[Bug 688692] Wrong encoding of backslash and yen

bugzilla at redhat.com bugzilla at redhat.com
Fri Mar 18 12:32:24 UTC 2011

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


--- Comment #3 from Akira TAGOH <tagoh at redhat.com> 2011-03-18 08:32:24 EDT ---
(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.

Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

More information about the fonts-bugs mailing list