Bug 108929 – Text shadow sometimes clipped unexpectedly

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Tobi Reif]

Open
http://www.tobireif.com/non_site_stuff/text_shadow_example/logo/
in Chrome. The text shadows are fragmented. Screenshot:
http://www.tobireif.com/non_site_stuff/text_shadow_example/chrome_text_shadow.png

Compare to the correct rendering in Firefox (on Mac IIRC). Screenshot:
http://www.tobireif.com/non_site_stuff/text_shadow_example/firefox_text_shadow.png

The font's proportions might be untypical, but Firefox applies the text shadows correctly. It would be great if WebKit/Chrome/Safari would apply the correct shadow as well, no matter which font format they choose.

Observable in Chrome on Mac, Win and Lin.
(For example Mac OS 10.7 and 10.8, Windows 7, and Ubuntu 12.04.)
Also in Safari (eg on Mac OS).

Also see this bug report:
http://code.google.com/p/chromium/issues/detail?id=173635

[Tobi Reif]

Are you able to reproduce this?

[Tobi Reif]

I installed the latest WebKit (Mac OS):  "Safari" "Version 6.0.2 (7536.26.17, 537+)".

Like Chrome and Safari, it renders
http://www.tobireif.com/non_site_stuff/text_shadow_example/logo/
with fragmented text shadows (please compare to the rendering by Firefox on Mac OS).

[Tobi Reif]

Created attachment 187311 [details]
reduces test case

Reduced test case.

[Tobi Reif]

Also see the Chrome report:
http://code.google.com/p/chromium/issues/detail?id=173635

[Alexander Shalamov]

It looks like glyph has invalid bounding box. When shadows are drawn, invalid clip area is calculated. I've opened ttf font in editor and fixed glyph width, so there is no clipping and result output is the same as expected.

[Alexander Shalamov]

Created attachment 193500 [details]
output with fixed glyph widht

[Tobi Reif]

Alexander, thanks for looking into this issue!

Firefox renders the lettering & shadows correctly. Would it be incorrect to expect WebKit to do the same? Does Firefox render the glyphs as intended because it behaves correctly, or because it behaves differently from what it's expected to do?

[Deirdre Saoirse Moen]

<rdar://problem/13114852>

[Tobi Reif]

Works now in Chrome.

The text shadow block still is fragmented in Safari 9.

[Tobi Reif]

I hope you can make it work in Safari (like the Chrome/Chromium team did :) ).

[Tobi Reif]

Works as is in Chrome and Firefox, please make it work in Safari.

[Tobi Reif]

I tried to make it work in Safari by trying stuff in Inkscape, in the font file itself (SVG source), and using FontForge. No luck.

It wold be great if Safari could render the shadows correctly,
as do Chrome and Firefox.

