I know that Haiku has an icon editor that saves special vector images that are extremely compact. I am wondering what it would take to use the same vector image editor to make font glyphs using a similar format and added metadata for kerning pairs. The reason this would be unique to Haiku is that TrueType and all similar formats that I know of use monochrome glyphs. In the day and age that the printed page is being relegated to the history books and the Internet is taking over, some colorful vector fonts would be a nice addition to any operating system so it might as well start here.
Unfortunately, other OS did this already: https://css-tricks.com/color-fonts/
Drat. I was hoping that an integer-based version could be invented so it would be faster than SVG. SVG uses all floating-point constants as far as I know and stores its files as XML text with ZLib compression to make the file size more manageable. I’ll have to give this some thought. Converting fixed-point to floats is easy but going back the other way seems fiddly with all the rounding errors associated with it.
Yes, this is what the Haiku Vector Icon Format (HVIF) does. There is an article and a video of a talk from Leah Hanson, which describes her analysis of the format and how everything is encoded. It is indeed much more compact than plain SVG.
http://blog.leahhanson.us/post/recursecenter2016/haiku_icons.html
2 Likes
Thanks. I had just finished reading that after finding that in my bookmarks and maybe I’ll consider a new font file format that can import from the other bulky one. I was already considering a 2D vector animation format for similar purposes, but from what I’ve read about HVIF, it has a limited grid for its resolution.
Circling back to a 5 year old topic
I’ve been giving this some thought lately again. To adapt HVIF to a font glyph format, I’d need to:
- convert the header record to be global, reducing or eliminating the HVIF headers from each individual glyph
- add metadata to the header so that the full UTF8 character map could be supported
- keep a PNG fallback like Haiku has been doing for BeOS app icons as a bitmap form
- allow a header override to recolor palette entries if needed for CSS support and general flexibility
- make translators for OpenType SVG fonts, groups and bitmap fonts to be imported (hopefully saving memory and disk storage)
- repurpose the Icon-o-Matic editing routines for general glyph editing to make Font-o-Matic available
Six steps seems like a lot, though steps 1 and 6 seem straightforward. Those would just mean factoring out an abstract parent class and building another child class for font glyphs.
Step 3 could be streamlined by using an offset position and layering technique (like Spriter does for game art) so the apostrophe and comma could share a common glyph/bitmap, as could quotation marks. OpenType groups have a similar feature but are a separate file format for it.
Another application of this would be layering the upper loop of a capital P onto a capitol I and the tail of the capital R and lower loop of the B onto the P to save rendering time. Of course there would be a nonlinear dependency chain brought about by this that could be abstracted from Ninja build.
I just thought I’d share these thoughts openly to see what people thought. The more I think about it, the more complicated my ideas get. Maybe I should map these features in a timeline of dependencies.
Circling back again months later
I was bored after being sick in bed for a few days so I dug out this relic.
I see that from my previous plan involved importing OpenType SVG fonts from other platforms. Perhaps being able to export to OpenType from a Haiku-specific format would be a better option.
Perhaps I could leave well enough alone though too. There was no response from my previous post.
Just before I give up the ghost on this subject, can someone indicate what Unicode mapping support Haiku has? I know Harfbuzz is a popular Linux import.
Haiku has Unicode support, not sure what you mean - you can look at fonts in Character Map to see what characters they support.
Re: Harfbuzz, I believe if you look through these forums or the mailing list or the bug tracker, there was talk of replacing/augmenting Haiku’s font system with Harfbuzz.
Re: the general idea of this thread:
I wrote a bunch of code a few years ago that can read and write OpenType fonts because I wanted to write a font editor, but haven’t gotten to finishing that project. It never occurred to me to parse an OpenType font and then write it out as SVG (or HVIF) but in theory once you’ve got the parsed data the world is your oyster?
…but even if you could take an OpenType font, convert it to an HVIF “font”, and then edit it with Font-o-Matic, you’d still need the OS support to be able to use the fonts - and that part would be quite an effort. I have an open code review just for adding the ability to load a custom font into the existing font system and it’s rather large.
ok, I’m being negative and unsupportive here. Instead I should say: go for it! I believe in you! 
I had noticed that WebPositive wasn’t downloading web fonts and I think @PulkoMandy said that the only way to install fonts at that time was through the package manager. Of course we need more than that for HTML5 support though.
just add a setting [] block web fonts and have it always enabled, then it’s a privacy thing 
web fonts are a bit icky currently, atleast in germany countless websites are under legal threat for using remote fonts, nevertheless we should support it. But i would be thankfull for options to turn a lot of this baggage off.
Considering glyph rendering is just a small piece of font handling, I’ve decided to broaden the scope of this thread to adding more general font support besides TrueType monochrome.
Font Manager?
Since the package manager is the backbone of the current font management, what would it take to expand the metadata of the HaikuDepot app and infrastricture to include “implicit packages” supplied by translator kit, whose presence is marked as transient based on a least-recently-used eviction policy, that will act as a cache for web fonts and ultimately add font management. Perhaps a special category of package could be used to differentiate those packages from explicitly installed fonts.
It sounds like quite a stretch for a package manager to also be the font manager though. Also, distribution and usage licensing are not embedded in web fonts anyway. Furthermore, I don’t know how secure it would be to let people promote font installs to permanent from transient and just start using them regardless of origin from a legal standpoint.
Other Transient Packages?
This proposal could open the door to unlicensed clip-art documents being treated as package cached, translator kit supplied artwork from the web and all the legal baggage. Of course people do use unlicensed photos and artwork from the web anyway, but do we want the browser cached documents indexed and searchable and easier to abuse in the package manager?
When pressed to extremes, it sounds absurd to me. Maybe object-oriented code reuse shouldn’t be so extreme in its application. It’s flexible but probably not a good idea.
Hello, nice if you like fonts too…
Have you checked Fontboy the Font explorer?
https://depot.haiku-os.org/#!/pkg/fontboy/haikuports/haikuports_x86_64/0/9/8/-/1/x86_64?bcguid=bc404-CBPL
Would be nice to extend this app to become a Font Manager for Haiku!
Would be great to drag n’drop fonts to FontBoy vice versa…
FontBoy looks like a good start of a font manager interface. Now we only need a place to put it!
I don’t know how secure it would be to let people promote font installs to permanent from transient
Yeah this sounds like a bad idea imo. The idea with web fonts is that they’re streamed into ram and then the font system could use them while the app is running - making them available to then download to disk and install as a permanent font feels fraught with peril.
Would it make more sense to make web caching of fonts and graphics a separate instance of the package filesystem without cross-communication from the cache to the persistent package filesystem but still make system font packages accessible as one-way communication?
I don’t understand why you want such a complex solution.
It also assumes that any webfont can be “right” in the naming of fonts.
Web should use system fonts after the downloaded fonts, it does this now. It only needs support to load fonts from memory.
What formats are supported so far? The OpenType standard has two main ones: TrueType and SVG ColorFonts. Are both available on Haiku?
Allowing future font formats to import into something more compact than SVG’s zipped XML format should be easy on Haiku if a new translator is supplied. I think a tokenized TVG format is being planned for being an SVG successor. I think Haiku’s HVIF is more compact than even the proposed TVG.
After some thought, I’m convinced that translating into an internal format for font glyphs is probably the best approach for efficient code. Whether it ends up being the HVIF code remains to be seen. Perhaps substituting half-precision 16-bit floats for the 7-bit coordinates of HVIF may be better for graphics drivers.
For now I’ve only opened the floor for discussion. As far as being able to use a font manager reusing code from existing Haiku programs, that’s still just discussion. Resource tracking in an operating system is sometimes handy for freeing up resources can be a useful diagnostic tool.
You are a bit late for discussion since the loading of fonts from RAM is already implemented. The patch is on Gerrit, and there is some discussion to finalize it: https://review.haiku-os.org/c/haiku/+/4790
The idea is very simple as nephele said: allow an application to create a BFont from application-provided data. Either from a file:
status_t BFont::LoadFont(const char* path);
or from in-memory data:
status_t BFont::LoadFont(const area_id fontAreaID, uint32 size = 0, uint32 offset = 0);
That’s all we need. The web browser can manage its caching for fonts in whichever way it wants (WebKit already has everything needed to manage that). It just has to feed them to app_server whenever it wants to draw something using such fonts.
Once this change is merged, WebKit will be adjusted to make use of it. The fonts never leave the web browser, and they shouldn’t.
Adding extra formats is handled on app_server side in FreeType. FreeType already handle all the font formats on Linux so, at worst we need to recompile it with a few extra options to enable all the things we need.
3 Likes
Thanks @PulkoMandy ! If that doesn’t scratch the itch, I’ll look at the FreeType sources.
yeah, that’s my patch, need to take a break from ArtPaint and go finish it.
1 Like