Bug Hunting Session
Bug 125945 - Thin Space Not Properly Rendered in Proportionally Spaced Fonts
Summary: Thin Space Not Properly Rendered in Proportionally Spaced Fonts
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: All Mac OS X (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2019-06-16 02:19 UTC by Jon R Kibler
Modified: 2019-06-16 14:12 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
ODT file for experimentation (11.20 KB, application/vnd.oasis.opendocument.text)
2019-06-16 02:19 UTC, Jon R Kibler
Details
PDF of rendering example (32.29 KB, application/pdf)
2019-06-16 02:21 UTC, Jon R Kibler
Details
testDoc at 200% on Windows build of 6.2.4.2 (40.69 KB, image/png)
2019-06-16 14:12 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jon R Kibler 2019-06-16 02:19:49 UTC
Created attachment 152221 [details]
ODT file for experimentation

Thin Spaces are not properly rendered in proportionally spaced fonts.

It is my experience that the thin space should be about half the width of a space. This appears to be the case for mono-spaced fonts, but not for proportional-spaced fonts.

Please see attached ODT and PDF files.
Comment 1 Jon R Kibler 2019-06-16 02:21:21 UTC
Created attachment 152222 [details]
PDF of rendering example
Comment 2 V Stuart Foote 2019-06-16 04:27:11 UTC
IIUC fonts do specify metrics for the NPC and spacing and Harfbuzz will use exactly that spacing for layout. 

It is only when using fonts with no coverage of the NPC and space Unicode that either os fallback or spacing for an undefined glyph is assigned.

We'd nned specifics of which font you are having issue with--and which Unicode spacing.

Perhaps a sample document, save to one of the flat ODF document formats.
Comment 3 Khaled Hosny 2019-06-16 11:00:43 UTC
Liberation Sans and Liberation Serif has glyph for U+2009 and U+200A, so we use the widths provided by the font. Liberation Mono does not have glyphs for both characters (which is understandable, it is monowidth font), so the fallback mechanism in HarfBuzz kicks in and it calculates suitable widths for these spacing characters.

This is working as intended, if you think the font is wrong you need to report this to the font developers (though since these particular fonts are meant to be metric-compatible with other Windows fonts, it is unlikely that they will be changed).
Comment 4 V Stuart Foote 2019-06-16 14:12:39 UTC
Created attachment 152231 [details]
testDoc at 200% on Windows build of 6.2.4.2

The attachment 152221 [details] test doc opened on Windows 10 with 6.2.4.2 build.

On this platform and build, the metrics for U+0020, U+2009, U+200A spaces are reflected on canvas. They match the spacing of the OPs PDF output (shows Mac OS X 10.12.6 Quartz PDFcontext).

So, agree with Khaled that our HarfBuzz implementation on macOS is honoring the metrics provided by the font(s). And falls to the font designer to provide correct fonts. => NOB