Sun 10 Dec 2017 02:01:59 AM UTC, original submission:
I learned that HarfBuzz is what renders glyphs in Pango, which is used to display text in GNOME and other environments. The HarfBuzz maintainer has fixed the situation with double diacritics; see
https://bugzilla.gnome.org/show_bug.cgi?id=787284
I also learned from that exchange that HarfBuzz handles combining characters by its own set of heuristics if a font does not contain the GPOS OpenType extension to TrueType. This is actually necessary when it comes to vertical stacking of combining characters, because basic TrueType only contains information about vertical positioning.
With that being the case, I do not think it is worthwhile to specify combining characters with anything other than single- or double-width. I will leave the Russian glyphs that were assigned a 12 pixel width the way they are though; there is no solution for them that is a good solution.
In addition to being able to draw glyphs at the correct aspect ratio with the unibmp2hex program, one other goal I had was to make it easy for others to draw glyphs who had artistic talent that I lack, but did not know how to read computer programs. To that end, I kept the precedent that Unifont established of applying a constant width to most scripts in the Basic Multilingual Plane. In general, Latin glyphs were single width, and Indic and CJK scripts were double width. The CJK scripts carry this to an extreme by even containing double-width Latin letters for consistency. An exception was symbol scripts. I have thought about this a great deal, and realized that if I start adding exceptions to script widths in unibmp2hex, it will require that someone know how to understand computer programs to know what the width of each individual glyph in a script will be. So I would like to stick with Unifont’s original design of a single width for most scripts, at least the Plane 0 scripts.
I also do not wish to throw away the hard work of Unifont pioneers, who created glyphs for scripts such as Tibetan and Devanagari before the graphics tools that I developed existed. The Devanagari script with its serifs might not match the sans serif nature of most of Unifont, but it is also one of the best looking scripts in all of Unifont—if not the best looking script. There is an issue with its combining characters overlapping consonants that it would combine with. I would modify the glyphs that exist though, not replace them wholesale.
Unifont was originally just designed to produce a BDF font. Many BDF rendering engines did not handle combining characters at all. So the original form of Devanagari and similar scripts was something that would render glyphs that someone could understand, even though they would not appear in the combined way they would be written. The BDF font to this day does not do anything special for combining characters. That is something that should probably change. It would take testing in various windowing systems that I have not taken the time to do.
On the TrueType font, I actually do not know why anybody would use Unifont for Indic scripts if an alternative full OpenType font exists. And for common Indic scripts, there are plenty of free OpenType fonts available. For Vedic Sanskrit, there is nothing that compares in completeness to the font from Omkarananda Ashram. Indic fonts for the most part have consonant contractions that every native speaker will expect, but that Unifont’s simple plain TrueType format does not support. So I think tinkering with them quickly reaches a point of diminishing returns. I think it would be better to start considering contributions to a free OpenType font that does support such contractions.
Another emerging issue is that FontForge developers have begun work on TruFont, an alternative to FontForge:
http://trufont.github.io/
Dave Crossland, who has headed FontForge development for several years, has shifted his focus to supporting TruFont development. This article with follow-on comments provides a lot of insight into the reasons for developers moving from FontForge maintenance to TruFont development:
http://typedrawers.com/discussion/1165/introducing-trufont-world-s-first-native-ufo3-font-editor-fully-cross-platform
So I have in the back of my mind been thinking of a future with an alternative to FontForge. At some point in the future, it is possible that FontForge maintenance will dwindle to an unworkable state and that will necessitate a change.
As a full OpenType vector-based, nicer looking alternative to Unifont, GNU FreeFont would be a natural choice for contributions. I have been too busy with Unifont to approach the FreeFont maintainers about contributing to their efforts so far.
In closing, I do not think “but this is the way we’ve always done it” is reasonable justification for never changing. With Unifont though, its origins as a BDF font and its plain TrueType format do not support features that many of the world’s scripts require. I think it serves a valuable place as a fallback font, a font of last resort. I do not think it is worthwhile to take such a simple font format and add complications like GPOS table support or other OpenType extensions.
What are the thoughts of others on these topics?
|