Re: [ft] Tahoma rendering differently on Freetype & Windows

[Lewis Pike]

Hi Werner,

> :-) This partially explains why I'm sometimes quite slow in answering
> e-mails: Preparing a response took me a few hours, both in writing a
> detailed, concise replay to your questions, and at the same time
> adding the necessary tracing stuff to the B/W rasterizer, which was
> still missing.

This makes me all the more thankful!

> Well, it's not that difficult, fortunately.
> 
>   (0a) Disassemble the font with `ttx' (I recommend to install the
>        current version directly from the `fonttools' git repository).

>   (0b) For debugging B/W rendering issues, FontForge works quite
>        nicely – you must probably build it by yourself so that the TT
>        debugger actually works.  Other, commercial font editors also
>        provide TrueType debugging facilities, AFAIK.

As it would happen, I built a copy of FontForge a few weeks ago with
the TT debugger enabled in a fairly naive attempt to figure this out.
Unfortunately, my lack of knowledge got in the way: it still didn't
make clear why native Windows renderer handles this particular glyph
differently.  However, I will say that suddenly being able to step
through the instructions with immediate visual feedback was a total
revelation.  This has got to be one of FontForge's best kept secrets.

>   (0c) In general, you certainly need the TrueType instructions manual
>        from the Microsoft font site :-)

I have a copy of the Microsoft reference [0] in hand and Apple's TTF
reference [1] to boot.  Additionally, I came across Beat Stamm's
online resource [2] which covers business of TT hinting in great
detail.  The whole of his site forms an impressive treatise on the
subject.  At this point, I can't claim a lack of documentation!

>   (5) Reassemble the dump with ttx.

Thank you once again for another great lesson!  This deepens my
understanding.  I may just have to give it a go.

> > Rather than fiddle with the TTF instructions, I thought I might
> > first try adding a cleaned up version of Tahoma at 16ppem into the
> > original TTF as an embedded bitmap.
> 
> If you are going this route, it would be sufficient to add a bitmap
> strike that holds a single bitmap for this particular glyph only...

Using FontForge to embed the full Tahoma character set at 16ppem
increased the file size a fair bit.  I think the TTF spec supports a
variety of formats for the embedded bitmap data, though I don't recall
FontForge offering me a choice.

To keep the size down, I did try to add just the glyph in question.
However, I wasn't sure if embedding only a partial set of strikes was
allowable let alone supported.  Initially, I couldn't seem to delete
the unmodified strikes without also deleting their corresponding
outlines.  I eventually found an old message on Fontforge-devel [3]
which addressed this very issue (using Tahoma, no less :)) and I
managed to embed just the single bitmap.  Alas, when using this
modified Tahoma, no application I tested would gracefully fall back to
the scalable glyphs in cases where the bitmap strike was missing.
Most applications simply substituted the missing bitmap strikes with
whitespace.  Perhaps FontForge is embedding empty strikes for these
glyphs?

In any event, I've abandoned that route as it doesn't make any
guarantee that applications will be choose a bitmap strike over its
scalable form.

Let's see how I fare on the steeper side.

.lewis

[0] https://www.microsoft.com/en-us/Typography/SpecificationsOverview.aspx
[1] https://developer.apple.com/fonts/TrueType-Reference-Manual/
[2] http://www.rastertragedy.com/
[3] http://sourceforge.net/p/fontforge/mailman/message/9864383/