Bug 116581 - disappear Noto fonts after install LibreOffice 6.0.3.1 on Windows 10
Summary: disappear Noto fonts after install LibreOffice 6.0.3.1 on Windows 10
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
6.0.3.1 rc
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.1.0 target:6.0.4
Keywords:
: 116871 (view as bug list)
Depends on:
Blocks: Installer-Windows
  Show dependency treegraph
 
Reported: 2018-03-23 08:51 UTC by Roman Kuznetsov
Modified: 2018-04-08 16:57 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
libreoffice install log for 6.0.3.1 (2.40 MB, application/octet-stream)
2018-03-23 08:55 UTC, Roman Kuznetsov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Kuznetsov 2018-03-23 08:51:55 UTC
Description:
disappear Noto fonts after install LibreOffice 6.0.3.1 on Windows 10

Steps to Reproduce:
1. Install 6.0.2.1 on Windows
2. Check system fonts in C:\Windows\Fonts -> There are Noto fonts
3. Then install 6.0.3.1 (don't delete 6.0.2.1 and user profile)
4. Check system fonts in C:\Windows\Fonts -> Noto fonts are disappear!

Actual Results:  
Noto fonts are disappear after install LO 6.0.3.1!

Expected Results:
There are Noto fonts in Windows system path after install LO 6.0.3.1


Reproducible: Always


User Profile Reset: No



Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Firefox/60.0
Comment 1 Roman Kuznetsov 2018-03-23 08:55:41 UTC
Created attachment 140823 [details]
libreoffice install log for 6.0.3.1
Comment 2 Mike Kaganski 2018-03-23 09:30:16 UTC
Andras, do you have any idea why the fonts get unregistered and removed, but not copied back, despite the component's action is "Absent"?

> MSI (s) (48:1C) [11:37:16:415]: Component: auto_ooo_fonts_pkg_fonts_noto__libreoffice_share_fonts_truetype; Installed: Absent;   Request: Local;   Action: Null;   Client State: Unknown
> ...
> MSI (s) (48:C0) [11:37:38:087]: Component: auto_ooo_fonts_pkg_fonts_noto__libreoffice_share_fonts_truetype; Installed: Local;   Request: Absent;   Action: Absent;   Client State: Local
> ...
> MSI (s) (48:C0) [11:37:46:102]: Executing op: FontUnregister(,File=NotoKufiArabic-Bold.ttf)
> ...
> MSI (s) (48:C0) [11:37:51:446]: Executing op: FileRemove(,FileName=NotoKufiArabic-Bold.ttf,,ComponentId={8ABA772F-AC26-C739-AAE6-EDA59ED2A2EB})
> ...
> MSI (s) (48:1C) [11:38:41:821]: Executing op: ComponentRegister(ComponentId={8ABA772F-AC26-C739-AAE6-EDA59ED2A2EB},KeyPath=C:\Windows\Fonts\NotoKufiArabic-Bold.ttf,State=3,,Disk=1,SharedDllRefCount=1,BinaryType=1)
> 1: {86113701-E008-4B35-9142-30D2A2F4A8C2} 2: {8ABA772F-AC26-C739-AAE6-EDA59ED2A2EB} 3: C:\Windows\Fonts\NotoKufiArabic-Bold.ttf 
> ...
Comment 3 Mike Kaganski 2018-03-23 10:28:40 UTC
The problem seems to be this:

> MSI (c) (DC:C4) [11:37:01:383]: Disallowing installation of component: {8ABA772F-AC26-C739-AAE6-EDA59ED2A2EB} since the same component with higher versioned keyfile exists

The MSI has NotoKufiArabic_Bold.ttf and other Noto fonts to have version 1.0.0.0. But the file (when opened with Windows built-in font view tool) shows version 1.04.

The related issue with a codepointer is bug 76239, in which a code to get the font version was implemented (http://cgit.freedesktop.org/libreoffice/core/commit/?id=df4afab6fcf653ee71762891b0bf287813726e45).
Comment 4 Mike Kaganski 2018-03-23 13:24:16 UTC
https://gerrit.libreoffice.org/51781

The problem is that some fonts only have version text encoded as UTF-16, while we only looked for 8-bit-encoded version string. This makes the fonts to be marked with wrong (default 1.0.0.0) version inside MSI package, thus failing to reinstall them on update.
Comment 5 Mike Kaganski 2018-03-23 13:37:38 UTC
This will affect Alef, amiri, Noto, and Reem Kufi (the latter will be removed once, because its version will go down from 1.0.0.0 to correct 0.6.0.0).
Comment 6 Timur 2018-03-23 15:06:30 UTC
So Bug 97982 is not related?
Comment 7 Commit Notification 2018-03-23 15:59:36 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2367557493c216be5b5e8156ba6493d440a10b0f

tdf#116581: also read UTF16-encoded version string from TTF

It will be available in 6.1.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 8 Khaled Hosny 2018-03-23 17:27:48 UTC
This (the original commit actually) is really a bad idea. Matching random strings in a binary file is never a good idea.

The proper way is to parse the TTF files and look for the version entries. Fortunately there is a Perl module for this, you need to use it and check the fontRevision in “head“ table (https://docs.microsoft.com/en-us/typography/opentype/spec/head, https://metacpan.org/pod/Font::TTF::Head) and/or name id 5 (version) in the “name” table (https://docs.microsoft.com/en-us/typography/opentype/spec/name, https://metacpan.org/pod/Font::TTF::Name).
Comment 9 Mike Kaganski 2018-03-23 19:58:17 UTC
(In reply to Khaled Hosny from comment #8)

Thank you very much!
Comment 10 Commit Notification 2018-03-26 10:00:04 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

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

Related: tdf#116581 Use Font:TTF::Font to get font versions

It will be available in 6.1.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 11 Roman Kuznetsov 2018-03-31 12:15:23 UTC
Please backport it into 6.0.4
Comment 12 Mike Kaganski 2018-03-31 12:50:04 UTC
(In reply to kompilainenn from comment #11)

I'm not sure that it's OK to backport it, since it would mean to introduce a new build requirement to a point release.

Also, note that the problem also affects 5.4 and older as well: see bug 115243, which is actually a dupe of this.
Comment 13 Mike Kaganski 2018-03-31 12:52:01 UTC
Heh, sorry - that one is also for 6.0, so unless we had bundled fonts with wrong versions in 5.4, it probably actually didn't affect that (by chance).
Comment 14 Commit Notification 2018-04-04 09:10:46 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f207ae9c7010b04f8a10554a3c9b62991fe51247&h=libreoffice-6-0

tdf#116581: also read UTF16-encoded version string from TTF

It will be available in 6.0.4.

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 15 Mike Kaganski 2018-04-04 09:17:57 UTC
Only a non-intrusive first patch version was backported to 6-0, to avoid introducing a new build-time dependency. This fixes the problem, I suppose that's enough for that branch.
Comment 16 V Stuart Foote 2018-04-08 16:57:21 UTC
*** Bug 116871 has been marked as a duplicate of this bug. ***