I got this multiple times over the years. Some fonts (that I actually use) just disappeared after libreoffice finished installation. Last time it was either the gentium fonts or the gentium basic fonts. They were just simply removed. Previously other fonts were removed. I didn't make notes which.
For OP, @Zsolt - what was the most recent build you had an issue with? This was fixed for bug 76239 for 4.4.7, 5.0.5, and 5.1.0 builds. @Andras, depending on OPs response would you prefer we reopen bug 76239 or collect additional details of what is happening with the Windows packaging of fonts here? *** This bug has been marked as a duplicate of bug 76239 ***
(In reply to V Stuart Foote from comment #1) > For OP, @Zsolt - what was the most recent build you had an issue with? > > This was fixed for bug 76239 for 4.4.7, 5.0.5, and 5.1.0 builds. > When I installed the latest one I have: 5.1.1.3 (x64). The gentium basic fonts were wiped.
OK, but we really need a verbose install log of the font removal as caught when doing "msiexec.exe /i <LibreOffice*.msi> /L*v install.log" from a command window. Know it is a hassle of having to work backwards--uninstall, install, upgrade. But, that captures the logic of why a font is removed rather than upgraded or left intact. Archive builds are available here: http://downloadarchive.documentfoundation.org/libreoffice/old/ Thanks!
(In reply to V Stuart Foote from comment #3) > OK, but we really need a verbose install log of the font removal as caught > when doing "msiexec.exe /i <LibreOffice*.msi> /L*v install.log" from a > command window. > > Know it is a hassle of having to work backwards--uninstall, install, > upgrade. But, > that captures the logic of why a font is removed rather than upgraded or > left intact. > > Archive builds are available here: > http://downloadarchive.documentfoundation.org/libreoffice/old/ > > Thanks! Isn't there an install log that's saved on normal installation?
Created attachment 124211 [details] 5.1.1.3 installation log Well I did it. Of course unsurprisingly I don't get any removed font now. I doesn't always happen. Too bad there's no installation log every time. Anyway I'll attach it. I doubt it'll be of much use.
Thanks for rolling back and running the two installations and posting the log. As you say typical that you did not have a repeat--these Windows installer issues can be very annoying to pin down. For what it is worth, if you look in the log at line #102073 there is an "Executing op: SetTargetFolder(Folder=C:\Windows\fonts)" from there onward are the control and operation sequences for the font installation. Note that many show as "To be installed; Won't patch; No existing file" but some are "Won't Overwrite; Won't patch; Existing file is of an equal version" and also "Overwrite; Won't patch; New file versioned - existing file unversioned" those continue through line #102409 -- the mix of CLSID GUID registrations earlier coupled with these "op" lines detail specifics of what happens with the fonts during install. Installing, patching, upgrading fonts. A similar log can be captured during an uninstallation. The patch done for bug 76239 (cmnt#66 & cmnt#35) refined the logic of using ref counts for font replacement. Unfortunately to make any additional adjustments to it we'd need solid log of things as the errant replacements/removals occur. It has been very hard to catch it. Which is why this should probably be linked to bug 76239 as a continuation if not simply duped back to it and reopen. It is not yet 100% correct, but without detailed log we're kind of stuck. To my mind it is Andras's call about going forward here, or just adding to 76239
(In reply to V Stuart Foote from comment #6) > Unfortunately to make any additional > adjustments to it we'd need solid log of things as the errant > replacements/removals occur. It has been very hard to catch it. > Can't you guys configure the installer to make a log on every installation/uninstallation? And then just as for that log whenever a user reports a problem like this?
(In reply to Zsolt from comment #7) > To my mind it is Andras's call about going forward here, or just adding to > 76239 Bug 76239 was about OpenSymbol font, which is somewhat special, because Math depends on it. Unless you see problems with OpenSymbol, please do not reopen that bug, even if you think that the root cause is the same. The fix of bug 76239 was that the LibreOffice Windows installer database (.msi) now uses font version numbers, and font files are refcounted by Windows installer. This is the same what MS Office does. I don't have a better idea than this, and if you are still experiencing bugs, then I need not only the installer log files, but the possible explanation of the situation. E.g. where did the removed font files come from?
(In reply to Andras Timar from comment #8) > (In reply to Zsolt from comment #7) > > > To my mind it is Andras's call about going forward here, or just adding to > > 76239 > > Bug 76239 was about OpenSymbol font, which is somewhat special, because Math > depends on it. Unless you see problems with OpenSymbol, please do not reopen > that bug, even if you think that the root cause is the same. > > The fix of bug 76239 was that the LibreOffice Windows installer database > (.msi) now uses font version numbers, and font files are refcounted by > Windows installer. This is the same what MS Office does. I don't have a > better idea than this, and if you are still experiencing bugs, then I need > not only the installer log files, but the possible explanation of the > situation. E.g. where did the removed font files come from? Well, since there's no log file generated on normal installation that's unavailable. In the last instance the removed files were installed from the font's own website: http://scripts.sil.org/cms/scripts/page.php?item_id=Gentium_basic#801ab246 And got purged when I installed 5.1.1.
So it happened again. Of course not when I was logging... I realized that there's a newer version than 5.1.1 so I updated. The same font disappeared. Although I only noticed it today. So either it was only removed after I restarted or I didn't start my video player after it. (I use this font for subtitles) I tried to re-create it. Downgrade to 5.1.1, then upgrade again but it didn't happen again. Most annoying. Since it not happens every upgrade I'm guessing the actual fonts in the package have to be never than the ones installed on the system as a prerequisite for this bug. It'd help a lot if the installer would automatically create a log with relevant entries. Otherwise it'll be hard to get a log. One has to be familiar with the issue and remember to start logging every time one updates libreoffice in hopes it happens to present itself at that time.
Created attachment 124420 [details] pair of installation logs-- clean 5.1.1.3 install and upgrade to 5.1.2.2 with external Gentium Basic v1.102 already installed On Windows 10 Pro 64-bit en-US Version: 5.1.2.2 (x64) Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) @Andras -- so given comment 9 and version disparity between SIL's Gentium 1.102 and our Gentium 1.100 bundling is the version logic done with https://cgit.freedesktop.org/libreoffice/core/commit/?id=38e24f1d059a6123ea15a68b4b24ca984642d66e breaking? Could we end up somehow uninstalling the Gentium Basic font bundle (1.102 assume a ref count of 0), but then not replacing (with 1.100)? I just did a complete removal of LO, then installed Gentium Basic and Gentium Book Basic (1.102) downloaded from the link. Then a clean custom install of 5.1.1.3 --fully logged-- Gentium Basic remained intact, ref to the bundled 1.100 but did not remove or object. Upgraded to 5.1.2.2 --fully logged-- the 1.102 Gentium Basic fonts remained, but again the installer noted 1.100 version, not the installed 1.102 build. Did not affect the fonts otherwise and they remain the 1.102 release. Logs attached.
Can the fonts being in use effect the outcome of the installation process?
There's Bug 97982 already in CC, but is this one a duplicate?
*** Bug 115441 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 97982 ***