@damieng This is unlike the other tests in this file in that none of the
assertions pass. Maybe you could take a look at some point to enable at
least some coverage on Windows for this?
...because the only possible scenario when a logical position in a text
node cannot be found is when the requested pixel position is exactly at
the end of the node.
Also, remove specs testing RTL behavior. They don’t work as of today,
and I think we need a better approach to handle them, that doesn’t
solely rely on the DOM, but actually takes into account that e.g. (0, 0)
is the rightmost character on a right-to-left string.
Instead, determine the need for a DOM update in the component before
measuring with the lines yardstick, and break `updateSync` into two
explicit pre- and post-measurement phases.
This commit fixes what seems to be a bug in Chromium.
When measuring lines (and with a special character sequence), it could happen
that Range(0, 0). getBoundingClientRect().width reports a number greater than 0.
This seems to happen when the font size is smaller than 12px and it's probably
due to subpixel font scaling. To solve it we've explicitly included a guard
clause that prevents this problem to happen.
For certain font sizes, enabling `textRendering: optimizeLegibility` caused a
bunch of measurement-related issues. You can reproduce it by setting the following in your stylesheet:
```
atom-text-editor {
font-size: 14px;
text-rendering: optimizeLegibility;
}
```
Although I wanted to defer subpixel font scaling to a later moment, it seems
like Chrome needs to have it enabled in order to properly support the
"legibility" path for text rendering. (I guess this is part of the reason why
the Chromium team enabled it by default at some point in the past.)
We have shifted the responsibility of orchestrating state updates and
measurements to the yardstick. The presenter still needs to be updated to make
use of these new capabilities.
