I can tell you how this former German developer solved it: The claasic Mac
version used to have special code to extract Mac Roman fonts from the system...

clipka <ano### [at] anonymousorg> wrote:
> 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