[Win][Uniscribe] Remove the code rounding off glyph advances and offsets for system fonts ComplexTextController::collectComplexTextRunsForCharacters has the following code. > // Match AppKit's rules for the integer vs. non-integer rendering modes. > if (!font->platformData().isSystemFont()) { > advance = roundf(advance); > offsetX = roundf(offsetX); > offsetY = roundf(offsetY); > } This was added by r18359. See also: Bug#228363 Comment#2
(In reply to Fujii Hironori from comment #0) > This was added by r18359. No. This code was added by r23462.
(In reply to Fujii Hironori from comment #1) > No. This code was added by r23462. More precisely r23199 and r23154.
Created attachment 434405 [details] WIP patch
In WinCairo, this patch makes the following ref tests fail. fast/text/emoji-gender-3.html [ ImageOnlyFailure ] fast/text/emoji-gender-4.html [ ImageOnlyFailure ] fast/text/emoji-gender-5.html [ ImageOnlyFailure ] fast/text/emoji-gender-6.html [ ImageOnlyFailure ] fast/text/emoji-gender-8.html [ ImageOnlyFailure ] This is caused by the difference of how to get glyph advance between simple text code path and complex text code path. The simple text code path is using cairo_scaled_font_glyph_extents, the complex text code path is using Uniscribe to get the glyph advance. I think the simple text code path also should use Uniscribe. However, the argument of Font::platformWidthForGlyph is Glyph not UChar. Uniscribe (ScriptShape) takes a string, not glyphs. Another approach is implementing Font::applyTransforms with Uniscribe (Bug 228363). However, Font::applyTransforms is not applied to a single character. This approach needs some modification to WidthIterator.
I confirmed WinCairo doesn't have the comment#4 problem if it always uses the complex text code path. In the complex text code path, it consistently uses Uniscribe.
Created attachment 434495 [details] WIP patch The WinCairo problem is fixed by reimplementing Font::platformWidthForGlyph with GetCharABCWidthsI.
<rdar://problem/81500144>