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

Issue 703562 link

Starred by 1 user

Issue metadata

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



Sign in to add a comment

Negative left side bearing in GPOS (net zero lsb) leads to bounding box overflow

Project Member Reported by drott@chromium.org, Mar 21 2017

Issue description

What steps will reproduce the problem?
(1) Open test-20170320-simple.html with font SidebearingsG1-Regular.ttf in the same folder, which activates the ss05 feature, which moves the left side bearing of the H 90 units to the left, and reduces the advance width by 180 units. The afkdo feature 
file for the font looks like this when ss05 is active:

pos H <-90 0 -180 0>;

(2) Observe highlighted bounding box when click in the "Henry..." paragraph
(3) Zoom in, magnify left stem of H

What is the expected result?
Left stem of H should not protrude outside the bounding box.

What happens instead?
Left stem of H protrudes slightly left outside the bounding box.

$ hb-shape --features="ss05=1" SidebearingsG1-Regular.ttf "Henry"
[H=0@-90,0+472|e=1+496|n=2+547|r=3+366|y=4+467]

Behdad, what's the @-90 in terms of hb_buffer_t info? Would we need to do something like a shifting operation on all the subsequent advance coordinates? Would that be Blink's job in your opinion, or could we set HarfBuzz to a mode where all advance coordinates get normalized to be 0 based?

 
 
test-20170320-simple.html
1.3 KB View Download
SidebearingsG1-Regular.ttf
103 KB Download
H_protruding.png
3.3 MB View Download

Comment 1 by drott@chromium.org, Mar 21 2017

Summary: Negative left side bearing in GPOS (net zero lsb) leads to bounding box overflow (was: Negative left side bearing leads to bounding box overflow)
As a clarification, the negative lsb is applied to a lsb that was 90 before, so the net lsb is 0. 

Comment 2 by drott@chromium.org, Mar 21 2017

Additional screenshots provided by Laurence.

leftbounds-firefox.png
10.4 KB View Download
leftbounds-chrome.png
8.5 KB View Download

Comment 3 by behdad@chromium.org, Apr 19 2017

HarfBuzz output looks correct.

> Behdad, what's the @-90 in terms of hb_buffer_t info?

That's x_offset.

> Would we need to do something like a shifting operation on all the subsequent advance coordinates?

No.  That's what the -180 adjustment to x_advance is for.

I don't think there's a problem here. The border you see is drawn because of contenteditable, and it has no room, so it draws one/two pixel on each side of the box.  No wonder it overlaps with content!  Just remove contenteditable and add proper border and you see there's no problem.

Comment 4 by behdad@google.com, May 22 2017

Dominik, can you check this out again?  I think it's a non-issue.
The border is because of contenteditable, but the position of the H is not affected if the divs are not contenteditable. See attached HTML and PNG.
test-20170525-simple-not-contenteditable.html
1.2 KB View Download
leftbounds-chrome-not-contenteditable.png
71.1 KB View Download
In other words, contenteditable does not affect positioning of the H. When you say "add proper border" what do you mean?
Project Member

Comment 7 by sheriffbot@chromium.org, May 25 2018

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.

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

Comment 8 by e...@chromium.org, May 29 2018

Status: Assigned (was: Untriaged)

Comment 9 by behdad@chromium.org, May 30 2018

Dominik?

Sign in to add a comment