Closed
Bug 1148903
Opened 10 years ago
Closed 10 years ago
C0 and C1 characters are rendered incorrectly
Categories
(Core :: Graphics: Text, defect)
Tracking
()
RESOLVED
FIXED
mozilla40
Tracking | Status | |
---|---|---|
firefox40 | --- | fixed |
People
(Reporter: kolan_n, Assigned: jfkthame)
Details
(Keywords: testcase)
Attachments
(2 files, 1 obsolete file)
38.12 KB,
text/html
|
Details | |
2.48 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
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.
Your testcase works somehow in Presto Opera 12 if you apply styling like
{letter-spacing:1em}
Does it work in any other browser?
Keywords: testcase
Version: 36 Branch → Trunk
Component: Layout: Text → Graphics: Text
Assignee | ||
Comment 2•10 years ago
|
||
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
Now they are visible, but FF still doesn't use the glyphs from the font.
Have updated the test using -moz-control-character-visibility
Attachment #8585163 -
Attachment is obsolete: true
>(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
Assignee | ||
Comment 6•10 years ago
|
||
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.
Assignee | ||
Comment 7•10 years ago
|
||
Here's a possible patch, if we want to allow this (as suggested in comment 6). WDYT?
Attachment #8585237 -
Flags: review?(roc)
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.
Attachment #8585237 -
Flags: review?(roc) → review+
Assignee | ||
Comment 9•10 years ago
|
||
(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. :)
Assignee: nobody → jfkthame
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Assignee | ||
Comment 10•10 years ago
|
||
Comment 11•10 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox40:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in
before you can comment on or make changes to this bug.
Description
•