roeln / chromacheck Goto Github PK

TTF CBDT font fails (tested using NotoColorEmoji.ttf).
Converted to woff, it shows up: https://rawgit.com/yincrash/43341c4848949b0e6534277cfe70d950/raw/07e192c9f2e646413a099b41181b6cc43e772c53/cbdt-test.html

However, loading that one CBDT font meant CBDT fonts following it failed to render. On that test page, I also included your ChromaCheck CBDT font.

Additionally, CBDT font prevented a COLR font following it to not render:
https://rawgit.com/yincrash/43341c4848949b0e6534277cfe70d950/raw/07e192c9f2e646413a099b41181b6cc43e772c53/cbdt-test-no-emoji.html

This also means any regular windows 10 emoji fallback to a b&w version as seen here: https://rawgit.com/yincrash/43341c4848949b0e6534277cfe70d950/raw/07e192c9f2e646413a099b41181b6cc43e772c53/cbdt-test-only-cbdt.html

And just to make sure COLR fonts load properly, a control using the ChromaCheck COLR font:
https://rawgit.com/yincrash/43341c4848949b0e6534277cfe70d950/raw/07e192c9f2e646413a099b41181b6cc43e772c53/cbdt-test-only-colr.html

Maybe it would be worthwhile to implement a visual inspection on the ChromaCheck page in addition to the automated SVG check? Yet the https://pixelambacht.nl/chromacheck/old/ works fine! So maybe I'm just going crazy.

Regression!

Uncaught SyntaxError: identifier starts immediately after numeric literal chromacheck-min.js:6:5505

i only tested the unminified version on github

Now it's a simple function, see if we can adhere to conventions

• Move original to src dir
• Move index.html to demo dir?

The inlined WOFFs simply refuse to load in Edge 18 and the Insider Preview.

The glyphs in the test font should snuggle up to each other, but Safari sticks about 4 pixels of space between them. There are no spaces in the text string.

Example:

Font is base64 inlined, but is still loaded async. So it might not have finished loading when we draw the image, resulting in false negatives. (Only seems to happen in Safari/OSX?)

Options: Fontfaceobserver? Simple finite loop?

See https://youtu.be/Mho5DIT6MWM?t=2471

But the old test does

IE (not Edge) will throw a SCRIPT5022: SecurityError when running ChromaCheck. This is because writing an SVG to the canvas taints the canvas, disallowing ChromaCheck to look at the drawn pixels:

Once a canvas has been tainted, you can no longer pull data back out of the canvas. For example, you can no longer use the canvas toBlob(), toDataURL(), or getImageData() methods; doing so will throw a security error.

See also this StackOverflow issue.

We draw an SVG to the canvas to work around an older Firefox issue. Maybe drop the SVG workaround? Or skip the SVG method for IE/non-Fx?

Hi, I don't know a lot of the technical details here, but on my Linux machine I have copied Apple Color Emoji (which definitely worked) and I believe Segoe UI Emoji (not sure if I'm misremembering, have to try again). Firefox supported SVG in Opentype first, and will support the Google/Noto format without any major issues in Firefox 44 or 45.

So basically as I said in the title, Firefox can show all four formats, in full color and everything.

I feel like Firefox's wide emoji support isn't widely known. If you need me to test this more, or help make this more reproducible/debuggable, I'm interested in contributing some time toward that. It'd be nice to have a definitive resource such as this to test emoji support. Just needs to be updated a bit, I think!

visiting the web page with a qt6 webengine browser results in this message in stderr:

js: Canvas2D: Multiple readback operations using getImageData are faster with the willReadFrequently attribute set to true. See: https://html.spec.whatwg.org/multipage/canvas.html#concept-canvas-will-read-frequently

This seems to come from /usr/lib64/libQt6WebEngineCore.so.6 .

On refresh it does work. It also doesn't apply the "test failed" classes.

Or, if for some reason canvas/svg/font won't work otherwise, stick it in the DOM in an unobtrusive manner (e.g. hiding it)

Hi.

In README.md it says this:

Firefox (on OSX?) has a bug that prevents color glyphs from being used on canvas with fillText(). This has been fixed for locally installed fonts but still needs more fixin' for fonts loaded through @font-face. ChromaTest works around this by sticking the font in an SVG image, and then drawing that image on canvas.

It says the status is Resolved:Fixed over at [bugzilla.mozilla.org](bug 1237640), but it says it needs fixing in your README.md.

I am pretty sure ChromaCheck is 100% accurate, but every time I see that in the README I feel like I missed something and can't be sure anymore. Some clarity would be helpful. ChromaCheck working 100% has some impact on whether I put in the effort to maintain my own testing setup for color font support.

P.S. Incidentally: a minor typo in that sentence:

ChromaTest works around this by . . .

Because they're all OpenType standards now. Except sbix :)

First and foremost ChromaCheck should see if individual color formats work. To avoid confusing render engines when there's more than one format in the font, we need to separate all four fonts, like was done for CDBT/CBLC.
Also see:
#8
#21

Current implementation uses the transform attribute on the test glyph's SVG element, which is not officially supported. The reason for this transformation is to convert SVG's axis system (top of letter is at y=-500) to OpenType axis (top of letter is at y=500).

Against spec, Firefox does do the transform, resulting in okay looking glyphs. But stricter implementations might not, causing the glyph to be shown outside its bounding box, resulting in a false negative on the test.

Hi @RoelN

It looks like your website is down…! https://pixelambacht.nl/chromacheck/
because your domain is in quarantine 😢

In the meantime I forked your repo and made it available via GitHub Pages https://jolg42.github.io/ChromaCheck/demo.html 😉

In MacOS since 10.10, Safari does show the sbix table from fonts loaded with @fontface. I put together a small sample page: files.glyphsapp.com/test_page.html It should show a colourful 'C'.

The test page does say that sbix is not supported on Safari even through it is.

Edit: current situation in a nutshell:

CBDT spec proposal stated no glyf table should be present in CBDT/CBLC fonts. Current spec doesn't say anything about this. Fonts built on the proposal specs will fail in browsers with OTS, as the absence of a glyf table makes OTS reject them. In current FreeType implementations (Chrome on Android), these glyfless fonts work, and the color glyphs are shown.

For CBDT/CBLC fonts with a glyf table the glyph in the CBDT/CBLC table will be ignored, effectively always rendering the normal glyph, making it impossible to get the color glyph.

https://drafts.csswg.org/css-fonts-4/#font-palette-control

Also see Chris Lilley's example: https://youtu.be/Mho5DIT6MWM?t=2471

The ttx file has an empty <colorPalettes> table in there, which was proposed very early on but is superseded by the CPAL table. So no need to look into that. More info

So it'll be a multitude of 0x50 like the rest :)

CBDT/CBLC glyph will show on Chrome on Linux, Android and ChromeOS, but only when there's no glyf table present in the font. There might also be a priority issue with the sbix table as mentioned here.

The only solution is to make a separate font. (Maybe make a separate font for the other formats as well?)

Clean up font, remove unused tables. Maybe use pyftsubset for further slimming down. Also see Bram Stein's Nanofont.

It can now be based on the actual test instead of duplicating CSS and using DOM elements