[SCM] WebKit Debian packaging branch, debian/experimental, updated. upstream/1.3.3-10851-g50815da

xji at chromium.org xji at chromium.org
Wed Dec 22 17:45:21 UTC 2010


The following commit has been merged in the debian/experimental branch:
commit 5fa610d499df774999dad28c057f8765d25575fc
Author: xji at chromium.org <xji at chromium.org@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
Date:   Tue Nov 30 00:12:47 2010 +0000

    2010-11-29  Xiaomei Ji  <xji at chromium.org>
    
            Reviewed by David Hyatt.
    
            Fix tab overflow problem when alignment is not left.
            https://bugs.webkit.org/show_bug.cgi?id=25459
    
            I checked WordPad in Windows, TextEdit in Mac, OpenOffice, and Google doc.
            In all of them, (when the writing mode is horizontal) when the alignment is not
            left alignment, the length of tab is computed based on the tab's position
            relative to the left start of line, not based on the tab's position relative
            to the left edge of the document.
    
            WebKit should follow the same.
    
            The m_xPos in each TextRun should be relative to the left start of the line,
            not left start of its containing block (in right alignment and center alignment,
            left start of the line is not the same as left start of the containing block).
            So, when the text is drawn, the width of tab is consistent with the width
            computed in RenderBlock::computeInlineDirectionPositionsForLine().
    
            I did not test vertical writing mode, but I think the same rule should apply.
    
            Test: fast/dom/tab-in-right-alignment.html
    
            * platform/graphics/TextRun.h:
            * rendering/InlineTextBox.cpp:
            (WebCore::InlineTextBox::textPos):
            * rendering/InlineTextBox.h:
    2010-11-29  Xiaomei Ji  <xji at chromium.org>
    
            Reviewed by David Hyatt.
    
            Fix tab overflow problem when alignment is not left.
            https://bugs.webkit.org/show_bug.cgi?id=25459
    
            I checked WordPad in Windows, TextEdit in Mac, OpenOffice, and Google doc.
            In all of them, (when the writing mode is horizontal) when the alignment is not
            left alignment, the length of tab is computed based on the tab's position
            relative to the left start of line, not based on the tab's position relative
            to the left edge of the document.
    
            WebKit should follow the same.
    
            The m_xPos in each TextRun should be relative to the left start of the line,
            not left start of its containing block (in right alignment and center alignment,
            left start of the line is not the same as left start of the containing block).
            So, when the text is drawn, the width of tab is consistent with the width
            computed in RenderBlock::computeInlineDirectionPositionsForLine().
    
            I did not test vertical writing mode, but I think the same rule should apply.
    
            * fast/dom/tab-in-right-alignment-expected.txt: Added.
            * fast/dom/tab-in-right-alignment.html: Added.
            * platform/qt/Skipped:
    
    
    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@72847 268f45cc-cd09-0410-ab3c-d52691b4dbfc

diff --git a/LayoutTests/ChangeLog b/LayoutTests/ChangeLog
index 7c67244..b8065c9 100644
--- a/LayoutTests/ChangeLog
+++ b/LayoutTests/ChangeLog
@@ -1,3 +1,30 @@
+2010-11-29  Xiaomei Ji  <xji at chromium.org>
+
+        Reviewed by David Hyatt.
+
+        Fix tab overflow problem when alignment is not left.
+        https://bugs.webkit.org/show_bug.cgi?id=25459
+
+        I checked WordPad in Windows, TextEdit in Mac, OpenOffice, and Google doc. 
+        In all of them, (when the writing mode is horizontal) when the alignment is not
+        left alignment, the length of tab is computed based on the tab's position
+        relative to the left start of line, not based on the tab's position relative 
+        to the left edge of the document.
+
+        WebKit should follow the same.
+
+        The m_xPos in each TextRun should be relative to the left start of the line, 
+        not left start of its containing block (in right alignment and center alignment,
+        left start of the line is not the same as left start of the containing block).
+        So, when the text is drawn, the width of tab is consistent with the width 
+        computed in RenderBlock::computeInlineDirectionPositionsForLine().
+
+        I did not test vertical writing mode, but I think the same rule should apply.
+
+        * fast/dom/tab-in-right-alignment-expected.txt: Added.
+        * fast/dom/tab-in-right-alignment.html: Added.
+        * platform/qt/Skipped:
+
 2010-11-29  Simon Fraser  <simon.fraser at apple.com>
 
         Add Qt-specific result.
