Bug 108929 - Text shadow sometimes clipped unexpectedly
Summary: Text shadow sometimes clipped unexpectedly
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P3 Major
Assignee: Myles C. Maxfield
URL: http://www.tobireif.com/non_site_stuf...
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-02-05 03:38 PST by Tobi Reif
Modified: 2016-05-27 10:32 PDT (History)
12 users (show)

See Also:


Attachments
reduces test case (7.09 KB, application/zip)
2013-02-08 06:52 PST, Tobi Reif
no flags Details
output with fixed glyph widht (29.71 KB, image/png)
2013-03-18 01:30 PDT, Alexander Shalamov
no flags Details
Slightly simpler test case (12.64 KB, application/zip)
2016-05-10 13:40 PDT, Simon Fraser (smfr)
no flags Details
Reduction (2.08 KB, application/zip)
2016-05-11 13:26 PDT, Myles C. Maxfield
no flags Details
Reduction (2.04 KB, application/zip)
2016-05-11 13:27 PDT, Myles C. Maxfield
no flags Details
Patch (6.42 KB, patch)
2016-05-12 15:58 PDT, Myles C. Maxfield
dino: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobi Reif 2013-02-05 03:38:03 PST
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
Comment 1 Tobi Reif 2013-02-08 06:15:59 PST
Are you able to reproduce this?
Comment 2 Tobi Reif 2013-02-08 06:24:53 PST
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).
Comment 3 Tobi Reif 2013-02-08 06:52:38 PST
Created attachment 187311 [details]
reduces test case

Reduced test case.
Comment 4 Tobi Reif 2013-02-08 08:53:06 PST
Also see the Chrome report:
http://code.google.com/p/chromium/issues/detail?id=173635
Comment 5 Alexander Shalamov 2013-03-18 01:29:21 PDT
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.
Comment 6 Alexander Shalamov 2013-03-18 01:30:11 PDT
Created attachment 193500 [details]
output with fixed glyph widht
Comment 7 Tobi Reif 2013-03-18 04:10:02 PDT
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?
Comment 8 Deirdre Saoirse Moen 2013-03-19 21:55:42 PDT
<rdar://problem/13114852>
Comment 9 Tobi Reif 2015-10-17 02:38:29 PDT
Works now in Chrome.

The text shadow block still is fragmented in Safari 9.
Comment 10 Tobi Reif 2015-10-21 02:50:38 PDT
I hope you can make it work in Safari (like the Chrome/Chromium team did :) ).
Comment 11 Tobi Reif 2016-01-19 04:40:39 PST
Works as is in Chrome and Firefox, please make it work in Safari.
Comment 12 Tobi Reif 2016-05-04 03:33:48 PDT
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.
Comment 13 Simon Fraser (smfr) 2016-05-10 13:40:28 PDT
Created attachment 278526 [details]
Slightly simpler test case
Comment 14 Tobi Reif 2016-05-11 00:49:27 PDT
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.
Comment 15 Myles C. Maxfield 2016-05-11 13:20:48 PDT
This is because the character draws way (to the left) outside its layout box.
Comment 16 Myles C. Maxfield 2016-05-11 13:26:05 PDT
Created attachment 278656 [details]
Reduction
Comment 17 Myles C. Maxfield 2016-05-11 13:27:37 PDT
Created attachment 278657 [details]
Reduction
Comment 18 Myles C. Maxfield 2016-05-12 12:17:30 PDT
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 ***
Comment 19 Myles C. Maxfield 2016-05-12 12:20:05 PDT
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.
Comment 20 Myles C. Maxfield 2016-05-12 12:20:22 PDT
(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
Comment 21 Myles C. Maxfield 2016-05-12 12:25:45 PDT
(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.
Comment 22 Myles C. Maxfield 2016-05-12 15:53:17 PDT
Simon prefers that we do the hack. Reopening.
Comment 23 Myles C. Maxfield 2016-05-12 15:58:18 PDT
Created attachment 278774 [details]
Patch
Comment 24 Myles C. Maxfield 2016-05-12 16:45:03 PDT
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.
Comment 25 Dean Jackson 2016-05-12 16:51:02 PDT
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.
Comment 26 Myles C. Maxfield 2016-05-12 18:54:51 PDT
Committed r200807: <http://trac.webkit.org/changeset/200807>
Comment 27 Tobi Reif 2016-05-13 02:07:16 PDT
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.
Comment 28 Myles C. Maxfield 2016-05-13 08:34:06 PDT
(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").
Comment 29 Tobi Reif 2016-05-13 09:14:45 PDT
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".)
Comment 30 Myles C. Maxfield 2016-05-13 09:47:55 PDT
(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).
Comment 31 Tobi Reif 2016-05-13 09:54:39 PDT
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.
Comment 32 Tobi Reif 2016-05-27 00:34:11 PDT
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.
Comment 33 Myles C. Maxfield 2016-05-27 10:32:51 PDT
(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!