View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0012346||Scribus||Typography||public||2014-06-04 12:49||2018-10-20 21:43|
|Target Version||1.5.4||Fixed in Version|
|Summary||0012346: (right-align) same bug as 0010720 but concerning more platforms and more versions|
|Description||I do not manage to edit the "Report Details" for Bug 0010720 but we are seeing the same problem:|
On Windows machines in our office (Win 7 pro) and on OpenSuse machines 13.1 and 12.3 and 12.1
We are seeing this on OpenSuse 1.4.3 and 1.4.2 and other people have seen it in the 1.5.0svn
This might need to be in category "font" or rather "font rendering" (did not find, so I put it in cat typography) but other users might search for this in "textframes"
|Steps To Reproduce||create any text with more than one paragraph and make it right-align: The not-last paragraphs will not exactly right-align but will show an unwanted space character (probably the rendering of the CR glyph) at the right-most position.|
This happens for many fonts (for example SIL Charis or Times New Roman) but NOT for other fonts (for example Arial or DejaVu).
Only the last paragraph will properly right align.
Right-alignment might seem rare and exotic, but we need it for several documents (for educational posters etc), so for us, priority should be even "higher", please.
|Additional Information||This is most likely to do about rendering text in right-align context:|
Based on a test with a "corrected" font, suspicions are that Scribus is "drawing" the glyphs not only for the
text of your lines, but also at least the "carriage return" character
(U+000D) and possibly the "linefeed" character (U+000A). Most
applications don't actually draw these characters (unless the user turns
on special "show invisible" or similar options that the app might
support) but rather just performs the necessary re-positioning that
would be indicated by the CR or LF.
Actually drawing the CR/LF characters wouldn't be a problem -- UNLESS
the font being rendered had real glyphs encoded to the CR or LF
characters. As it turns out, SIL Charis and Andika (and a number of other of
SIL fonts) *do* have a glyph encoded for the CR character. This isn't a
violation of any technical specification, and it hasn't (until now) been
Thus guessing that all the fonts users are having trouble with have a
glyph encoded for the CR and/or LF characters and the fonts that "work"
do not encode those.
What was tweaked in the test-font (a copy of SIL Charis) was to remove the CR character from the font (LF wasn't present anyway). With the tweaked font, the right alignment DID work properly!
|2014-06-04 12:49||MZaske||New Issue|
|2014-06-04 16:03||ale||Relationship added||related to 0010720|
|2014-07-24 04:45||Kunda||Target Version||=> 1.5.1|
|2014-07-29 13:52||Kunda||Relationship added||related to 0012565|
|2014-10-04 19:17||JLuc||Summary||same bug as ID 0010720 but concerning more platforms and more versions => same bug as#10720 but concerning more platforms and more versions|
|2014-10-04 19:17||JLuc||Description Updated||View Revisions|
|2014-10-04 19:18||JLuc||Summary||same bug as#10720 but concerning more platforms and more versions => same bug as 0010720 but concerning more platforms and more versions|
|2014-10-04 19:19||JLuc||Tag Attached: layout|
|2014-10-08 22:16||Kunda||Summary||same bug as 0010720 but concerning more platforms and more versions => (right-align) same bug as 0010720 but concerning more platforms and more versions|
|2015-12-13 11:44||Kunda||Note Added: 0037910|
|2016-01-23 17:16||cbradney||Target Version||1.5.1 => 1.5.3|
|2016-12-08 22:04||Kunda||Target Version||1.5.3 => 1.5.4|
|2018-10-20 21:42||jghali||Relationship replaced||duplicate of 0010720|
|2018-10-20 21:43||jghali||Assigned To||=> jghali|
|2018-10-20 21:43||jghali||Status||new => resolved|
|2018-10-20 21:43||jghali||Resolution||open => duplicate|
|2018-10-20 21:43||jghali||Status||resolved => closed|