diff --git a/LayoutTests/fast/dom/tab-in-right-alignment-expected.txt b/LayoutTests/fast/dom/tab-in-right-alignment-expected.txt
new file mode 100644
index 0000000..38e0352
--- /dev/null
+++ b/LayoutTests/fast/dom/tab-in-right-alignment-expected.txt
@@ -0,0 +1,2 @@
+PASS
+PASS
diff --git a/LayoutTests/fast/dom/tab-in-right-alignment.html b/LayoutTests/fast/dom/tab-in-right-alignment.html
new file mode 100644
index 0000000..e6cd245
--- /dev/null
+++ b/LayoutTests/fast/dom/tab-in-right-alignment.html
@@ -0,0 +1,46 @@
+<!DOCTYPE html> 
+<html> 
+<head> 
+<meta http-equiv="Content-Type" content="text/html;charset=utf-8" >
+<script>
+    function log(str) 
+    {
+        var li = document.createElement("li");
+        li.appendChild(document.createTextNode(str));
+        var console = document.getElementById("console");
+        console.appendChild(li);
+    }
+    
+    onload = function() 
+    {
+        var div = document.getElementById("div");
+        var pre = document.getElementById("pre");
+        var rightOfClientBox = div.clientWidth + div.offsetLeft - 20; // 20 for right padding in 'div' and 'pre'.
+        if (window.textInputController) {
+            var caretRect = textInputController.firstRectForCharacterRange(0, 0);
+            var xOfRightmostCharacter = caretRect[0];
+            if (xOfRightmostCharacter > rightOfClientBox)
+                log("FAILED: rightmost character (at " + xOfRightmostCharacter + ") is beyond the right edge (" + rightOfClientBox + ") of client box");
+            else 
+                log("PASS");
+            caretRect = textInputController.firstRectForCharacterRange(1, 0);
+            if (caretRect[0] >= xOfRightmostCharacter)
+                log("FAILED: second rightmost character (at " + caretRect[0] + ") is on or beyond the right edge (" + rightOfClientBox + ") of client box");
+            else 
+                log("PASS");
+        }
+        if (window.layoutTestController)
+            div.style.display = "none";
+    }
+
+    if (window.layoutTestController)
+        layoutTestController.dumpAsText();
+
+</script>
+</head> 
+<body> 
+<div contenteditable id="div" dir="rtl" style="padding-right: 10px; border-width: 10px; width: 40ex;border: solid 1px;"><pre style="padding-right: 10px; border-width: 10px" id="pre">פורסם: 	24.04.09, 21:14</pre></div> 
+<ul id="console"></ul>
+</body> 
+</html> 
+ 
diff --git a/LayoutTests/platform/qt/Skipped b/LayoutTests/platform/qt/Skipped
index fe8ebae..c570c73 100644
--- a/LayoutTests/platform/qt/Skipped
+++ b/LayoutTests/platform/qt/Skipped
@@ -301,6 +301,7 @@ editing/inserting/insert-tab-003.html
 editing/inserting/insert-text-with-newlines.html
 # Missing textInputController.firstRectForCharacterRange()
 editing/inserting/caret-position.html
+fast/dom/tab-in-right-alignment.html
 
 # ---- to be reviewed
 editing/inserting/4278698.html
diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog
index 1b4c2f8..dbf3e72 100644
--- a/WebCore/ChangeLog
+++ b/WebCore/ChangeLog
@@ -1,3 +1,33 @@
+2010-11-29  Xiaomei Ji  <xji at chromium.org>
+
+        Reviewed by David Hyatt.
+
+        Fix tab overflow problem when alignment is not left.
+        https://bugs.webkit.org/show_bug.cgi?id=25459
+
+        I checked WordPad in Windows, TextEdit in Mac, OpenOffice, and Google doc. 
+        In all of them, (when the writing mode is horizontal) when the alignment is not
+        left alignment, the length of tab is computed based on the tab's position
+        relative to the left start of line, not based on the tab's position relative 
+        to the left edge of the document.
+
+        WebKit should follow the same.
+
+        The m_xPos in each TextRun should be relative to the left start of the line, 
+        not left start of its containing block (in right alignment and center alignment,
+        left start of the line is not the same as left start of the containing block).
+        So, when the text is drawn, the width of tab is consistent with the width 
+        computed in RenderBlock::computeInlineDirectionPositionsForLine().
+
+        I did not test vertical writing mode, but I think the same rule should apply.
+
+        Test: fast/dom/tab-in-right-alignment.html
+
+        * platform/graphics/TextRun.h:
+        * rendering/InlineTextBox.cpp:
+        (WebCore::InlineTextBox::textPos):
+        * rendering/InlineTextBox.h:
+
 2010-11-29  Mikhail Naganov  <mnaganov at chromium.org>
 
         Reviewed by Pavel Feldman.
diff --git a/WebCore/platform/graphics/TextRun.h b/WebCore/platform/graphics/TextRun.h
index 79b6cb3..dce5535 100644
--- a/WebCore/platform/graphics/TextRun.h
+++ b/WebCore/platform/graphics/TextRun.h
@@ -117,7 +117,10 @@ private:
     const UChar* m_characters;
     int m_len;
 
-    int m_xpos;
+    // m_xpos is the x position relative to the left start of the text line, not relative to the left
+    // start of the containing block. In the case of right alignment or center alignment, left start of
+    // the text line is not the same as left start of the containing block.
+    int m_xpos;  
     int m_padding;
 #if ENABLE(SVG)
     float m_horizontalGlyphStretch;
diff --git a/WebCore/rendering/InlineTextBox.cpp b/WebCore/rendering/InlineTextBox.cpp
index 575bdf2..d055185 100644
--- a/WebCore/rendering/InlineTextBox.cpp
+++ b/WebCore/rendering/InlineTextBox.cpp
@@ -1085,10 +1085,11 @@ unsigned InlineTextBox::caretMaxRenderedOffset() const
 
 int InlineTextBox::textPos() const
 {
+    // When computing the width of a text run, RenderBlock::computeInlineDirectionPositionsForLine() doesn't include the actual offset
+    // from the containing block edge in its measurement. textPos() should be consistent so the text are rendered in the same width.
     if (logicalLeft() == 0)
         return 0;
-    RenderBlock* blockElement = renderer()->containingBlock();
-    return logicalLeft() - blockElement->borderStart() - blockElement->paddingStart();
+    return logicalLeft() - root()->logicalLeft();
 }
 
 int InlineTextBox::offsetForPosition(int lineOffset, bool includePartialGlyphs) const
diff --git a/WebCore/rendering/InlineTextBox.h b/WebCore/rendering/InlineTextBox.h
index bc2219b..c97a061 100644
--- a/WebCore/rendering/InlineTextBox.h
+++ b/WebCore/rendering/InlineTextBox.h
@@ -119,7 +119,7 @@ public:
 private:
     virtual unsigned caretMaxRenderedOffset() const;
 
-    int textPos() const;
+    int textPos() const; // returns the x position relative to the left start of the text line.
 
 public:
     virtual int offsetForPosition(int x, bool includePartialGlyphs = true) const;

-- 
WebKit Debian packaging



More information about the Pkg-webkit-commits mailing list