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
Created attachment 140823 [details] libreoffice install log for 6.0.3.1
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 > ...
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).
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.
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).
So Bug 97982 is not related?
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.
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).
(In reply to Khaled Hosny from comment #8) Thank you very much!
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.
Please backport it into 6.0.4
(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.
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).
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.
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.
*** Bug 116871 has been marked as a duplicate of this bug. ***