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.
This might be a issue with Firefox's fonts handling.
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
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
I wonder if it could not be FreeType?
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.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
I reported this upstream in https://bugzilla.mozilla.org/show_bug.cgi?id=1580099