New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 655154 link

Starred by 3 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-11-28
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Missing text run intercepts for upright glyphs in vertical text

Project Member Reported by drott@chromium.org, Oct 12 2016

Issue description

Blink's painting code rotates upright in vertical text TextBlobs CCW before drawing. 

The way we position glyphs in TextBlobs for upright glyphs in vertical text we cannot compute getTextIntercepts for those blobs correctly. E.g. CJK characters and Emoji do not rotate in vertical text. See GlyphBufferBloberizer in Font.cpp

We calculate glyph positions for the text blob underneath each other, down from the baseline. the getTextIntercepts Skia function follows the baseline and computes the intercepts for where the upper part of the first glyph crosses the baseline.  

I am attaching an image rendered from a modified Chrome that does not to the SkCanvas transformation before drawing the upright-in-vertical TextBlobs. This demonstrate what kind of intercepts are incorrectly calculated.

So for now, I need to skip those TextBlobs, until we have found a solution to calculate those correctly.

Florin, do you have any suggestions of how to modify the Font.cpp painting code in order to address this? Or do we need an API on the TextBlobs to define the baseline somehow?

 

Comment 1 by drott@chromium.org, Oct 12 2016

intercepts_vertical_text_modified_chrome.png
191 KB View Download
I'm having a bit of trouble wrapping my head around what the underline is expected to look like for upright vertical text.  Do you happen to have an example png lying around? :)

Yes, unfortunately that rotation is not playing nicely with text blobs and the bloberizer is hacking around it.  I recall at the time we considered adding per-run rotation info to text blobs, but gave up on it for some reason (either decided that upright vertical was rare enough not to worry about it, or there were other complications, I don't recall).

If we resurrected that idea, and instead of rotating the canvas we would add rotation info to each text blob run, do you think that would provide sufficient info for Skia to compute the correct intercepts?

Comment 3 by drott@chromium.org, Oct 13 2016

> I'm having a bit of trouble wrapping my head around what the underline is expected to look like for upright vertical text.  Do you happen to have an example png lying around? :)

I don't have one, but I could construct one if needed. The Japanese glyph sequence in vertical should be rotated counterclockwise (it is not in this image, because I disable the rotation), so that it follows the aaag... sequence downwards. The intersects between the CJK glyphs and the vertical underline should then be clipped. The CJK glyphs are a little bit more "left" then the Latin glyphs, due to the baseline shift alphabetic-ideographic.

> If we resurrected that idea, and instead of rotating the canvas we would add rotation info to each text blob run, do you think that would provide sufficient info for Skia to compute the correct intercepts?

This sounds to me like it would be enough to follow a different baseline direction for calculating the intersects, but I am not sure whether we should push the rotation down in the stack in this way. Either way, we need to handle upright in vertical somehow, ideally in a clean way. Maybe Cary can take a look and comment?



Comment 4 by drott@chromium.org, Oct 13 2016

I imagine it should look something like this. (photoshopped)

vertical_skip_ink.png
44.5 KB View Download

Comment 5 by drott@chromium.org, Nov 16 2016

Cc: kojii@chromium.org

Comment 6 by kojii@chromium.org, Nov 19 2016

Coincidentally WebKit has the bug http://wkb.ug/128518
Project Member

Comment 7 by sheriffbot@chromium.org, Nov 20 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 8 by drott@chromium.org, Nov 20 2017

Status: Available (was: Untriaged)
Still applies, but remains low prio.

Comment 9 by drott@chromium.org, Nov 20 2017

Owner: ----
Project Member

Comment 10 by sheriffbot@chromium.org, Nov 20

Status: Untriaged (was: Available)
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
NextAction: 2018-11-28
@drott - please retriage
The NextAction date has arrived: 2018-11-28
Owner: drott@chromium.org
Status: Assigned (was: Untriaged)

Sign in to add a comment