Bug 1569943

Summary:	upgrading font version in a desktop session can affect rendering of text
Product:	[Fedora] Fedora	Reporter:	Jens Petersen <petersen>
Component:	firefox	Assignee:	Gecko Maintainer <gecko-bugs-nobody>
Status:	ASSIGNED ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	0xalen+redhat, ajax, alexl, fonts-bugs, gecko-bugs-nobody, i18n-bugs, jhorak, john.j5live, mclasen, petersen, pjasicek, psatpute, rhughes, rstrode, sandmann, tagoh
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jens Petersen 2018-04-20 10:53:11 UTC

Description of problem:
The Liberation 1 and 2 fonts may be binary incompatible
in the sense that upgrading a live desktop from Liberation 1 to 2
seemed to corrupt some characters for me in Firefox (with Ariel text in
Google Docs for the default unordered list mark symbols).

Version-Release number of selected component (if applicable):
liberation-fonts-2.00.1

Actual results:
'·' -> '>'
'⃝' -> '<'
for example

Expected results:
Not change of glyphs.

Additional info:
I suspect this might be due to caching of the old font's tables in memory.
It would be better if the tables were more compatible I suppose.

Comment 1 Jens Petersen 2018-04-23 08:42:40 UTC

This might be a issue with Firefox's fonts handling.

Comment 2 Nicolas Mailhot 2018-04-26 09:45:16 UTC

Yes, that's not specific to liberation at all, that's old and well-known broken fontconfig/harfbuzz integration in Firefox, it does not properly invalidate its font cache when fonts are updated. You have to close it to force it to parse the new font file metadata otherwise it seems to try reading glyphs as their location in the old font file even though the new font file has them moved somewhere else (with metadata that correctly indicates where this somewhere else is).

The bug should be reassigned

Comment 3 Pravin Satpute 2018-04-26 14:22:14 UTC

Thanks Nicolas for confirming. Being a font developer i often face this issue, specifically when FF is running and i update the font. For sometime all rendering gets broken

Comment 4 Jens Petersen 2018-07-17 08:33:57 UTC

I wonder if it could not be FreeType?

Comment 5 Akira TAGOH 2018-07-17 12:24:35 UTC

This isn't an issue in fontconfig even. this would rather be an application issue or rendering library where deal with file handles of fonts. fontconfig provides an API to let them know if fonts are being updated. they have a way to know that (but there are no way to know which one was updated...)
If they don't reopen a font when updating, the behavior may depends how they open it. that is likely to see such issue anyway.

Comment 6 Jan Kurik 2018-08-14 10:05:57 UTC

This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.

Comment 7 Jens Petersen 2019-09-10 07:04:32 UTC

I reported this upstream in https://bugzilla.mozilla.org/show_bug.cgi?id=1580099