Open behdad opened 3 years ago
I do like the idea of reusing existing bitmap tables as source, though this seems like a COLRv2 thing to me :)
The main use I've seen for bitmaps in SVG-in-OT fonts is for extremely large filesize "textured" fonts (Eg https://creativemarket.com/itsmesimon/2355840-Yeah-foil-balloon-colour-font from https://creativemarket.com/fonts/colorful-fonts ) so there is no mixing.
I seem to recall there is a resolution constraint on CBLC/CBDT
PNG data? If so, I expect that would need to be removed to enable such fonts to be recompiled to COLR.
I also wonder about using non-PNG formats that might be better for such images too; PNG makes sense for little pixelated 32x32 images, but maybe not for photos of balloons and so on.
I guess this also related to color profiles (discussed also recently in https://github.com/MPEGGroup/OpenFontFormat/issues/46)
+1, immediate question from multiple svg users
@drott mentioned we should cover how to encode it, supporting different resolutions per glyph size / screen dpi, color space support. Some of this is deferred to the bitmap table in @behdad model (which I'm a fan of).
@behdad pointed out sbix supports jpg,png,tiff so we're not png only.
I'm not sure we should upgrade CBDT; I'd kind of like to view that table as legacy.
I'm not sure we should upgrade CBDT; I'd kind of like to view that table as legacy.
+1
Is it time to get the modern WebP and AVIF formats added to the jpg, png, tiff formats allowed in OpenType sbix?
Also note that Apple’s sbix spec includes PDF as an allowed format and states “Support for the 'pdf ' … data types [is] planned for future releases of iOS and macOS”. It may be useful to hear from Apple developers whether that continues to be true.
Is it time to get the modern WebP and AVIF formats added to the jpg, png, tiff formats allowed in OpenType sbix?
Yes.
Also note that Apple’s sbix spec also includes PDF as an allowed format and states “Support for the 'pdf ' … data types [is] planned for future releases of iOS and macOS”. It may be useful to hear from Apple developers whether that continues to be true.
No thank you. SVG is enough of a headache....
That said, Apple has switched to a PNG-like format using LZFSE instead of Zlib with a tag of emjc
:
Is jpeg xl already allowed under the jpg graphic type in sbix?
Is jpeg xl already allowed under the jpg graphic type in sbix?
I don't know of any implementation that accepts jpg, so hard to answer. :)
Should jpeg xl be allowed under the jpg graphic type? :)
Should jpeg xl be allowed under the jpg graphic type? :)
To me, yes. Same way that another standard sanctioning, say, the Open Font Format for a particular use should automatically roll forward with OFF advancements...
Does Jpeg XL deprecate webp?
Does Jpeg XL deprecate webp?
https://caniuse.com/jpegxl makes support look a touch gloomy so maybe not quite yet. Still, if we can claim jpegxl should work then maybe its not necessary to add a lot of other formats jpegxl aspires to replace.
https://caniuse.com/jpegxl makes support look a touch gloomy so maybe not quite yet.
Given that it was only finalized in Dec 2020, looks like it is rolling out in browsers just ahead of COLRv1; so we might as well depend on it.
only finalized in Dec 2020
Oh good catch, I somehow thought it'd been done a bit longer. Nice.
👍
The biggest catch I'm currently aware of with bitmaps is what happens when compositing a bitmap that isn't sRGB. But maybe we do two versions and in the first version it either has to be sRGB or it gets coerced into it.
The biggest catch I'm currently aware of with bitmaps is what happens when compositing a bitmap that isn't sRGB
But that's already an open question in CBDT/CBLC and sbix tables. Referencing them here is really no different.
It’s different if the intent now is to ship fonts and renderers :)
We reference https://www.w3.org/TR/compositing-1/ for compositing. https://www.w3.org/TR/css-color-4/ references https://www.w3.org/TR/compositing-1/#simplealphacompositing which seems to presume sRGB.
https://docs.microsoft.com/en-us/typography/opentype/spec/cbdt limits itself to sRGB ("Uncompressed Color Bitmaps ... are encoded colors in the sRGB colorspace" and "Compressed Color Bitmaps ... image data shall be in the sRGB colorspace." I don't see anything similar for sbix.
Thinking "aloud", an implementation must have sRGB compositing to support COLR v1. We know support for that to be widely available. If we follow the pattern of keeping v1 to widely supported graphic capabilities then IMO it makes sense to add PaintBitmap in v1, noting that composition with an image not in sRGB is undefined or ... maybe even that it's forbidden when COLR version is 1. We can note COLR v2+ may add capability beyond sRGB.
If COLR v1 lands then a major theme of COLR v2 becomes improved color capability, variable colors, more color spaces [with compositing], oh my!
jxl is the suggested file extension and media type for jpeg xl (https://en.wikipedia.org/wiki/JPEG_XL). IMHO it would be fine for an implementation to Just Work if it saw one under graphicType jpg but we probably want to update to permit 'jxl' as well.
Is it time to get the modern WebP and AVIF formats added to the jpg, png, tiff formats allowed in OpenType sbix?
Why? Just because they exists and are useful for other purposes doesn't necessarily imply they're beneficial for use in fonts. What would be the particular benefits for font developers or users? Would it limit portability of fonts to different implementations and devices?
Also note that Apple’s sbix spec includes PDF as an allowed format ...
I'm with Behdad: no, thanks! This would have some of the same issues as SVG-in-OT:
https://lists.aau.at/mailman/private/mpeg-otspec/2023-July/002939.html references https://liebefonts.com/fonts/liebeheide as a nice example of a commercial font not readily expressed in vectors.
For more examples search for "watercolor lettering".
And as there was some discussion about color spaces: We should add support CMJK as there are still people that print stuff.
https://lists.aau.at/mailman/private/mpeg-otspec/2023-July/002939.html references https://liebefonts.com/fonts/liebeheide as a nice example of a commercial font not readily expressed in vectors.
I've wondered if this might be simulated in vectors using noise filters. The size of dots varies, suggesting noise on variable component parameters might be used, though that would be a new kind of architectural complexity.
I wonder if Perlin noise would look natural enough. The pseydo randomness should vary within each glyph to not have a super regular structure. And then maybe also in combination with some transparency to fade out stroke endings?
If it is desired to be able to include bitmap images in COLRv1 glyphs (which is possible eg. with OT-SVG), we can add a
PaintBitmapGlyph
that would load a bitmap fromsbix
orCBLC/CBDT
(I suggest in that order, though open to discussion) and make available to the paint graph.