Bug 688692

Summary:	Wrong encoding of backslash and yen
Product:	[Fedora] Fedora	Reporter:	Paul Flo Williams <paul>
Component:	motoya-lmaru-fonts	Assignee:	Akira TAGOH <tagoh>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	14	CC:	fonts-bugs, i18n-bugs, tagoh
Target Milestone:	---
Target Release:	---
Hardware:	noarch
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-03-18 02:05:45 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 Paul Flo Williams 2011-03-17 18:06:16 UTC

Description of problem:

U+005C is supposed to be character REVERSE SOLIDUS (backslash), but in this font it shows as a Yen symbol. U+00A5 YEN SIGN doesn't have a glyph at all.

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. pango-view --font "MotoyaLMaru 48" -t "[\]"
  
Actual results:

Shows left square bracket, yen sign, right square bracket.

Expected results:

Should show left square bracket, backslash, right square bracket.

Comment 1 Akira TAGOH 2011-03-18 02:05:45 UTC

This is because of a bit complicated and historical reason in Japanese. if you don't like it, you could use different Japanese fonts to see a correct glyphs on U+005C etc.

Comment 2 Nicolas Mailhot 2011-03-18 09:41:22 UTC

1. there's no reason not to have yen at its correct codepoint U+00A5
2. having U+005C with non-standard glyph makes the font non-interoperable. That will hurt us sooner or later. Japanese people are not the only ones which have to migrate from legacy encodings. If upstream is not willing to fix this the font priority must be set low enough so correct unicode fonts preempt this

Comment 3 Akira TAGOH 2011-03-18 12:32:24 UTC

(In reply to comment #2)
> 1. there's no reason not to have yen at its correct codepoint U+00A5

Sure. both U+005C and U+00A5 has a yen sign. since ISO 646 defines some areas including 0x5C as the national variants, we had a yen sign assigned to 0x5C. as a result, we missed a way to see if it's a yen sign as "yen" or a control code. we have two mapping tables to convert from the legacy encodings. 1) 0x5C <-> U+005C 2) 0x5C <-> U+00A5. 1) would helps for programing languages say. 2) would helps for data. and put a yen sign to U+005C was a workaround to keep a compatible for legacy systems, but anyway.

> 2. having U+005C with non-standard glyph makes the font non-interoperable. That
> will hurt us sooner or later. Japanese people are not the only ones which have
> to migrate from legacy encodings. If upstream is not willing to fix this the
> font priority must be set low enough so correct unicode fonts preempt this

It is. I have no plans to make this default for Japanese at all.

Comment 4 Paul Flo Williams 2011-03-23 21:24:32 UTC

(In reply to comment #3)
> (In reply to comment #2)
> > 1. there's no reason not to have yen at its correct codepoint U+00A5
> 
> Sure. both U+005C and U+00A5 has a yen sign.

Perhaps I'm missing something, but this command

pango-view --font 'MotoyaLMaru 48' -t '¥' -o yen.png -q

shows me a vertical bar. The Unicode cmap table doesn't have an entry for U+00A5, so I'm guessing that the vertical bar is some kind of fallback.

Comment 5 Akira TAGOH 2011-04-08 06:27:02 UTC

Sure. I see some glyphs at Latin-1 Supplement is being messed up on Motoya fonts. please file a separate bug for that.

Thanks,

Comment 6 Akira TAGOH 2011-04-21 11:17:30 UTC

just FYI, Bug#698599 and Bug#698601 filed for that.