https://bugzilla.redhat.com/show_bug.cgi?id=1569943
Bug ID: 1569943 Summary: upgrading from Liberation 1 to 2 in a desktop session can affect rendering of text Product: Fedora Version: rawhide Component: liberation-fonts Assignee: psatpute@redhat.com Reporter: petersen@redhat.com QA Contact: extras-qa@fedoraproject.org CC: alexl@redhat.com, fonts-bugs@lists.fedoraproject.org, i18n-bugs@lists.fedoraproject.org, john.j5live@gmail.com, mbarnes@fastmail.com, mclasen@redhat.com, petersen@redhat.com, psatpute@redhat.com, rhughes@redhat.com, rstrode@redhat.com, sandmann@redhat.com
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.
https://bugzilla.redhat.com/show_bug.cgi?id=1569943
--- Comment #1 from Jens Petersen petersen@redhat.com --- This might be a issue with Firefox's fonts handling.
https://bugzilla.redhat.com/show_bug.cgi?id=1569943
--- Comment #2 from Nicolas Mailhot nicolas.mailhot@laposte.net --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1569943
--- Comment #3 from Pravin Satpute psatpute@redhat.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1569943
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ajax@redhat.com, | |pnemade@redhat.com, | |tagoh@redhat.com Component|liberation-fonts |fontconfig Assignee|psatpute@redhat.com |tagoh@redhat.com
--- Comment #4 from Jens Petersen petersen@redhat.com --- I wonder if it could not be FreeType?
https://bugzilla.redhat.com/show_bug.cgi?id=1569943
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|upgrading from Liberation 1 |upgrading font version in a |to 2 in a desktop session |desktop session can affect |can affect rendering of |rendering of text |text |
https://bugzilla.redhat.com/show_bug.cgi?id=1569943
--- Comment #5 from Akira TAGOH tagoh@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1569943
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |0xalen@protonmail.com, | |gecko-bugs-nobody@fedorapro | |ject.org, | |jhorak@redhat.com, | |kengert@redhat.com, | |pjasicek@redhat.com Component|fontconfig |firefox Assignee|tagoh@redhat.com |gecko-bugs-nobody@fedorapro | |ject.org
i18n-bugs@lists.fedoraproject.org