325 bytes, text/html; charset=utf-8
1.20 KB, patch
|Details | Diff | Splinter Review|
5.51 KB, patch
|Details | Diff | Splinter Review|
69.93 KB, image/png
442 bytes, text/html
Created attachment 674557 [details] Test case In certain cases (such as when included in a page title), Firefox can wind up synthesising a bold variant of the Apple Color Emoji font. As the font is made up of images instead of normal font data, the result is that the images appear smeared instead of just wider. Safari and TextEdit (at least) refuse to show/make a bold variant, or at least render it in a much softer manner.
Attachment #674557 - Attachment mime type: text/plain → text/html
Attachment #674557 - Attachment mime type: text/html → text/html; charset=utf-8
Another testcase, showing both synthetic bolding and italics at various sizes: http://people.mozilla.org/~jdaggett/tests/poo-waterfall.html
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Alex from comment #0) > Created attachment 674557 [details] > Test case > > In certain cases (such as when included in a page title), Firefox can wind > up synthesising a bold variant of the Apple Color Emoji font. As the font is > made up of images instead of normal font data, the result is that the images > appear smeared instead of just wider. > > Safari and TextEdit (at least) refuse to show/make a bold variant, or at > least render it in a much softer manner. TextEdit doesn't implement synthetic bolding; if there's no actual bold face in the selected font family, notice that the "B" button and the Format/Font/Bold menu command are actually disabled. Safari does synthetic bold using a "smear" technique, similar to Firefox. The key difference that it always uses just a one-pixel "smear", regardless of the font size, whereas Firefox varies the amount of "smearing" in proportion to the font size being used. The Safari option has the advantage that it never leads to such broad (and sometimes ugly-looking) smearing, but on the other hand it means that the distinction between "regular" and "bold" becomes progressively less noticeable as the font size increases. With large fonts (headlines, etc), it's often almost imperceptible, which rather defeats the object of using bold at all. IMO, many of the emoji glyphs actually look pretty decent with the synthetic-bold effect; it can "smear" some fine details, but in general it appears mainly as a "shadow-like" highlight on the left of the glyph, and doesn't mess up the main body of the image. (It would be much worse with a very "busy" image that has a lot of thin lines and interior gaps, but that doesn't seem to be typical.) We could consider slightly reducing the smear factor we use, but I don't think we should revert to a Safari-like single pixel at all sizes, because of the problem of boldness becoming imperceptible for large fonts. So I don't really know what a "perfect" solution here would look like. We could refrain from fake-bolding the emoji font altogether, but that doesn't seem right either - if an author chooses to apply a bold weight, we should render that in a visible way.
Created attachment 676123 [details] [diff] [review] make synthetic bolding a bit less severe at large sizes Here's a small patch that makes the synthetic-bold effect less extreme at large sizes, while still maintaining an element of scaling so that we don't degenerate into imperceptible single-pixel "bold" when it is applied to huge fonts.
Created attachment 676124 [details] [diff] [review] make synthetic bolding a bit less severe at large sizes Oops, exported the wrong patch! Here's the intended one.
Created attachment 676125 [details] [diff] [review] make synthetic bolding a bit less severe at large sizes Argh, total mq fail. :( *This* is it. Sorry about the noise.
Attachment #676125 - Flags: review?(jdaggett)
jdaggett, review ping?
Comment on attachment 676125 [details] [diff] [review] make synthetic bolding a bit less severe at large sizes The width of the synthetic bolding is really a separate issue. I makes no sense at all to me to be doing synthetic bolding of emoji, given that these characters are color graphics and not outlines. Synthetic bolding is a hack to begin with, we shouldn't be extending that hack unless absolutely necessary. I think we should just flag the Apple Color Emoji font as not being a font for which synthetic bolding is used. We're going to need a flag like that for the font-synthesis property anyways.
I much prefer a flag to disable synthetic bolding on Apple Color Emoji.
Created attachment 681027 [details] [diff] [review] suppress synthetic bolding for the Apple Color Emoji font OK, here's a patch that suppresses fake bold for the Color Emoji font. FTR, I'm not really convinced this is the right thing to do - if authors apply bold styling, I think we should do something visible with it wherever possible, and the fake-bold effect on the emoji doesn't look particularly awful - but I don't care enough to fight about it at this point. Note, however, that there's nothing to prevent Apple (or anyone) creating additional fonts that use similar color bitmaps; if that starts to happen, this approach won't scale very well. But detecting the bitmap table isn't a good answer either, as there might be color bitmaps only for a few glyphs out of a larger font.
Attachment #681027 - Flags: review?(jdaggett)
Comment on attachment 681027 [details] [diff] [review] suppress synthetic bolding for the Apple Color Emoji font Looks fine. If there end up being more fonts that use the Apple embedded PNG glyph format then we'll rethink how to do this but fundamentally I don't think it's a good idea to define an arbitrary effect as the moral equivalent of "bold". I think mimic'ing what Webkit does is fine.
Attachment #681027 - Flags: review?(jdaggett) → review+
(In reply to John Daggett (:jtd) from comment #10) > Comment on attachment 681027 [details] [diff] [review] > suppress synthetic bolding for the Apple Color Emoji font > > Looks fine. If there end up being more fonts that use the Apple embedded > PNG glyph format then we'll rethink how to do this but fundamentally I don't > think it's a good idea to define an arbitrary effect as the moral equivalent > of "bold". I think mimic'ing what Webkit does is fine. But this patch *doesn't* mimic what webkit does. As pointed out in comment 2, webkit applies its synthetic-bold effect to the color emoji glyphs, just like any other font for which no true bold face is available. This is easier to see if you don't use enormous font sizes: data:text/html;charset=utf-8,regular%20%F0%9F%98%84%20%<b>%F0%9F%98%84%20bold The only difference between our *current* behavior and webkit's is that we scale the synthetic-bold effect in proportion to font size, whereas webkit always overprints with a single-px offset. This means webkit's "bold" becomes imperceptible at huge sizes (whether for emoji or normal text), whereas ours maintains a visible distinction from non-bold. Overall, I think our approach is superior; the first patch here would help to mitigate the criticism that it makes for ugly "smeared" glyphs at large sizes, but switching it off entirely (as per the second patch) does *not* make us "mimic webkit".
Comment on attachment 676125 [details] [diff] [review] make synthetic bolding a bit less severe at large sizes So if we want to mimic webkit w.r.t. the emoji font, we'd do better to take the first patch (continue to apply synth-bold, just make it less aggressive at large sizes) rather than the second (turn it off entirely).
Attachment #676125 - Flags: review- → review?(jdaggett)
Ping: jdaggett (and joe?) - in view of comments 11-13, do you want to reconsider which patch should be r+'d and landed here?
Marking needinfo? in hopes of getting an answer to the above.
I agree with Jonathan, but will defer to what John wants to do in the end.
Comment on attachment 676125 [details] [diff] [review] make synthetic bolding a bit less severe at large sizes Argh, I thought Webkit wasn't bolding at all but I see you're correct, they are by an imperceptible amount. However, I think the issue remains the same, in the context of pictogram glyphs I think there's is very little meaning to "bold" in this context, just as there is no sense to say "color: red" for these glyphs either. I just don't see smudge effects in any way correlating with the semantics of "bold". So r- from me, but if someone wants to override this, I'm not going to squabble.
(In reply to John Daggett - out until 27 Dec (:jtd) from comment #17) > However, I think the issue > remains the same, in the context of pictogram glyphs I think there's > is very little meaning to "bold" in this context By that argument, we should similarly refrain from synthetic-bolding other "pictogram" fonts like Zapf Dingbats, Apple Symbols, Wingdings-#, and Webdings, not to mention the "icon webfonts" that are becoming popular on various sites - FontAwesome, Modern Pictograms, Typicons, and more. But we don't - we (and Safari) go ahead and "smear-bold" those pictograms just like any other glyphs. Even though it doesn't usually look all that great: data:text/html;charset=utf-8,<p style="font-family:zapf dingbats">%E2%9C%86%E2%9C%8D%E2%9C%A0%E2%9D%A6<b>%E2%9C%86%E2%9C%8D%E2%9C%A0%E2%9D%A6 And I think that's reasonable behavior. If designers don't like the result, they can (and should) refrain from applying bold font-weight values to these fonts. But for us to try and second-guess which glyphs should or shouldn't be subject to the effect, and hard-code that into gecko, is a rathole I'd much prefer to avoid. And to single out Apple Color Emoji for exceptional treatment, while ignoring other icon/pictogram/emoji fonts, is an ugly and unjustified hack. So I still think it's better *not* to do the Color Emoji-specific hack, but to mitigate the perceived ugliness at large font sizes (for all fonts, not just this one) by reducing the amount by which we "smear" at larger sizes. Joe? Should we solicit additional opinions from Roc/Jeff/someone?
Cmon, smearing a glyph from an outline font is consistent with what a font designer would do when designing a bold face. Smearing a color pictogram just doesn't look "bold", it just looks ugly. There's no consistency issue here, why are we debating this so much? The current behavior is ugly, it's a minor issue but we should fix it. There's no reason to be wasting cycles smearing when it doesn't achieve any desired effect.
(In reply to John Daggett - out until 27 Dec (:jtd) from comment #19) > Cmon, smearing a glyph from an outline font is consistent with what a font > designer would do when designing a bold face. Not the font designers I've known! > Smearing a color pictogram > just doesn't look "bold", it just looks ugly. No worse than, say, data:text/html;charset=utf-8,<p style="font:72px zapf dingbats">✆<b>✆</p> In most cases the color emoji fare much better under "smearing" than this. > There's no consistency issue > here, why are we debating this so much? Because adding code to special-case the Apple Color Emoji font is a hack that won't scale to cover other similar cases, and there's no compelling aesthetic or cross-browser-consistency argument that would justify it. Whereas adjusting the degree by which we "smear" at larger sizes will provide a consistent improvement across all the fonts where this effect gets applied, whether textual or pictographic, color or monochrome. (See also bug 728436.)
Created attachment 719414 [details] Other issues While checking the rendering after bug 728436 landed, I noticed some other issues. It seems that then "double struck" the Emoji glyphs render darker (In Safari and Firefox, probably an underlying issue), so I tried a RGBA font colour (I remembered a presentation that showed that caused issues) and I noticed that when the glyphs are rendered normally they ignore the alpha value, while when they get synthetic bolding they do respect the alpha value (And apparently also suffer from extra clipping). Should I file a new bug for these issues?
Attachment #719414 - Attachment mime type: text/plain → text/html
Yes, please. One issue per bug makes things easier to track. Thanks!
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: a day ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.