An HVIF derivative format allowing shared elements was the proposal. If it can grow remains to be seen. A nice, compact binary format that fares well against SVG in most of its usecases is what I find attractive about HVIF. Let’s see how far we can go from here.
GUI elements need to follow the color schemes of the color preferences and themes. Engineering those shared colors would be a start at least.
PNG based emoji are not vectotized but a general SVG to HVIF importer would show how HVIF stacks up against SVG in all cases. Let’s at least keep that. Is there a ticket for that or is it needed? I’ll search.
HVIF is meant for a very specific role: relatively simple and small images. It is not meant as a generic equivalent to SVG. That’s how it manages to be smaller than SVG.
If your plan is to have something as generic as SVG, you have to “pay the price” for it in terms of compactness. If you need a generic format, SVG isn’t that bad, really (if you optimize and compress it).
In fact HVIF is a good example of what I said earlier: it ended up the way it is because it was done with the simplicity and cleanliness of the BeOS icons in mind. To represent these, a low number of shapes was needed. It doesn’t do very well on anything else (but emojis are similar, in that they need to be simple and readable at small sizes).
Consider for example Mac OS, which went with super photorealistic icons instead. If a specific format was developped for these, vector formats might be ruled out quite quickly, because in these cases, it would possibly be larger than a bitmap file, and considerably slower to render.
So, let’s not mix everything here. What do you want to do? A generic image format like SVG, or something specific just for emojis? In the latter case, do you want to do all the possible emojis ever, or pick a theme and try to optimize that specific one?
In these situations, the more generic solution isn’t always the best.
Fine. Let’s drop the emoji image discussion for now and focus on ways to make a better SVG replacement. If it ends up being a built-up HVIF alternative or IFF DR2D derivative instead, let that be a non-issue.
Here’s a proposal:
Basic Specifications
16-bit coordinate components in integer format (32 bits total for X and Y components put together)
subshapes and color palettes indicated in the header for common usage (as previously mentioned) to save on rerendering common vector forms to bitmap format
subshapes, once rendered, should have mirroring, offset translation and texture rotation features common to a modern GPU
Implementation Suggestions
all points grouped together so they can be scaled using vector ops (16 bit coordinate componant by 16 bit scale factor multiply, discarding low 16 bits of 32 bit result for scaled component results)
gradients allowed in color definitions to keep shape count low like HVIF and compatibility with SVG achievable
I just think anyone should be able to use any font in whatever way they choose. No need to do any work for a user, no conversions or pack as resources. Just pick a font with the icons you like and start using it. It is already done today by many apps, I guess it makes app development faster and resource reuse better as many apps can share a font. However I think the font format for icons is still rather primitive, unless OpenType did something interesting. And that is why I think the original idea is worth exploring.
Color icon fonts are png files encapsulated in a png. This format grew out of liminations of the web (it’s faster to load one large file than many small ones over http). We can support it, but I’m not convinced it’s the solution that matches our needs the best for native apps. BResource solves a similar problem for us: it’s better to store one big file on BFS than many small ones.
Then there is the convenience of using already existing fonts. Sure, they exist and we can support them in app_server and there’s no reason not to. But I wouldn’t go as far as recommending it for native apps?
Welcome to the thread! TrueType is monochrome. Some glyphs need to have more than a foreground and background color. I was thinking more like an SVG alternative that is not XML based.
Interesting proposal. Are you thinking of using a translator to convert SVGs to your format or having a dedicated editor like Icon-O-Matic to draw images in your format? A translator would make it simple to develop the format but would limit some features such as shape and color sharing. A full-fledged editor would allow you to do much, much more, but would also require a lot of time to develop.
This all feels a bit NIH, and from my experience, using standards ends up with a more long term solution. Because if you start to invent niche solutions, those solutions will either need to be very flexible or dropped when a standard comes in. Otherwise you end up with a mess of some parts working in one scenario, but not others, and some parts not having feature parity with the new standard.
BeOS used TTF for a reason, because creating your own fonts, much like skinning an OS UI, is nice in theory, but the devil is in the detail. If there is an existing standard, would be good to implement that. Then and only then, add in extensions and allow custom formats - if there is a real need for it.
But it also doesn’t explore the idea of sharing shapes/paths/gradients between multiple images, which is worth exploring if you have a lot of similar images to encode
I was thinking of making it a spin-off of HVIF so the Font-o-Matic editor could share code with Icon-o-Matic. Now I’m not so sure. I’ll have to look at the HVIF specification again. Now that I’m aware of the 256 node limit in Shapes and in the total number of shapes, I see that HVIF might not work out-of-the-box the way I hoped. I’ll also have to scope out the competition.
It would be possible to make the shapes section null terminated instead of having a count at the beginning. The HVIF format would then support unlimited shapes at a total cost of 0 bytes
Something else I was considering for subshapes was a dependency mapped subshape being potentially rendered out of other subshapes itself. As a font-glyph example in a Times Roman-like font, the capital H is 2 capital I’s connected with a cross piece. Likewise the capital A is a y-mirrored capital V with a cross piece.
To render these quickly, the dependency map would be implemented using a thread pool like Ninja build does for compiling.
Threads are costly. They mean synchronization to take care of, they use up some memory, and they make software more complicated (unless you use a language like Erlang that is written with threads in mind).
I think this should start by defining a file format and writing a simple renderer for it (even if it is slow). Then see if you manage to make a significant difference to the font size compared to the existing offerings. If you don’t, there is no point in trying to make it as fast than the existing systems. And if your goal is to make things faster than existing systems, that probably means making the font files larger, not smaller, if we assume the designer of the truetype format knew a bit about what they were doing.
Thanks for helping me keep sight of the priorities, @PulkoMandy . If the file is smaller, the hard drive latency (or lack thereof) may make a bigger difference anyway.
PDF is basically a tokenized postscript. We use them both for printing.
Instead of replacing HarfBuzz, I might consider a backward-compatible Graphite2 replacement. HarfBuzz seems to be more for the Unicode parsing. I’ll have to look into it more.
Starting the Journey
I’ve forked the WonderBrush v3 sources as a starting point. After reading some development docs, rendering reusable “blocks” as bitmaps and incorporating Icon-o-Matic features were already on the agenda. Thanks @stippi !
I might just remove the text gadget for now from my fork. Glyph-o-Matic, as I am now calling it, will be mainly for rendering GUI elements and font glyphs. Rendering a font glyph inside a font glyph gets uncomfortably recursive.
