289588 - Korean fillers displayed as spaces

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

[Erik van der Poel]

The Unicode character 0x1160 is a Korean "filler" that is supposed to be used
to transform nonstandard syllables to standard ones. However, the Windows
version of GFX currently has a simple implementation that looks up the Unicode
in any or all of the TrueType fonts, and uses a glyph found there to display
the character. This is fine for many Unicodes, but not this one, since some
fonts have an empty space for that character. Note that several neighboring
codepoints seem to have the same problem, even though they are not legal
Unicodes: U+115A..U+1160, U+11A3..U+11A7. There may be others. Careful!

Move this bug to GFX Windows if you wish, but file new bugs under the other
versions of GFX if you do so, since they may have similar problems.

This bug came from bug 279099 comment 239.

Comment 1

[Erik van der Poel]

Jungshik and Simon, what's the status of jamo and filler work?

Comment 2

[Neil Harris]

There are also similar display problems in the Linux implementation.

Comment 3

[Neil Harris]

I think the Korean fillers now have the default-ignorable Unicode property in the most recent versions of Unicode. 

See http://www.unicode.org/review/pr-5.html for a description of this property, which appears to mean something on the lines of "if you can't correctly render this character in some particular context, you should ignore it".

Comment 4

[Neil Harris]

Should this be in "core graveyard"?

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Is the bug still present in the new graphics backend in Firefox 3.0 and later?  If so, it should be moved out.

Comment 6

[Neil Harris]

Attachment: HTML fragment, tests rendering of U+1160 HANGUL JUNGSEONG FILLER

The text given contains the string "Here is a Korean filler character: (ᅠ)" repeated in a number of different fonts.

The bus still appears to be live, since U+1160 is still rendered as a space on my Firefox 3.5 / Debian Lenny machine, which already has some Korean fonts installed. 

The rendering of this text appears to be dependent on the set of fonts available on the machine, so font substitution probably plays a part in this. Adding more Korean fonts by installing ttf-unfonts-core made the problem go away; more work is needed to test the detailed interactions between the installed set of fonts, the requested font, and the displayed glyph.

Comment 7

[Neil Harris]

Attachment: Firefox 3.5 / Debian lenny rendering of above attachment

PNG image of rendering of HTML attachment 391910 [details] on Firefox 3.5 / Debian lenny, with some, but not all, Korean fonts installed

Comment 8

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Not sure whether this belongs in Gfx:thebes or layout:fonts&text

Comment 9

[Simon Montagu :smontagu]

On my OS X system U+1160 is rendered by the missing-glyph fallback. On Windows it is rendered as a space in every line of the test case, even though I have at least some Korean font support (there are no missing glyphs at http://alanwood.net/unicode/hangul_jamo.html).

I think we should generalize this issue to something like "conform to http://unicode.org/faq/unsup_char.html", either in this bug or a new one. There are probably other bugs that would depend on it too.

Comment 10

[Neil Harris]

I've filed a new bug for the above: Bug 546013 - "Text rendering of unsupported characters should conform to http://unicode.org/faq/unsup_char.html"