Bug Hunting Session
Bug 124591 - Noto fonts don't display correctly in Microsoft (sorry, yes) Office 2016, please update to at least 2.001
Summary: Noto fonts don't display correctly in Microsoft (sorry, yes) Office 2016, ple...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.0.3 release
Hardware: All Windows (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2019-04-07 16:45 UTC by ezrider
Modified: 2019-06-14 12:12 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ezrider 2019-04-07 16:45:43 UTC
Description:
The Noto fonts in version 2.000 that are currently installed with LibO Version 6.2.x do not display correctly in Microsoft Office 2016. They are substituted with other fonts there. This is not strictly a LibO problem, but I am probably not the only (home) user of LibO who also has Microsoft Office in parallel (for job related reasons). Updating the Noto fonts to version 2.001 in LibO would fix this, see here:

https://answers.microsoft.com/en-us/msoffice/forum/all/its-2018-and-microsoft-still-cant-get-fonts-right/36bac9bc-e85e-4ad1-a226-f6b61db0aca0

So it's not a Microsoft problem but a bug in the Noto fonts distributed with LibO.

Steps to Reproduce:
1. Install Libreoffice (from version 6.x with Noto fonts)
2. Write document with Noto font (Noto Serif, Noto Sans)
3. Open document in Microsoft Office 2016.

Actual Results:
see above.

Expected Results:
Noto fonts are substituted with other fonts in Microsoft Office.


Reproducible: Always


User Profile Reset: No



Additional Info:
Use the latest version of Noto fonts (2.001) to avoid this problem.
Comment 1 Adolfo Jayme 2019-04-08 07:16:34 UTC
Thanks for your bug report.
Comment 2 V Stuart Foote 2019-04-09 06:25:01 UTC
I verify the missing code page details, opening the v2.000.GOOG build Noto fonts with FontCreator, but can not confirm the impact of the missing Code Page Character Ranges--at least in an en-US locale.

On a system with the Noto v2.00 build fonts installed with LibreOffice 6.2, LO generated ODF, OOXML and at least DOCX are rendered in MS Word 2016 with no loss of font fidelity. The Noto Sans and Noto Serif Regular fonts are parsed and read by MS Word.

On same system with an ODF exported to PDF (font subset) the PDF renders using the Noto fonts as composed.

So on the originating system this appears pretty benign. Of course it could be more severe reopening on a different system, or for locale using other scripts.

But, probably best to move to more current Noto sources that have been patched when available as this seems legitimate for some locales.

@Khaled?
Comment 3 Khaled Hosny 2019-06-14 12:12:44 UTC
That is a known bug in certain versions of Noto fonts that lacked code pages bits in the OS/2, which makes them not work on certain Windows applications that use the code pages to determine what character ranges the font supports before using fallback fonts (not only MS Office, but I believe other applications using RichEdit component as well).

I think we should upgrade our version since technically the version we have is broken on Windows even though LibreOffice itself is unaffected.