[css-fonts] Display gaiji as text if glyphs are supported

[stantonmarcum]

Authors (particularly in east-asian languages) tend to use images to represent rare and uncommon characters. These images are commonly called gaiji images. Use of gaiji in content causes several problems which include:

• Image may look blurry at larger font sizes
• Alignment of image baseline with the text baseline
• Font in image may not match the base text

Authors don't trust all browsers and readers to represent these glyphs correctly, so even though it may work in one application they will continue to use the image as long as the lowest common denominator does not support the glyph.

In order to break this deadlock, a property could be added that allows for a UA to display the alt-text of an image if those glyphs are supported by the UA. If the glyphs are not supported, the UA will display the image as normal.

Currently, it seems an appropriate place to add this could be as a new keyword to "content".

https://www.w3.org/TR/css-content-3/#content-property

[stantonmarcum]

content: attr(alt), contents is pretty close to what we want. However, I think we need an additional semantic value to describe that the UA needs glyph support for all characters in the 'alt' string. If the glyphs are not supported, the UA should fallback to the next item in the list.

[frivoal]

Separately from which property is used to trigger this behavior, there's also the question of what counts as "not supporting the glyph"? Should it only trigger if the glyph is not supported at all, or are there cases where you'd have different levels of priority? Say you've specified font-family: serif;, and the character wasn't in the serif font, but there's a catch-all font in the system font fallback which has great unicode coverage, but is potentially quite ugly. Do you use the glyph from there, or do you use the gaiji image?

I suppose that what authors should actually do is make a custom font with coverage for the code-point(s) they think may be poorly supported, and insert that in the right place in their font fallback chain: font-family: "Osaka", sans-serif, "my gaiji font"; Then they'd get full control over the fallback behavior, proper baseline alignment, etc.

However, images are so much easier to create than fonts that it seems hard to convince people to do that. I'm kind of tempted to propose some CSS syntax to assemble a pseudo-font out of images, but this feels dirty...

@image-font {
  font-family: "my gaiji font;
  glyphs: u+56FD url("kuni.jpg"),
          u+5B57 url("ji.jpg");
  baselines: alphabetic 20%, ideographic 5%, central 50%;
}

This is probably a bad idea, but I thought I'd through it out there.

[nigelmegitt]

@frivoal that approach might work for a requirement we are lacking solution ideas for in TTWG at the moment.

One suggestion is to use special fonts with non-Unicode images (e.g. a Twitter/YouTube/Facebook/Honda icon etc) at private use area code points; however the main criticism of that approach is that it is brittle: if the author cannot control the actual font file used then it would break. That could easily happen, for example 1) if there's some out of band agreement to use a particular font file, which holds valid for a year or two, and then the font file is updated but the referencing resources are not maintained, or 2) if the author synthesises a font with just the images needed, but the distributed font differs for some reason.

Directly synthesising the font within the resource where it is going to be used helps avoid those issues.

[Crissov]

@font-face {font-family: "my gaiji font"; src: url("kuni.jpg"); unicode-range: U+56FD;}
@font-face {font-family: "my gaiji font"; src: url("ji.jpg");   unicode-range: U+5B57;}
...

Name:	src
Value:	[ <image> | <url> [format(<string> #)]? | <font-face-name> ] #
Initial:	N/A

[stantonmarcum]

@Crissov that proposal looks very reasonable to me, I'd be in favor of moving forward with that. Baseline information like @frivoal has would be helpful as well to ensure correct alignment.

One other nice bit to have is if the image can be treated as an alpha mask applied to background/foreground colors - which can allow the UA to adjust colors when applying things like dark mode.