Dang, there should be a `povray.rants` newsgroup, where it is clear from 
the get-go that any post there is to blow off steam, not step on 
anyone's toes. Anywhere, here I go.


In the wake of the tokenizer changes, I needed to clean up the internal 
handling of character encoding.

In the wake of the character encoding cleanup, I needed to make changes 
to the TrueType font handling.

In the wake of changing the TrueType font handling, I found out that the 
fonts we're currently shipping with POV-Ray are crap. Total and utter 
crap. Not from an artistic point (that could be debated), but from 
conceptual and technical points. Who made these pieces of digital 
bullshit anyway?


Let's start with a look at the choice of fonts: We have a serif font 
(`timrom.ttf`) and a sans-serif (`crystal.ttf`) font. So far, so good. 
But when we look beyond ASCII characters, pretty much all we have is in 
a third font (`cyrvetic.ttf`), and it is... no, not Unicode, that would 
be too much to expect... no, not the most widespread non-Unicode 
extension to ASCII, namely Windows-1252... no, it's Cyrillic. I mean 
come on, seriously? You can give us "дерьмо", but not good old German 
"Scheiße", despite some key developers having been German speakers? Or 
"flûte", pardon my French, despite a great tradition of French-speaking 
community members?

When we look more closely, things get even more out of whack: The 
`timrom.ttf` font _does_ go beyond the ASCII character sets; but what do 
we find? Punctuation. A whole bunch of punctuation, most of which you'll 
never ever need. But German or French letters? Not a single one in 
sight. Flûte.

And with that, we come to the technical side. And there the Scheiße is 
really am Dampfen.


Now the TrueType font format provides multiple different ways to map 
numeric values (character codes) to glyphs (the actual shapes of the 
characters), stored in so-called "CMAP tables". Each CMAP table has its 
own peculiarities.

For instamce, CMAP table (1,0) is intended to be used on classic Mac OS 
systems to map 8-bit character codes to glyphs according to the "Mac OS 
Roman" character set, while CMAP table (3,1) is intended to be used on 
Microsoft systems to map 16-bit character codes to glyphs according to 
the UCS-2 character set (essentially the 16-bit subset of Unicode).

But if we translate Unicode characters first to Mac OS Roman and then 
try to map them via CMAP table (1,0), we get Schei§e. No, not Scheiße, 
that would be fine. Schei§e with a § as in German legal paragraph. Why? 
Because in this font CMAP table (1,0) is not arranged according to MAC 
OS Roman as it should be, but according to Windows-1252. Flûte encore! 
Well, at least CMAP table (3,1) is good.

It's no surprise that CMAP table (1,0) of `cyrvetic.ttf` isn't any 
better. Of course at this point we don't expect it to be MAC OS Roman as 
the table IDs advertise. After browsing plenty of character set tables, 
I figured it's Windows-1251. But this font can do worse: Expecting CMAP 
table (3,1) to use Unicode mapping? Hah! All you get is ScheiЯe. I mean, 
flыte. Ah, дерьмо! In a table that should be arranged according to 
Unicode, and provides ample space for it, you find a Windows-1251 
mapping! Even if you shove in the Unicode values of Cyrillic characters, 
you get nothing useful out of it.


So TL;DR: The choice of available characters leaves much to be desired. 
The `timrom.ttf` and a sans-serif `crystal.ttf` are technically broken. 
But the `cyrvetic.ttf` takes the cake: Buffing POV-Ray to do proper 
Unicode handling will make that font TOTALLY useless(*).


What an absurdly crappy set of fonts!


I thknk it is time we got us some new ones to ship with POV-Ray.

Also, I have decided to try changing the font handling from our own 
dated code to using the FreeType library. That way I won't be tempted to 
work around such crap. Them old fonts no longer work? Tough luck. If the 
lib won't handle them, then maybe, just maybe, the fonts really are the 
pieces of shit I'm calling them.

(Actually I was already toying with the idea of delegating TrueType font 
file handling to a 3rd party library for other reasons; the problems 
with our old fonts are just the last straw.)


(*Yeah, I know it can still serve as a sans-serif ASCII font; but we 
already have `crystal.ttf` for that.)

Post a reply to this message