Bug 698599 - mapping on Latin-1 supplement is broken
Summary: mapping on Latin-1 supplement is broken
Status: CLOSED DUPLICATE of bug 681808
Alias: None
Product: Fedora
Classification: Fedora
Component: motoya-lmaru-fonts
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Akira TAGOH
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2011-04-21 11:12 UTC by Akira TAGOH
Modified: 2011-07-20 05:41 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-07-20 05:41:10 UTC
Type: ---

Attachments (Terms of Use)

Description Akira TAGOH 2011-04-21 11:12:28 UTC
Description of problem:
even if the font itself doesn't have a glyph being assigned to the certain code point, other one appears there and totally get scrambled at the Latin-1 supplement.

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

How reproducible:

Steps to Reproduce:
1.run gucharmap
2.select MotoyaLMaru
3.see Latin-1 supplement

Comment 1 Paul Flo Williams 2011-04-21 11:57:07 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.

Comment 2 Akira TAGOH 2011-04-26 08:08:07 UTC
Right. this simply works for a workaround though, I guess the real issue should be in freetype as the rendering library.

Comment 3 Akira TAGOH 2011-07-20 05:37:50 UTC
There seems the apple roman support code in fontconfig and getting rid of those code fixes this issue.

Comment 4 Akira TAGOH 2011-07-20 05:41:10 UTC

*** This bug has been marked as a duplicate of bug 681808 ***

Note You need to log in before you can comment on or make changes to this bug.