[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ft-devel] various questions about implementing ttf
From: |
Werner LEMBERG |
Subject: |
Re: [ft-devel] various questions about implementing ttf |
Date: |
Mon, 05 Dec 2016 07:57:12 +0100 (CET) |
> I'm currently writing on some ft-"equivalent" pascal lib. I've
> decided to do this from scratch, 100% fresh code base.
Why? This sounds like reinventing the wheel, in particular, ignoring
FreeType's intelligence forged over 20 years...
I would rather rewrite *FreeType* in Pascal, probably defining a
better, uniform, and more modern interface. I could even imagine the
opposite to texk, the main implementation today of TeX, which uses a
very simple Pascal-to-C translator (followed and preceded by various
patches) to avoid rewriting Knuth's original code...
> 1. Are there fonts designed for the purpose of debuging
> interpreters?
Not really, AFAIK. You can however compare the results of FreeType's
`ttdebug' program with your stuff. Additionally, Microsoft's VTT is
also available.
> 2. Scaling: Really make the interpreter work on device-space units?
> Wouldn't it be more natural to scale by pointsize, and probably
> have some "intended ppem hint" about a final renderer transform
> just for fonts that are really interested in subpixel fitting?
Well, you have to follow the OpenType specification if you are going
to interpret TrueType bytecode...
> 3. CVT-table (from font-file):
> spec unclear (apple says 4 bytes per elem),
Unclear? 4 bytes per element is correct.
> OT/MS say FUnits and tabs often have odd multiples of 2
CVS are basically stored as funits but scaled to the current PPEM
before being used (note that it gets tricky if the horizontal and
vertical scaling factors are different).
What do you mean with `odd multiples'?
> How to scale? By device independent pointsize?
The basic unit for bytecode is 1/64th pixel, and you *always* scale by
PPEM, not pointsize – while the latter is absolute, it has no
connection to the output device resolution.
> 4. Interpreter/Hinter, initializations: How to Reset or keep states
> between program invocations? Fresh init for any invocation, or
> reset to what "prep" left?
It's quite simple: `fpgm' is run once per font, `prep' is always run
after the graphic state changes (e.g., new PPEM, AA instead of B/W,
etc.)
> What about zone0 init?
Missing in the spec, but it is always reset and re-initialized in the
MS implementation before a glyph gets rendered, IIRC.
> 5. Interpreter/Hinter, dual projection vector: Is it really used
> somewhere?
Of course. Mainly for diagonal lines.
> 6. Renderer, dropout control: Is the test "continue to intersect
> scanlines" a pixel-based process, like just checking if the
> neighbor scan line segments have been touched by a contour? Or
> do we already have more sophisticated tests implemented today?
Dropout control is badly worded in the specification, and I wasn't
able to make FreeType behave exactly the same as MS, unfortunately.
It's extremely sensitive to rounding issues...
Werner