1002910 - Firefox renders U+FFFC OBJECT REPLACEMENT CHARACTER as  [obj] but Chrome discards it

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[Chris Peterson [:cpeterson]]

Attachment: Screenshot.png

This Hacker News story's title includes U+FFFC OBJECT REPLACEMENT CHARACTER, which Firefox renders as  [obj] but Chrome discards it.

https://news.ycombinator.com/item?id=7663462

Similar bug 947588 concluded that control characters should be discarded and not rendered as hexboxes unless the `-moz-control-character-visibility: visible` CSS style is set. But I'm not sure whether U+FFFC OBJECT REPLACEMENT CHARACTER should be considered a "control character".

Comment 1

[Henri Sivonen (:hsivonen)]

(In reply to Chris Peterson (:cpeterson) from comment #0)
> But I'm not sure whether U+FFFC OBJECT
> REPLACEMENT CHARACTER should be considered a "control character".

It is in the same block together with U+FFFD, which is clearly a displayable character. Yet, the Unicode Standard says:
"The U+FFFC object replacement character is used as an insertion point for objects located within a stream of text. All other information about the object is kept out-side the character data stream. Internally it is a dummy character that acts as an anchor point for the object’s formatting information. In addition to assuring correct placement of an object in a data stream, the object replacement character allows the use of general stream-based algorithms for any textual aspects of embedded objects."

So its described use seems a lot closer to non-printable nature than the use of U+FFFD. It's annoying that the spec doesn't say if U+FFFC should be printable in applications that don't use for tracking the placement of an object.

Comment 2

[Jonathan Kew [:jfkthame]]

(In reply to Chris Peterson (:cpeterson) from comment #0)
> Created attachment 8414215 [details]
> Screenshot.png
> 
> This Hacker News story's title includes U+FFFC OBJECT REPLACEMENT CHARACTER,
> which Firefox renders as  [obj] 

Just to clarify: AFAICS, how Firefox renders it will depend on your available fonts - it's simply drawn using the page's specified font-family, or whatever font we find during fallback if the specified font-family (list) doesn't support it.

Since several common fonts, including Times New Roman and Courier New, have a small boxed "[OBJ]" glyph for this character, it's very likely that's what you'll see, but Gecko isn't giving it any special treatment.

Incidentally, I notice that in Safari and Chrome (at least on OS X), where it is suppressed on the web page, it still shows up as the [OBJ] glyph in the context menu, if you select that range and right-click on it.

(In reply to Henri Sivonen (:hsivonen) from comment #1)
> (In reply to Chris Peterson (:cpeterson) from comment #0)
> > But I'm not sure whether U+FFFC OBJECT
> > REPLACEMENT CHARACTER should be considered a "control character".
> 
> It is in the same block together with U+FFFD, which is clearly a displayable
> character. Yet, the Unicode Standard says:
> "The U+FFFC object replacement character is used as an insertion point for
> objects located within a stream of text. All other information about the
> object is kept out-side the character data stream. Internally it is a dummy
> character that acts as an anchor point for the object’s formatting
> information. In addition to assuring correct placement of an object in a
> data stream, the object replacement character allows the use of general
> stream-based algorithms for any textual aspects of embedded objects."
> 
> So its described use seems a lot closer to non-printable nature than the use
> of U+FFFD. It's annoying that the spec doesn't say if U+FFFC should be
> printable in applications that don't use for tracking the placement of an
> object.

It's categorized in UnicodeData.txt as So (Symbol, Other), just like U+FFFD; it is not categorized as Cf, like the immediately-preceding interlinear annotation control characters, for example.

IMO, we're correct to simply treat it as a (displayable) symbol if it occurs.

Comment 3

[Chris Peterson [:cpeterson]]

Based on comment 1 and comment 2, displaying U+FFFC seems to be the spec'd behavior, even if it is not "user friendly".