Safari renders the glyphs correctly
(see http://tobireif.com/centerslate/ -> the smaller version),
so it could also render the shadows correctly.

[Simon Fraser (smfr)]

Created attachment 278526 [details]
Slightly simpler test case

[Tobi Reif]

On
http://tobireif.com/centerslate/
I now have only WOFF - no SVG fonts anymore.
(The issue is still there in Safari.)

Perhaps you want to update the summary.

[Myles C. Maxfield]

This is because the character draws way (to the left) outside its layout box.

[Myles C. Maxfield]

Created attachment 278656 [details]
Reduction

[Myles C. Maxfield]

Created attachment 278657 [details]
Reduction

[Myles C. Maxfield]

This is because of a mismatch between CoreGraphics and CSS. In particular, CoreGraphics doesn't support drawing multiple shadows on text.

We work around that by drawing the text multiple times, one for each shadow. However, we want to make sure that the original text isn't also drawn multiple times, so we bump up the shadow offsets so the text and the shadow don't intersect, and then we clip out the original text (so only the shadow remains).

Unfortunately, this clipping requires knowing where the visual extent of the text is, which WebKit currently has trouble with. In particular, we often use layout extents in lieu of visual extents, which is a problem when the glyphs draw outside of their layout boxes. In this case, it causes us to think the text shadow is much smaller than it really is, so our clipping operation clips to an area which is too small.

A quick and dirty hack would be to inflate this clip rect by an arbitrary amount (and bump up the shadow offset accordingly). However, that doesn't actually solve the problem; it just makes the problem occur less often. The real solution is for WebKit to be properly educated about the difference between layout extents and visual extents, which is a fairly large task.

Therefore, I'd like to mark this as a dup of (an extremely old) bug 6274.

*** This bug has been marked as a duplicate of bug 6274 ***

[Myles C. Maxfield]

Here are some things to not if you want to work around this:

1. This bug does not occur for the last shadow, because the clipping I mentioned above doesn't need to occur for the last shadow (we paint the real text at the same time as the last shadow)

2. It looks like you are using this as a logogram. You can implement this with an SVG graphic (the <use> element should be helpful) and use standard image-replacement techniques to preserve accessibility.

[Myles C. Maxfield]

(In reply to comment #19)
> Here are some things to not if you want to work around this:
> 
> 1. This bug does not occur for the last shadow, because the clipping I
> mentioned above doesn't need to occur for the last shadow (we paint the real
> text at the same time as the last shadow)
> 
> 2. It looks like you are using this as a logogram. You can implement this
> with an SVG graphic (the <use> element should be helpful) and use standard
> image-replacement techniques to preserve accessibility.

*** some things to note if

[Myles C. Maxfield]

(In reply to comment #20)
> (In reply to comment #19)
> > Here are some things to not if you want to work around this:
> > 
> > 1. This bug does not occur for the last shadow, because the clipping I
> > mentioned above doesn't need to occur for the last shadow (we paint the real
> > text at the same time as the last shadow)
> > 
> > 2. It looks like you are using this as a logogram. You can implement this
> > with an SVG graphic (the <use> element should be helpful) and use standard
> > image-replacement techniques to preserve accessibility.
> 
> *** some things to note if

Oh, also, if you can modify the font, you can increase the "C" character's advance to include the entire visual extents of the glyph.

You can probably preserve centering if you do the same thing with whichever glyph is all the way on the other side of the line of text.

[Myles C. Maxfield]

Simon prefers that we do the hack. Reopening.

[Myles C. Maxfield]

Created attachment 278774 [details]
Patch

[Myles C. Maxfield]

Comment on attachment 278774 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=278774&action=review

> LayoutTests/fast/text/multiple-text-shadow-overflow-layout-rect.html:12
> +<div style="position: relative">

I should probably add an explanation of what is going on.

[Dean Jackson]

Comment on attachment 278774 [details]
Patch

It would be nice if your SVG file included an example of the "a" glyph, possibly inside a <rect> element that shows where the font bounds are defined.

[Myles C. Maxfield]

Committed r200807: <http://trac.webkit.org/changeset/200807>

[Tobi Reif]

Thanks everyone for fixing this / helping to fix this!

Is there a way for me to confirm that the issue has been resolved for my page?
https://tobireif.com/centerslate/

I have Safari Technology Preview version "9.1.1 (11601.6.10, 11602.1.25)".
Ideally I could ask it to update itself, so that I can check my page in the latest (eg nightly) WebKit/Safari.

On https://tobireif.com/centerslate/ there still is this note:
'The rendering of the "3D block" (CSS text shadows) is broken in Safari as of 2016-05 (reported 2013-02).'

I'd be very happy to remove it as soon as the latest stable Safari (and Mobile Safari) renders it as intended / as Firefox and Chrome do.

And sincere best wishes for https://bugs.webkit.org/show_bug.cgi?id=6274 , which seems to have been described as the more fundamental issue.

[Myles C. Maxfield]

(In reply to comment #27)
> Thanks everyone for fixing this / helping to fix this!
> 
> Is there a way for me to confirm that the issue has been resolved for my
> page?
> https://tobireif.com/centerslate/
> 
> I have Safari Technology Preview version "9.1.1 (11601.6.10, 11602.1.25)".
> Ideally I could ask it to update itself, so that I can check my page in the
> latest (eg nightly) WebKit/Safari.
> 
> On https://tobireif.com/centerslate/ there still is this note:
> 'The rendering of the "3D block" (CSS text shadows) is broken in Safari as
> of 2016-05 (reported 2013-02).'
> 
> I'd be very happy to remove it as soon as the latest stable Safari (and
> Mobile Safari) renders it as intended / as Firefox and Chrome do.
> 
> And sincere best wishes for https://bugs.webkit.org/show_bug.cgi?id=6274 ,
> which seems to have been described as the more fundamental issue.

This bug appears fixed on https://tobireif.com/centerslate/ using the latest nightly build (Scroll down on https://webkit.org/downloads/ to see "WebKit Nightly").

[Tobi Reif]

Tried it in nightly "WebKit-SVN-r200821.dmg" Safari "Version 9.1 (11601.5.17.1)",
no luck :| The shadows are still cut off in the Nightly I downloaded.

Nightly keeps on saying "A new nightly build of WebKit is available! Please take a moment to download and install it before continuing your testing.", which I did twice. (It also wants to use some ~"confidential information stored in my keychain".)

[Myles C. Maxfield]

(In reply to comment #29)
> Tried it in nightly "WebKit-SVN-r200821.dmg" Safari "Version 9.1
> (11601.5.17.1)",
> no luck :| The shadows are still cut off in the Nightly I downloaded.
> 
> Nightly keeps on saying "A new nightly build of WebKit is available! Please
> take a moment to download and install it before continuing your testing.",
> which I did twice. (It also wants to use some ~"confidential information
> stored in my keychain".)

Oh, yeah, the nightlies don't get along well with System Integrity Protection. Even though the nightly says it's the latest version, it's actually using system WebKit :(

There is a workaround listed at https://trac.webkit.org/wiki/WebKitNightlyElCapWorkaround

Alternatively, I've disabled SIP on my system (where the bug appears fixed).

[Tobi Reif]

The nightly setup is no intricate, sorry :|

> the bug appears fixed

Thanks again! If the logo/shadows look the same as in Chrome and Firefox, it is fixed indeed.

What counts for my visitors is latest stable Safari, so I'll remove the note as soon as the latest stable Safari (and Mobile Safari) renders it as intended.

[Tobi Reif]

It now works in Safari Technology Preview.

Thanks all!

I appended this to the note on https://tobireif.com/centerslate/ :
"Update 2016-05-27: Works in Safari Technology Preview."

When I flip forth and back between Chrome and Safari Tech Preview I see slight differences, even regarding the width of parts of glyphs, it seems. But I didn't ensure a 100% sound test, and don't know whether these slight differences are to be fixed or not.

The issue I had reported was much more grave, and I'm really happy that you fixed it. Thanks again.

[Myles C. Maxfield]

(In reply to comment #32)
> It now works in Safari Technology Preview.
> 
> Thanks all!
> 
> I appended this to the note on https://tobireif.com/centerslate/ :
> "Update 2016-05-27: Works in Safari Technology Preview."
> 
> When I flip forth and back between Chrome and Safari Tech Preview I see
> slight differences, even regarding the width of parts of glyphs, it seems.
> But I didn't ensure a 100% sound test, and don't know whether these slight
> differences are to be fixed or not.
> 
> The issue I had reported was much more grave, and I'm really happy that you
> fixed it. Thanks again.

Text rendering is implemented in completely different ways with completely different libraries in Chrome / WebKit / Firefox / Edge, and is expected to not give pixel-exact results. We don't consider this a bug - instead it's a way to allow for innovation in text-rendering!