-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reusing bitmaps #272
Comments
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 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 MPEGGroup/OpenFontFormat#46) |
+1, immediate question from multiple svg users |
@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. |
+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. |
Yes.
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 |
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? :) |
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? |
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. |
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. |
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. |
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. |
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?
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. |
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.The text was updated successfully, but these errors were encountered: