Bug 111330 - Installation: does not use latest font version, and replaces with bundled-older
Summary: Installation: does not use latest font version, and replaces with bundled-older
Status: RESOLVED DUPLICATE of bug 39743
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-04 07:07 UTC by librelibre
Modified: 2018-03-31 11:50 UTC (History)
2 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 librelibre 2017-08-04 07:07:46 UTC
Description:
does not use latest font version 
e.g. https://github.com/adobe-fonts/source-code-pro/releases (2.030) vs 2.010,noitalics
http://www.paratype.com:80/uni/public/PTSerif.zip (1.002 2014) vs 1.000

does not check if later version already installed, 
and replaces with bundled older

also reverting-to-later font versions in windows not smooth (file-name-conflict due to replaced-later font-file not removed-internally but de-registered)

Steps to Reproduce:
1. note fonts already installed and their versions in control panel, also record command prompt C:\Windows\Fonts "dir"
2. update or install libreoffice
3. compare installed fonts after installation

Actual Results:  
source-code pro is reverted with older version,
cmd.exe dir reveals both older and nwer files in folder but only the bunded-libreoffice-version in registered/installed

Expected Results:
uses latest versions of the free fonts and use scripts to auto-check-for-updates,
if later version already installed (check file version, dates, metadata, size?) dont replace


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Comment 1 Julien Nabet 2017-08-04 09:45:01 UTC
For the test, could you rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile#Windows) and give a new try?
Indeed, I don't think fonts directory is scanned at each LO start.
Comment 2 QA Administrators 2018-03-02 10:01:56 UTC Comment hidden (obsolete)
Comment 3 Buovjaga 2018-03-03 18:38:58 UTC

*** This bug has been marked as a duplicate of bug 39743 ***
Comment 4 Mike Kaganski 2018-03-31 11:50:07 UTC
I'm not sure I understand the problem correctly. The description is vague.

As far as I know, 5.4.0.3 bundled 2.030 version of SourceCodePro fonts. So, it's unclear how could it downgrade to 2.010.

Also, at least for these fonts, it's improbable that LibreOffice would do all this, because it actually does contain fonts versions in MSI, and unless its records are wrong and report values greater than actual (which isn't the case for these fonts), it should do the job right.

Just FYI: we don't bundle PT Serif anymore as of 6.0.

The commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=c91f70f9b0129685737260c04a2e347726f1dedf should take care of the cases where our MSI database contained wrong version records; but as I said, this was not the case for these fonts.