View Issue Details

IDProjectCategoryView StatusLast Update
0010720ScribusFontspublic2019-06-04 20:56
ReporterTynach Assigned Tojghali  
Status closedResolutionfixed 
PlatformAMD64OSUbuntuOS Version12.04
Product Version1.4.1 
Target Version1.5.4Fixed in Version1.5.5.svn 
Summary0010720: Right-aligned text does not work as expected with some fonts.
DescriptionWhen 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 ReproduceUsing 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 InformationI 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.
Tagsalignment, layout, spacing, text, text frames


has duplicate 0012346 closedjghali (right-align) same bug as 0010720 but concerning more platforms and more versions 
related to 0012565 closedjghali Right alignment of hyphens 



2012-05-25 04:46


Selection_008.png (10,096 bytes)   
Selection_008.png (10,096 bytes)   


2012-05-25 04:55

reporter   ~0028029

It also happens on the "gargi", "Waree", "Umpush", "Rekha", "Rachana", "OpenSymbol", "NanumGothic", "Meera", and "Loma" fonts.


2012-05-25 05:36


bug.sla (10,941 bytes)


2012-05-25 05:36


bug.pdf (9,295 bytes)


2012-05-25 05:37

reporter   ~0028031

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.


2012-05-25 05:38


bug.png (10,331 bytes)   
bug.png (10,331 bytes)   


2012-05-25 05:39

reporter   ~0028032

Uploaded a screenshot with the "Show Control Characters" option enabled.


2012-05-25 05:39

manager   ~0028033

i see it with the "Loma" font...


2014-04-24 00:54

reporter   ~0031797

Can confirm this bug with both right-alignment and forced justification on 1.4.3


2014-04-25 09:33

developer   ~0031809

Last edited: 2014-07-28 21:41

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.


2014-04-25 09:33


hypehanted word.png (25,500 bytes)   
hypehanted word.png (25,500 bytes)   


2014-05-19 19:34

reporter   ~0031866

I confirm this for OpenSuse 12.3 x86_64
KDE 4.10.5
Linux 3.7.10-1.28-desktop

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.


2014-05-21 16:20

developer   ~0031897

Last edited: 2014-05-21 16:21

quote of MZaske on the scribus list :

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.



2014-06-04 12:23

reporter   ~0031995

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
a problem.

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
of things?

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 ----


2014-06-04 16:00

developer   ~0032009

Last edited: 2014-06-05 20:54

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.


2015-12-13 11:43

updater   ~0037909

Needs testing since 0012565 has been fixed


2015-12-13 13:30



2018-10-20 21:42

administrator   ~0045524

This is apparently fixed in current 1.5.5.svn.


2018-10-21 08:39

developer   ~0045526

yes it is !


2018-10-22 20:10

reporter   ~0045532

Glad to know this is fixed! I wonder what the relevant commit was that fixed it, and how long ago it actually got fixed?


2018-10-22 20:18

administrator   ~0045533

I suspect this is the text layout engine rewrite which occurred during 1.5.3 development which fixed the issue.

Issue History

Date Modified Username Field Change
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