1148903 - C0 and C1 characters are rendered incorrectly

Status: RESOLVED FIXED

(Core :: Graphics: Text, defect)

Description

[KOLANICH]

Attachment: The test I have used.

User Agent: Mozilla/5.0 (Windows NT 6.3; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20150320202338

Steps to reproduce:

I have created a font making C0 and C1 characters visible.


Actual results:

These chars are not rendered.


Expected results:

They should be rendered.

Comment 1

[j.j.]

Your testcase works somehow in Presto Opera 12 if you apply styling like
{letter-spacing:1em}

Does it work in any other browser?

Comment 2

[Jonathan Kew [:jfkthame]]

Firefox currently follows (approximately, at least) the behavior specified in the current LCWD of CSS Text[1], which says that:

# Control characters (Unicode class Cc) other than tab (U+0009), line feed (U+000A), and carriage return
# (U+000D) are ignored for the purpose of rendering.

(In certain contexts -- e.g. View Source windows, and elements with editable text -- we instead make the control characters visible.)

The CSS WG has agreed to modify this, as indicated by the latest ED text[2], where we find:

# Control characters (Unicode category Cc) other than tab (U+0009), line feed (U+000A), and carriage
# return (U+000D) must be rendered as a visible glyph and otherwise treated as any other character of
# the Other Symbols (So) general category and Common script.

but I'm not sure exactly when this change of behavior will be implemented; the plan, AIUI, is to coordinate the change across multiple implementations.

Currently, you can make control characters visible in Firefox by setting the property "-moz-control-character-visibility: visible;" on the element concerned (this is what we apply to editable text and view-source windows).

(Note, however, that the "codes" font in the testcase is rejected due to a problem in the 'maxp' table; open the Web Console and Shift-Reload the page to check for error messages.)


[1] http://www.w3.org/TR/css-text-3/#white-space-processing
[2] http://dev.w3.org/csswg/css-text-3/#white-space-processing

Comment 3

[KOLANICH]

Now they are visible, but FF still doesn't use the glyphs from the font.

Comment 4

[KOLANICH]

Attachment: Updated test

Have updated the test using -moz-control-character-visibility

Comment 5

[KOLANICH]

>(Note, however, that the "codes" font in the testcase is rejected due to a problem in the 'maxp' table; open the Web Console and Shift-Reload the page to check for error messages.)
Now googling

Comment 6

[Jonathan Kew [:jfkthame]]

On second look, the console message about the maxp table (downloadable font: maxp: bad max_zones: 0 (font-family: "codes" style:normal weight:normal stretch:normal src index:0) source: data:font/otf;base64,....) is a non-fatal warning, so the font should still be usable despite this error.

However, Gecko doesn't actually render those character codes as graphic characters from the current font; instead, it renders "hexbox" representations. IIRC, this is because there are fonts around that incorrectly map those character codes to entirely unrelated glyphs, or to invisible glyphs; so if we simply pass them to the font (like normal printable characters), the result may be thoroughly misleading.

Perhaps, though, we could allow them to be rendered through webfonts, on the assumption that if the author has explicitly provided a font that covers these codepoints, that's what should be used.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Allow control characters to be rendered by user fonts

Here's a possible patch, if we want to allow this (as suggested in comment 6). WDYT?

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 8585237 [details] [diff] [review]
Allow control characters to be rendered by user fonts

Review of attachment 8585237 [details] [diff] [review]:
-----------------------------------------------------------------

OK, but this seems like a really low-priority bug to me.

Comment 9

[Jonathan Kew [:jfkthame]]

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #8)
> OK, but this seems like a really low-priority bug to me.

Agreed; it's also a really trivial patch. :)

Comment 10

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1098a252ea57

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1098a252ea57