Bug 157118 – [Cocoa] Initial advances don't work in LTR text

• Status: NEW
• Component: New Bugs

[Myles C. Maxfield]

[Cocoa] Initial advances in the complex text path are not handled correctly when they occur at the beginning of an element

[Myles C. Maxfield]

Created attachment 277579 [details]
Patch

[Build Bot]

Comment on attachment 277579 [details]
Patch

Attachment 277579 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/1232385

New failing tests:
fast/text/complex-first-glyph-with-initial-advance.html

[Build Bot]

Created attachment 277583 [details]
Archive of layout-test-results from ews103 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 277579 [details]
Patch

Attachment 277579 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/1232395

New failing tests:
fast/text/complex-first-glyph-with-initial-advance.html

[Build Bot]

Created attachment 277584 [details]
Archive of layout-test-results from ews107 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 277579 [details]
Patch

Attachment 277579 [details] did not pass ios-sim-ews (ios-simulator-wk2):
Output: http://webkit-queues.webkit.org/results/1232404

New failing tests:
fast/text/complex-first-glyph-with-initial-advance.html

[Build Bot]

Created attachment 277586 [details]
Archive of layout-test-results from ews125 for ios-simulator-wk2

The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews125  Port: ios-simulator-wk2  Platform: Mac OS X 10.11.4

[Build Bot]

Created attachment 277588 [details]
Archive of layout-test-results from ews116 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews116  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Myles C. Maxfield]

Created attachment 278053 [details]
Patch

[Build Bot]

Comment on attachment 278053 [details]
Patch

Attachment 278053 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/1263765

New failing tests:
fast/ruby/ruby-expansion-cjk-4.html

[Build Bot]

Created attachment 278056 [details]
Archive of layout-test-results from ews101 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews101  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 278053 [details]
Patch

Attachment 278053 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/1263769

New failing tests:
fast/ruby/ruby-expansion-cjk-4.html

[Build Bot]

Created attachment 278057 [details]
Archive of layout-test-results from ews107 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 278053 [details]
Patch

Attachment 278053 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/1263790

New failing tests:
fast/ruby/ruby-expansion-cjk-4.html

[Build Bot]

Created attachment 278060 [details]
Archive of layout-test-results from ews113 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews113  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Darin Adler]

Comment on attachment 278053 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=278053&action=review

> Source/WebCore/platform/graphics/mac/ComplexTextController.cpp:162
> +    if (m_complexTextRuns.isEmpty())
> +        return;
> +
>      if (!m_isLTROnly) {
>          m_runIndices.reserveInitialCapacity(m_complexTextRuns.size());
>  
>          m_glyphCountFromStartToIndex.reserveInitialCapacity(m_complexTextRuns.size());
>          unsigned glyphCountSoFar = 0;
> -        for (unsigned i = 0; i < m_complexTextRuns.size(); ++i) {
> +        for (auto& complexTextRun : m_complexTextRuns) {
>              m_glyphCountFromStartToIndex.uncheckedAppend(glyphCountSoFar);
> -            glyphCountSoFar += m_complexTextRuns[i]->glyphCount();
> +            glyphCountSoFar += complexTextRun->glyphCount();
>          }
>      }
>  
> -    m_runWidthSoFar = m_leadingExpansion;
> +    m_runWidthSoFar = m_leadingExpansion + m_complexTextRuns[0]->initialAdvance().width;

Is it OK to have m_runWidthSoFar be 0 rather than m_leadingExpansion when m_complexTextRuns is empty? That seems to be a change in behavior.

[Myles C. Maxfield]

Created attachment 278090 [details]
WIP