| Summary: | mapping on Latin-1 supplement is broken | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Akira TAGOH <tagoh> |
| Component: | motoya-lmaru-fonts | Assignee: | Akira TAGOH <tagoh> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | aalam, fonts-bugs, i18n-bugs, paul, tagoh |
| Target Milestone: | --- | Keywords: | i18n |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-07-20 05:41:10 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Akira TAGOH
2011-04-21 11:12:28 UTC
I'm not convinced that this is a bug in these fonts, although it is possible to work around it by changing them. Lmaru and lcedar contain Format 0 and Format 4 cmap subtables. The format 0 subtable is for Mac byte mappings, and the Format 4 is for Windows Unicode BMP mappings. Examining the Format 4 subtable shows that there are only 11 glyphs mapped between U+0080 and U+00FF. However, gucharmap shows many more Lmaru glyphs here. I suspect that gaps in this area are being filled in incorrectly by also using the Format 0 subtable. Removing the cmap format 0 subtable corrects this problem, and all available Lmaru glyphs are shown in their proper locations, as far as I've been able to judge. Unfortunately, I have only managed to construct the font with work-around on RHEL5, as fonttools/ttx on Fedora has a bug which prevents Lmaru being rebuilt from a TTX file (bug #688713). (My apologies Akira; I've been trying to solve that one before filing the bugs you asked me to file on these fonts.) So, I think that the _real_ bug is present in whichever component of the font stack uses both subtables to place random glyphs at odd encodings, but I don't know where to assign that one. Right. this simply works for a workaround though, I guess the real issue should be in freetype as the rendering library. There seems the apple roman support code in fontconfig and getting rid of those code fixes this issue. *** This bug has been marked as a duplicate of bug 681808 *** |