|
|
Selection_008.png (10,096 bytes) |
|
|
It also happens on the "gargi", "Waree", "Umpush", "Rekha", "Rachana", "OpenSymbol", "NanumGothic", "Meera", and "Loma" fonts. |
|
|
|
|
|
|
|
|
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. |
|
|
bug.png (10,331 bytes) |
|
|
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. |
|
|
hypehanted word.png (25,500 bytes) |
|
|
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. |
|
|
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. fwiw /quote |
|
|
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 Bob ---- 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 |
|
|
with invisible chars displayed.jpg (18,431 bytes) |
|
|
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. |
- Anonymous
