freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Werner LEMBERG
Subject: Re: [ft] Tahoma rendering differently on Freetype & Windows
Date: Sat, 06 Jun 2015 05:37:18 +0200 (CEST)

> Simply observing the process by which this behavior can be debugged
> is elucidating in its own right.

:-) 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.

> Mounting an attempt at the bytecode certainly is tempting, though it
> may be best to leave well enough alone unless I am planning a
> professional career in this sort of thing.

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.

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

  (1) Use FontForge to iterate over the glyph's bytecode instructions
      until you find the spot where the point in question is moved a
      last time along the horizontal axis.  In this case, it is moved
      twice, and we are interested in the last move caused by a
      SHPIX[] operator.  It is part of a function (which you must not
      change since other glyphs use it also); consequently, you have
      to insert the new bytecode somewhere after this function call,
      but before the final IUP[] instruction.  You should also ensure
      that the freedom vector is (1,0) – along this axis SHPIX[]
      actually works.

  (2) At the very place where you want to insert the bytecode, check
      whether there are jump instructions that jump over the code
      spot; you will have to update the offsets accordingly (IIRC,
      there aren't jump instructions in this glyph).

  (3) To restrict the change to a single ppem value (16ppem in your
      case), you need to insert code like this (this is, inserting
      into the dump produced by ttx).

        MPPEM[ ]
        PUSH[ ]
          16
        EQ[ ]
        IF[ ]
          ... here comes the new code ...
        EIF[ ]

  (4) The new code is most probably another SHPIX[] call, to partially
      undo the right shift of point 25.  Assuming that a shift of
      -3/64px is sufficient, the code within the IF clause is

          PUSH[ ]
            25
            -3
          SHPIX[ ]

  (5) Reassemble the dump with ttx.

That's it.  Note, however, that your new Tahoma font file will not by
digitally signed (this is, the DSIG table in the font will be a dummy
version only).

> 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...


    Werner

reply via email to

[Prev in Thread] Current Thread [Next in Thread]