[BUG] Webkit font rendering (spacing / icon fonts)

[olee]

Context:

• Playwright Version: 1.1.1
• Operating System: Windows
• Browser: WebKit 1269

Bug description
When trying to test screenshots with webkit, I noticed that font rendering looks a bit weird and no font icons were rendered.
The icon font rendering can be easily tested by starting the playwright webkit browser (eg. AppData\Local\ms-playwright\webkit-1269\Playwright.exe) directly and navigating for example to https://material.io/resources/icons
An interesting behavior I could observe was that when I set font-kerning: normal on font icons (eg. on .material-icons), some icons appeared, some stayed hidden and some showed incorrect icons (eg. keyboard_arrow_down was rendered as keyboard icon only).

Also it seems while font-kerning: auto seems to enable it by default in other browsers, this does not seem to happen at all in the playwright webkit.

Without font-kerning: normal

With font-kerning: normal

How it should like like eg. in Chrome:

Any ideas on how to solve this?

[fujii]

WebKit bug:
201214 – [Win][Uniscribe] Material icons containing underscore or numbers aren't shown because ScriptItemize splits them apart
https://bugs.webkit.org/show_bug.cgi?id=201214

[fujii]

And, this:

201213 – [Win] Material icons font aren't shown because ligature doesn't work
https://bugs.webkit.org/show_bug.cgi?id=201213

[olee]

Can someone explain, why this this works in Safari, but not in the playground WebKit browser?
I know that Safari probably adds some stuff on top of WebKit, so is a fix for this probably part of this was well?
I tried finding some information regarding this, but could not find anything

[pavelfeldman]

I addressedit a while ago, forgot to close the bug, so it should work in playwright@next. The reason behind this is that WebKit relies upon platform-specific APIs when rendering text, accessing network, etc. That's a WebKit philosophy. Windows port uses Uniscribe for that and it was not happy about Material font trick where a 3d_rotation text was supposed to render as a single ligature glyph. Windows api was aggressively tokenizing it into digits, _ and letters, so the ligature was never coming together.

[pavelfeldman]

@olee ^^

[olee]

Ok, now I get loading font icons when starting the playwright browser manually and go to my page, but when it is launched from code, no icon fonts will render at all:

    const browser = await playwright.webkit.launch({ headless: false });
    const context = await browser.newContext();
    const page = await context.newPage();
    await page.goto('https://material.io/resources/icons');

[olee]

Yes I can confirm. When you let playwright start with the code above, the font icons are not loaded/rendered correctly.
However, if you then open the devtools in webkit and reload the page, they show up.

[arjunattam]

I'm facing a similar issue with WebKit on GitHub Actions, with Linux (build) and Windows (build). WebKit on macOS (build) is working. Link to app.

Sharing relevant screenshots from build artifacts below:

Webkit on macOS

Webkit on Windows

Webkit on Ubuntu

[JoelEinbinder]

Whats happening here is that we set our useragent to mimic Safari, and google fonts sends us a woff2 file which we cant process. But opening the inspector resets the useragent to be windows, and google fonts sends a ttf file that we can parse.

Options:

1. Add woff2 support to our windows build to match mac safari. I'm looking into how hard this will be now.
2. Stop lying in our user agent. This might break tests/sites that don't expect to see webkit for windows out in the wild.

[JoelEinbinder]

The linux issue is something more specific. I can only reproduce it in WPE, not in GTK. The font loads, appears to parse fine, and then the text does not render. The text has some metrics, but they appear to be wrong. It looks to be something specific to the 'Material Design' font, as there is a LayoutTest for woff2 that passes for playwright+WPE. WPE and GTK share the same font rendering code for the most part, so I don't know where a difference could have creeped in.

1. Add woff2 support to our windows build to match mac safari. I'm looking into how hard this will be now.
   Woff2 just changes the compression over woff1.

On GTK/WPE:
woff2 file -> libwoff -> freetype
woff file -> custom code -> freetype

On Windows:
woff2 file -> bail out
woff -> custom code -> cairo

On Mac/iOS:
woff2 file -> CoreText
woff file -> CoreText

The very recent version of FreeType (2.10.0) supports Woff2 out of the box, and should also support windows. Moving windows to use FreeType instead of cairo, and bumping the freetype, could get woff2 support. Another option would be to port libwoff or an equivalent to windows and keep sending the fonts to cairo.