While verifying bug 119897 (update on Windows 10 64-bit from 6.1.1.2 -> 6.1.3.1) noticed in verbose installation log that packaged fonts with versioning are not replacing our earlier font installations registered without versioning. For example: MSI (s) (9C:84) [09:31:48:582]: Executing op: RegisterSharedComponentProvider(,,File=LiberationMono_Bold.ttf,Component={636E130F-4EC1-9AF3-2BD7-2E324C4DC331},ComponentVersion=2.0.1.0,ProductCode={28CD926D-EB22-4B4B-9139-494A3C25C3E2},ProductVersion=6.1.3,PatchSize=0,PatchAttributes=0,PatchSequence=0,SharedComponent=0,IsFullFile=0) MSI (s) (9C:84) [09:31:48:582]: Executing op: FileCopy(SourceName=LIBERA~1.TTF|LiberationMono-Bold.ttf,SourceCabKey=LiberationMono_Bold.ttf,DestName=LiberationMono-Bold.ttf,Attributes=16384,FileSize=301684,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,Version=2.0.1.0,,InstallMode=58982400,,,,,,,) MSI (s) (9C:84) [09:31:48:582]: File: C:\WINDOWS\Fonts\LiberationMono-Bold.ttf; Overwrite; Won't patch; New file versioned - existing file unversioned Would think we'd want our versioned to replace any older unversioned instances to get each font to a known state.
Initial work up for the see also bug 116581 in https://gerrit.libreoffice.org/#/c/51793/
Created attachment 145833 [details] zip Windows MSI verbose log of update from 6.1.1.2 -> 6.1.3.1
I'm not sure we want to fix this. It's unfortunate that we had bugs that resulted in "unversioned" fonts installed; but I cannot see how could we tell for sure if the unversioned version is resulting from our previous installation, and not from e.g. manual installation by user. (The other thing is that I don't know if we can enforce MSI behavior in this case - but this is secondary wrt the former question.)
(In reply to Mike Kaganski from comment #3) > I'm not sure we want to fix this. > > It's unfortunate that we had bugs that resulted in "unversioned" fonts > installed; but I cannot see how could we tell for sure if the unversioned > version is resulting from our previous installation, and not from e.g. > manual installation by user. (The other thing is that I don't know if we can > enforce MSI behavior in this case - but this is secondary wrt the former > question.) Verified an uninstall does clear out the Reference counts, so all that is necessary is a LibreOffice uninstall and a fresh LibreOffice install to move to our versioned fonts... This from a 6.1.3.1 install after first uninstalling... MSI (s) (0C:B4) [12:50:03:420]: Executing op: FileCopy(SourceName=LIBERA~1.TTF|LiberationMono-Bold.ttf,SourceCabKey=LiberationMono_Bold.ttf,DestName=LiberationMono-Bold.ttf,Attributes=16384,FileSize=301684,PerTick=65536,,VerifyMedia=1,,,,,CheckCRC=0,Version=2.0.1.0,,InstallMode=58982400,,,,,,,) MSI (s) (0C:B4) [12:50:03:420]: File: C:\WINDOWS\Fonts\LiberationMono-Bold.ttf; To be installed; Won't patch; No existing file MSI (s) (0C:B4) [12:50:03:420]: Source for file 'LiberationMono_Bold.ttf' is compressed InstallFiles: File: LiberationMono-Bold.ttf, Directory: C:\WINDOWS\Fonts\, Size: 301684 MSI (s) (0C:B4) [12:50:03:435]: Executing op: So, I am OK with the WONTFIX here. @Andras, * -- anyone with concerns of allowing the unversioned font instances to remain?
Hello V Stuart Foote, Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
(In reply to Xisco Faulí from comment #5) > Hello V Stuart Foote, > Could you please try to reproduce it with a master build from > http://dev-builds.libreoffice.org/daily/master/ ? Not really possible. Dev builds of master don't touch the registry unless forced, and fonts for an /a admin install are not pushed to the Windows/Fonts directory. I'm OK with the WF, we're well past builds through 6.1 and now are correctly versioned. Mike's comment 3 is reasonable.