[Webkit-unassigned] [Bug 25459] Regression(?): tabs in not-left alignment erroneously overflows

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 13 16:09:21 PST 2010


https://bugs.webkit.org/show_bug.cgi?id=25459


Xiaomei Ji <xji at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #75829|0                           |1
        is obsolete|                            |




--- Comment #27 from Xiaomei Ji <xji at chromium.org>  2010-12-13 16:09:21 PST ---
Created an attachment (id=76462)
 --> (https://bugs.webkit.org/attachment.cgi?id=76462&action=review)
test case for Mac port

Previous fix brings the consistency between RenderBlock::computeInlineDirectionPositionsForLine() and Font::drawSimpleText(). And it fixed the problem when the line can fit in the containing block (when containing block's available width is greater then the total logical width of the line).

But there are 2 other problems:

1. In the case of writing direction is RTL, wide line should overflow to the left. So, we need to add logicalLeft adjustment when text alignment is LEFT or RIGHT in RenderBlock::computeInlineDirectionPositionsForLine(). For example:

        case RIGHT:
        case WEBKIT_RIGHT:
            if (style()->isLeftToRightDirection()) {
                ......
            } else {
                if (totalLogicalWidth > availableLogicalWidth && trailingSpaceRun) {
                    trailingSpaceRun->m_box->setLogicalWidth(max(0, trailingSpaceRun->m_box->logicalWidth() - totalLogicalWidth + availableLogicalWidth));
                    totalLogicalWidth -= trailingSpaceRun->m_box->logicalWidth();
+                  logicalLeft +=  availableLogicalWidth - totalLogicalWidth;
                } else
                    logicalLeft += availableLogicalWidth - totalLogicalWidth;
            }
            break;


2. TAB width computation is not consistent between RenderBlock::findNextLineBreak() and RenderBlock::computeInlineDirectionPositionsForLine()/ Font::drawSimpleText().

Given the following example: "ABCDE: \topqrst uvwx" in RTL block, where capital letter stands for Hebrew letter.
Let's assume the logical width of "ABCDE: " is 62, logical width of "opqrst" is 86, tab width is 48, and the width of block is 183.

The character width computation in RenderBlock::findNextLineBreak() follows logical order. So, the width of "\t" will be: "48 - mod(62, 48)" = 34,
and "ABCDE: \topqrst" can fit in one line.

After line break is found, bidi run will be generated on the line. Then, logical width and logical left are computed for each InlineBox in 
RenderBlock::computeInlineDirectionPositionsForLine().

The logical width computation in RenderBlock::computeInlineDirectionPositionsForLine() (and Font::drawSimpleText()) follows visual order between text runs and logical order inside one text run. The 1st visual text run in the above line is "opqrst", and the 2nd is "ABCDE: \t". So, the width of "\t" will be 
"48 - mod(86 + 62, 48)" = 44. Same when drawing text.

In the end, the above line overflowed left (although it should fit in).

I am thinking to compute the logical width of each InlineBox in RenderBlock::computeInlineDirectionPositionsForLine() following *logical* order of text runs.
And besides logical left in InlineBox, we will need a new data member: logical offset (offset of the box in logical order), which will replace textPos() as the x position of text run and is used in "\t" width computation.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list