View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0010720||Scribus||Fonts||public||2012-05-25 04:46||2019-06-04 20:56|
|Target Version||1.5.4||Fixed in Version||1.5.5.svn|
|Summary||0010720: Right-aligned text does not work as expected with some fonts.|
|Description||When you have a text frame that is set to right-align, and you add multiple lines of text, every line has an extra 'space' at the end of the line except for the very last line. It appears as if a newline character adds both a space AND a newline; this space is not deletable without deleting the newline as well.|
This only happens with some fonts, noticeably the Ubuntu font that comes with the system. I happen to really love the style of this font, so this is very frustrating and disappointing.
|Steps To Reproduce||Using Ubuntu 12.04, create a large enough text frame to hold multiple lines of text.|
Make the text box right-aligned.
Set the font to the "Ubuntu" font.
Enter some text, and press 'Enter' to go to a new line. A space will be added to the last line of text automatically. Get rid of the new line, and the space goes away instantly. Thus, all lines will have a space at the end except for the last one.
|Additional Information||I used whatever version of Scribus comes up when you use the Software Center. I know in 11.10, it had a "Scribus Development" and "Scribus Stable", however I didn't use Synaptic or anything like that on my fresh install of 12.04. I just used the software center. It installed "1.4.1.svn", though now it appears that version is called "1.4.1", and the new .svn (according to this website) is 1.4.2.svn. I don't know if this is relevant.|
|Tags||alignment, layout, spacing, text, text frames|
||It also happens on the "gargi", "Waree", "Umpush", "Rekha", "Rachana", "OpenSymbol", "NanumGothic", "Meera", and "Loma" fonts.|
bug.sla (10,941 bytes)
bug.pdf (9,295 bytes)
||Uploaded a .sla file, and a .pdf file, with the bug. Don't know if you'll see it in the .sla file if it doesn't occur on your system.|
||Uploaded a screenshot with the "Show Control Characters" option enabled.|
||i see it with the "Loma" font...|
||Can confirm this bug with both right-alignment and forced justification on 1.4.3|
I confirm on scribus 1.5 (using the bug.sla uploaded file)
It happens also for hyphenated words. See uploaded screenshot. See 0012565
Note that with this font, a Carriage Return doesnt add a space at the line, but a hyphen does.
I confirm this for OpenSuse 12.3 x86_64
comes ready with Scribus 1.4.2 C-C-T-F-C1.12.8-64bit
We are seing the bug with several fonts, for example Times New Roman and SIL Charis. It behaves erratically, sometimes we can get rid of the spaces (by hitting Enter and deleting several times) sometimes we cannot and it is frustrating my team.
Can the priority be upped? This is preventing us from creating properly aligned picture-dictionary charts, because the text on the right of the main illustration does not properly justify. (If ALL the lines would behave funnyly, we could just move the text-box, but so, it is a severe problem.)
Other users, please write if you find (or found) a workaround. Thank you.
quote of MZaske on the scribus list http://permalink.gmane.org/gmane.comp.graphics.scribus/44840 :
I [...] did some testing today :
One can easily identify the fonts which get miss-handled when activating View > Show Control Characters. Those which show proper paragraph symbols, tend to properly right-align.
Text portions in fonts which are not handled correctly tend to not show any paragraph symbols. (When editing some mixed font text in the inbuilt editor, I even had all the paragraph symbols disappear...).
Concerning workarounds :
If an entire text-box is done in the same font, one can create a
dummy-last-line which just needs to be empty. That way each visible line
receives the same buggy "space" on the right. And the entire text-box
can be shifted according to document layout-needs.
This does not seem to work for mixed fonts, because the unwanted
right-hand-side spaces appear in different widths, depending on font. So
no joy with right-aligning mixed fonts (luckily this does not affect us,
we keep our documents simple).
Another potential workaround (depending on user needs) is this: Normal
paragraph text - which flows over several lines - does right-align
properly. So the "bad space" only happens where there is a paragraph-end.
If the user can replace the "paragraph-end-character" by New Line
(Shift plus Return) then the bug does not affect those and the text
looks properly right-aligned. And yes, there are side effects, because
paragraphs do exist for a reason...
And for control-testing (comparison), my fonts DejaVu are not affected,
and those are widely available.
I have no idea whether this is something fundamental within the text
rendering engine, or maybe just some off way of reading certain font
parameters. The fact that alignment and also the showing (or not) of the
control characters is affected together might be a pointer for the
developers where to look.
I had asked some people about this who really know about fonts. And I
have received a patched version of one of the affected fonts: It now
does properly right-align.
---- Here some extracts from our exchange: ----
On 2014-05-21 at 15:28 Martin Zaske wrote:
> Hi Bob,
> I am really exited about your suspicion. Of course I am willing to
test since we are benefiting from your help. .......
> Whatever you tweaked in the copy of Charis, it makes the right-align
bug in Scribus "go away".
That's good news!
> Normally (with the bug) each right-aligned line shows one unwanted
right-side-space (except the very last line). With your modified version
it behaves better. ......
> Now I would like to ask you "how you did it", please. Maybe you could
briefly write up your tweak in "font-developer-speak", so that I can
post it on the Scribus list and on the Scribus bug-management-site, for
the benefit of the Scribus users, and developers and other font makers.
My 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, Charis and Andika (and a number of other of
our 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 my guess is that all the fonts you 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 I tweaked in the font I sent you was to remove the CR character
from the font (LF wasn't present anyway).
> Would you consider this an issue which should rather be "fixed" at the
font-side of things, or rather at the text-rendering (in Scribus) side
As you might deduce from the above description, I think it could be
"fixed" either way. One could change Scribus so that it doesn't
physically draw the CR/LF glyphs, or one can patch all the affected
fonts so they don't encode those characters.
Assuming my understanding is correct, then making the change to Scribus
would be a universal fix. But there may be reasons that the Scribus
folks don't want to make this change, in which case you are dependent on
font vendors to fix all the fonts that you are interested in.
Hope this helps
---- end of extract ----
So the issue is that some CR glyphs actually have some width in some fonts (as a space), and not in some others, and Scribus actually displays this glyph as if it was a real glyph instead of just "acting=CRLF-ing" it ?
Is there no standard or spec for fonts about that issue ?
Since the users cannot tweak all existent fonts, it looks like Scribus should test whether the glyph being displayed is CRLF and in such a case, not display anything.
||Needs testing since 0012565 has been fixed|
||This is apparently fixed in current 1.5.5.svn.|
||yes it is !|
||Glad to know this is fixed! I wonder what the relevant commit was that fixed it, and how long ago it actually got fixed?|
||I suspect this is the text layout engine rewrite which occurred during 1.5.3 development which fixed the issue.|
|2012-05-25 04:46||Tynach||New Issue|
|2012-05-25 04:46||Tynach||File Added: Selection_008.png|
|2012-05-25 04:55||Tynach||Note Added: 0028029|
|2012-05-25 05:06||Tynach||Tag Attached: alignment|
|2012-05-25 05:06||Tynach||Tag Attached: text|
|2012-05-25 05:06||Tynach||Tag Attached: text frames|
|2012-05-25 05:06||Tynach||Tag Attached: spaces|
|2012-05-25 05:36||Tynach||File Added: bug.sla|
|2012-05-25 05:36||Tynach||File Added: bug.pdf|
|2012-05-25 05:37||Tynach||Note Added: 0028031|
|2012-05-25 05:38||Tynach||File Added: bug.png|
|2012-05-25 05:39||Tynach||Note Added: 0028032|
|2012-05-25 05:39||ale||Note Added: 0028033|
|2014-04-07 15:46||JLuc||Tag Attached: layout|
|2014-04-24 00:54||Pancho||Note Added: 0031797|
|2014-04-25 09:33||JLuc||Note Added: 0031809|
|2014-04-25 09:33||JLuc||File Added: hypehanted word.png|
|2014-04-25 09:47||JLuc||Note Edited: 0031809|
|2014-04-25 10:23||JLuc||Note Edited: 0031809|
|2014-04-25 10:23||JLuc||Note Edited: 0031809|
|2014-05-19 19:34||MZaske||Note Added: 0031866|
|2014-05-19 20:16||JLuc||Note Edited: 0031809|
|2014-05-19 20:25||JLuc||Note Edited: 0031809|
|2014-05-21 16:20||JLuc||Note Added: 0031897|
|2014-05-21 16:21||JLuc||Note Edited: 0031897|
|2014-06-04 12:23||MZaske||Note Added: 0031995|
|2014-06-04 16:00||JLuc||Note Added: 0032009|
|2014-06-04 16:03||ale||Relationship added||related to 0012346|
|2014-06-05 20:54||JLuc||Note Edited: 0032009|
|2014-07-24 04:46||Kunda||Target Version||=> 1.5.1|
|2014-07-24 12:26||Kunda||Summary||Right-aligned text does not work work as expected with some fonts. => Right-aligned text does not work as expected with some fonts.|
|2014-07-28 21:39||JLuc||Note Edited: 0031809|
|2014-07-28 21:41||JLuc||Note Edited: 0031809|
|2014-07-29 13:52||Kunda||Relationship added||related to 0012565|
|2014-12-25 10:28||JLuc||Patch||=> No|
|2014-12-25 10:28||JLuc||Severity||tweak => major|
|2014-12-25 10:28||JLuc||Status||new => confirmed|
|2015-12-13 11:43||Kunda||Note Added: 0037909|
|2015-12-13 13:30||JLuc||File Added: with invisible chars displayed.jpg|
|2016-01-23 17:17||cbradney||Target Version||1.5.1 => 1.5.3|
|2016-03-10 14:16||Kunda||Tag Detached: spaces|
|2016-03-10 14:16||Kunda||Tag Attached: spacing|
|2016-12-08 22:04||Kunda||Target Version||1.5.3 => 1.5.4|
|2018-10-20 21:42||jghali||Assigned To||=> jghali|
|2018-10-20 21:42||jghali||Status||confirmed => resolved|
|2018-10-20 21:42||jghali||Resolution||open => fixed|
|2018-10-20 21:42||jghali||Fixed in Version||=> 1.5.5.svn|
|2018-10-20 21:42||jghali||Note Added: 0045524|
|2018-10-20 21:42||jghali||Relationship replaced||has duplicate 0012346|
|2018-10-21 08:39||JLuc||Note Added: 0045526|
|2018-10-22 20:10||Tynach||Note Added: 0045532|
|2018-10-22 20:18||jghali||Note Added: 0045533|
|2019-06-04 20:56||cbradney||Status||resolved => closed|