I’ve brought this up before and am ready to start planning infrastructure. The first time I thought that 6-bit HVIF coordinates were too limiting but later found out that there are 15 bit coordinates as an option in that format.
Let’s list requirements and features:
Reusable brush strokes across many font glyphs to reduce rasterization time.
X-mirroring and Y-mirroring and other effects for those brush strokes (now known as “shapes”) will make them more reusable yet.
All features needed to import SVG glyphs and TrueType glyphs for full OpenType font support, but stored more compactly, reusing code from HVIF if possible.
This seems like a bad idea. HVIF is unsuited for fonts, and we don’t have any font designers or ressources to pull this off currently. We don’t even have our own font rendering code, we use freetype like everyone else.
(edit: also, what is the motivation? is there some major problem in ttf otf or is this just “we should replace this just because”?)
What is the point in redoing this? fonts already work nicely.
The issue in the ticket won’t be satisfied, it is about an improvement in our font support.
Exactly! Color fonts stored as zipped XML like SVG are bulky! If a vector format based on HVIF is compact enough to replace SVG fonts, it’ll be worth it. Plus it would make SVG imports more practical for the HVIF glyphs.
Otherwise I’d be in agreement with @nephele because monochrome fonts in TrueType format have been around longer and are a more mature source base. Monochrome fonts are more compact than color fonts and if TrueType uses integer coordinates, there’s no real reason to switch formats as a monochrome format.
For “color fonts” the question for me is a bit: why?
we don’t support them at this time, and I don’t see a reason why we should in the future.
Color emoji are too specific, and less usefull than monochrome ones, what would make sense is inline images maybe… but that is effectively just an inline image, like a BPicture.
Unicode itself thinks emoji (specially colored ones) will be superseeded by inline images. Severall color emoji fonts also contain images.
But the problem of my emoji doesn’t look like yours isn’t solved, especially when colored emojis get too specific (instead of “dancing person” now female dancing person with light skin etc). An inline image allows clients to embed whatever they want as images (even if it is vector ones).
IIRC it does make a lot of sense if you look what is inside in some fonts and how they are rendered, but probably should not be done by Haiku. Take a look at some of the big fonts we use to support languages.
I also think we should support colored fonts properly, emojis and UI elements are much better with it, just being able to have a proper green checkmarks easily in any app makes it worth it.
As I see it, it will mainly be useful if importing SVG glyphs can be done easily and transparently. That way existing color fonts can be imported from Inkscape or Adobe Illustrator.
Even if we ignore the emoji aspect for a moment, UI elements need to be scalable icons. Having groups of scalable icons that share common shapes between them could reduce overhead related to theme implementation.
I agree with others - I don’t see a use-case for a custom Haiku font format.
Having written code to parse OpenType fonts, I would argue that the OpenType spec is pretty darn compact already. Not sure how an SVG-based font would be better. Also OTF/TTF already uses the idea of re-usable portions (like an accented character combines the accent mark and base glyph).
I’d say rather than this project, look for ways to improve Haiku’s font engine. I think there’s an outstanding task to use HarfBuzz, for example.
TTF is good. SVG is not. OpenType supports both because TTF is monochrome only. My proposal is a backwardly compatible alternative to SVG web fonts.
Edit:
Looking at Harfbuzz, that looks like a good starting point anyway, even if the current package needs a version bump. I’ll look into doing that while we continue to discuss.
I honestly don’t understand this argument, emojis are worse with colored fonts, they can’t be recolored, aren’t scalable (usually) are less expressive etc.
We already have “colored” hvif based UI elements that work perfectly fine? e.g the toolbar in Koder. There isn’t really much to be done here, doing it in a font just because you technically can do ut in a font doesn’t make much sense to me.
So what about country flags or anything else that already exist in unicode. Are we supposed to make our own HVIF for all of unicode then?
Because then you are pretty much aligned with the idea proposed here. As HVIF is much better than SVG and in some cases bitmaps in fonts
We already have country flags in the installer (or had them), so I don’t see the issue. I don’t see anything that needs to be done in this area, fonts just aren’t the right tool for arbitrary UI icons.
You can already get “most of unicode” with the fonts we already ship, just the clearer monochrome versions. If you need a colored UI element a font is the wrong solution imo.
I’m all for using more HVIF in the GUI but I don’t see the point in going through fonts.
For the country flags, we do have all of them (converted from SVG). I recently made a more generic API to access them as well as the BAlert icons. They are stored in libbe BResources.
We can add a few more standard icons to this, probably starting with the toolbar ones.
But do we need the full Unicode thing? Erojis with all hossible skintone colors and genders? All encoded as text? It seems a bit much to me, but as more and more text on the web is being written this way, we may have no choice. The main interest of it being “text” in this case is that it can be “flowed” with other text and rendered inline. I don’t know how useful that is in terms of UI design.
By the way, the discussion about the emojis being hard to read is somewhat unrelated. There are some examples of succesful emojis sets, such as the “blob” ones from Google (now abandoned by them). But that’s unrelated to which format they’re encoded in
We do need to support emojis and pictograms in fonts unless someone is going to do a haiku specific icon for each unicode. If I for some reason needed the bus symbol, I don’t want to spend time drawing when I can just use a pre-made icon for it.
The other discussion is that SVG and bitmaps in fonts take up a lot of disk space and SVG also needs an XML-parser and are usually quite memory heavy. So compacting things with a more efficient format would make a lot of sense. So if someone wants to investigate what can potentially be done there, I think we shouldn’t be so negative even before there are any conclusions on what can be done.
Perhaps it was unwise of me to refer to “icon banks” as fonts just because “web fonts” are used to implement them in web pages. My first goal was to create an SVG alternative based on HVIF. As an added bonus, I wanted to share sub-shapes between the icons in the bank. Color palettes as presets could be another bonus that isn’t possible within true-color formatted SVGs. An HVIF bank would be uniquely qualified to keep the data types separately used but collectively shared.
If HarfBuzz or something similar is needed to implement Unicode out of those icons or ligatures via algorithmic rendering, that would be a future issue that could be dealt with separately. Should I change the name of the thread to “Haiku-native icon bank format?” or something similar?
Those flags were actually original IOM icons. The reason I only grudgingly accepted them being removed from the language menus ofthe FirstBootPrompt and the user guide.
I’ll look into doing that while we continue to discuss.