Bug 89252 - font width affected by previous use of synthetic bold
Summary: font width affected by previous use of synthetic bold
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
PreBibisect
Hardware: Other All
: medium normal
Assignee: martin_hosken
URL:
Whiteboard: target:4.5.0 target:4.4.2 target:4.3.7
Keywords: preBibisect
Depends on:
Blocks:
 
Reported: 2015-02-09 11:56 UTC by Justin L
Modified: 2015-12-17 08:46 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Zip containing several example documents and PDF evidence. (122.76 KB, application/force-download)
2015-02-09 11:56 UTC, Justin L
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin L 2015-02-09 11:56:55 UTC
Created attachment 113251 [details]
Zip containing several example documents and PDF evidence.

When a graphite font without a physical fontfile for bold or italics is used, the character width depends on how it was “first used”.  Using the same font/size in a different, separate document can also affect the layout.  This bug affects Linux (since before version 3.5), but not Windows.

For example, if I type a-z in bold Andika font, and then type it again as a regular Andika font, the regular character widths will be just as wide as the bold widths - taking up a lot more space on the line than it should.  “First used” refers to LibreOffice as a whole - so if in an earlier-opened document the font was used, then the second document's layout width will be affected by the first document.

Linux instructions for installing the Andika Compact font used in the example document can be found here:  http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&id=andika_download

A work-around is to start LibreOffice with “SAL_DISABLE_GRAPHITE=true soffice”.

The attached PDF shows the following results:
Page 1:  Bug evidence - bold and regular take up the same width in the test document. 
Page 2:  SAL_DISABLE_GRAPHITE workaround applied - fixes the problem. 
Page 3:  simply displays the contents of the “first document” which causes LibreOffice to cache regular width font sizes for each alphabet letter. 
Page 4:  evidence that the “first document” font cache affects the width of the test document.  The bold characters are now “squished” because they are using the regular width. 


The developer can see the problem using this code...
file:  vcl/generic/glyphs/graphite_serverfont.cxx
function: float freetypeServerFontAdvance(const void* appFontHandle, gr_uint16 glyphId)
SAL_WARN("DEBUG","caching fontwidth["<<pServerFont->GetGlyphMetric(glyphId).GetCharWidth()<<"] for ["<<glyphId<<"] font["<<pServerFont->GetFontFileName()<<"]");

This appears to be a bug in the integration code for SIL's graphite library.  I have noticed the bug occurring while using SIL's Andika, Doulos, and GentiumPlus font familes. Based on the output of the debugging line, I would suggest that this bug only occurs where synthetic bolding (or italics?) occurs.
Comment 1 Justin L 2015-02-10 15:32:21 UTC
Patch submitted by Martin Hosken for review:  
https://gerrit.libreoffice.org/#/c/14380/
Comment 2 Commit Notification 2015-02-12 10:40:04 UTC
Martin Hosken committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0ed14401925d16932ed98bc418d395adac047b39

Resolves: tdf#89252 Fix bold, regular font spacing bug for Graphite fonts

It will be available in 4.5.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 3 Commit Notification 2015-02-12 10:51:24 UTC
Martin Hosken committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=19af334c922a9f3a25db68bc90ceb9446eeb79b0&h=libreoffice-4-4

Resolves: tdf#89252 Fix bold, regular font spacing bug for Graphite fonts

It will be available in 4.4.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 4 Commit Notification 2015-02-12 10:52:46 UTC
Martin Hosken committed a patch related to this issue.
It has been pushed to "libreoffice-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c2447648961bc8fa4776f996604fead893e3be4&h=libreoffice-4-3

Resolves: tdf#89252 Fix bold, regular font spacing bug for Graphite fonts

It will be available in 4.3.7.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 5 Rik Shaw 2015-02-12 11:42:03 UTC
Martin, thank you for your quick response!
Comment 6 Justin L 2015-02-12 19:00:08 UTC
Here are some scripts to implement the temporary workaround until the fixed versions are released:

sed -i -e 's#SAL_DISABLE_GRAPHITE=true \+##g' -e 's#^Exec=\(env \)*#Exec=env SAL_DISABLE_GRAPHITE=true #'  /usr/share/applications/libreoffice-*.desktop

undo with:
sed -i -e 's#=env \+SAL_DISABLE_GRAPHITE=true \+\(libreoffice\|soffice\)#=\1#' -e 's#SAL_DISABLE_GRAPHITE=true \+##g' /usr/share/applications/libreoffice-*.desktop
Comment 7 Robinson Tryon (qubit) 2015-12-17 08:46:40 UTC Comment hidden (obsolete)