googlefonts / colr-gradients-spec

63 stars 8 forks source link

Reusing bitmaps #272

Open behdad opened 3 years ago

behdad commented 3 years ago

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 from sbix or CBLC/CBDT (I suggest in that order, though open to discussion) and make available to the paint graph.

davelab6 commented 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)

rsheeter commented 3 years ago

+1, immediate question from multiple svg users

rsheeter commented 3 years ago

@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).

rsheeter commented 3 years ago

@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.

behdad commented 3 years ago

I'm not sure we should upgrade CBDT; I'd kind of like to view that table as legacy.

+1

Lorp commented 3 years ago

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.

behdad commented 3 years ago

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:

https://github.com/harfbuzz/harfbuzz/issues/2808

rsheeter commented 3 years ago

Is jpeg xl already allowed under the jpg graphic type in sbix?

behdad commented 3 years ago

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. :)

rsheeter commented 3 years ago

Should jpeg xl be allowed under the jpg graphic type? :)

behdad commented 3 years ago

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?

rsheeter commented 3 years ago

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.

behdad commented 3 years ago

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.

rsheeter commented 3 years ago

only finalized in Dec 2020

Oh good catch, I somehow thought it'd been done a bit longer. Nice.

twardoch commented 3 years ago

👍

rsheeter commented 3 years ago

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.

behdad commented 3 years ago

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.

Lorp commented 3 years ago

It’s different if the intent now is to ship fonts and renderers :)

rsheeter commented 3 years ago

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!

rsheeter commented 3 years ago

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.

PeterConstable commented 3 years ago

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:

rsheeter commented 1 year ago

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.

schriftgestalt commented 1 year ago

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.

PeterConstable commented 1 year ago

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.

LiebeFonts commented 1 year ago

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?