Bug 698599

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:
Embargoed:

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):
motoya-lmaru-fonts-1.00-0.1.20100928git.fc14.noarch

How reproducible:
always

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 ***