[Devel] Re: extra metric points

[Antoine Leca]

Halo Werner,

Werner LEMBERG va escriure:

>> I just pulled down freetype_current and I see support for only two
>> phantom points.  Is this a design decision or has no one gotten
>> around to updating?
>
> Before you've mentioned this a few days ago I've never heard of this.
> Do you volunteer to update FreeType?  BTW, please provide a link to
> the relevant part of the OpenType specification.

This is strange. I noted this point litteraly years ago, inside the Freetype
1 interpreter (it was about GETINFO). Unfortunately, I refrain to comment
it, and certainly to include it in the documentation, probably because I was
missing time to oinvolve me in the required developments...
But it did not occur to me it was something that Werner missed... or perhaps
I am mixed up things here?

Originally, (Apple) TrueType only has 2 control points, usually dubbed
"phantom", at both horizontal extremas (left-side-bearing and horizontal
avance). Moving them allowed to change the metrics (and this is the reason
why for precise metrics, you should make a full run of the instructions,
only skipping the raster). Also, they are stored in 'hmtx', not in 'glyf'.

However, while revising the docs to compose this message, it appears to me
that the Apple spec is very very quiet about this. I only found 3 references
to "phantom", and only in the example (chapter 3). And I was not able to
find the place where it says that in addition to the points defined in
'glyf', one should add two points, coming from 'htmx' (I did not search
hard).
For what it is worth, Windows 3.1 Truetype behaves the same (the only
difference is that it mainly operates with 16-bit values).

<URL:http://www.microsoft.com/typography/otspec/instgly.doc>, updated
1997-04-20, says that MS
Rasterizer v.1.7 (for information, the one included in Windows 95, see below
for more) enhanced this (search for "Phantom points"). Since it is very
interesting, I quote it in full :

<BLOCKQUOTE>
The Microsoft rasterizer v.1.7 or later will always add four "phantom
 points" to the end of every outline to allow either widths or heights to be
controlled (MS rasterizers earlier than v.1.7 only add two phantom points,
allowing only widths to be controlled).
If the entire set of contours for a glyph requires "n" points (i.e., contour
points numbered from 0 to n-1), then the scaler will add points n, n+1, n+2,
and n+3. Point "n" will be placed at the character origin, point "n+1" will
be placed at the advance width point, point "n+2" will be placed at the top
origin, and point "n+3" will be placed at the advance height point. For an
illustration of how these phantom points are placed, see Figure 2-1 (points
17, 18, 19, 20) and Figure 2-2 (points 27, 28, 29, and 30).

All four phantom points may be controlled by TrueType instructions, with
corresponding effects on the sidebearings, advance width, and advance height
(in the case of vertical positioning) of the instructed glyph. The side
bearings, advance width, and advance height are computed using these phantom
points and are called the device-specific widths and heights (since they
reflect the results of grid fitting the width or height along with the glyph
to the characteristics of the device). The device-specific widths or heights
can be different from or identical to the linearly scaled widths or heights
(obtained by simple scaling operations), depending on the instructions
applied to the phantom points.

Before applying a TrueType instruction on height related phantom points (n+2
and n+3), use GETINFO[ ] to check that the rasterizer is a MS rasterizer
v.1.7 or later.

</BLOCKQUOTE>

I must add that obviously, the "n+2" and "n+3" do not come neither from the
'glyf' nor the 'hmtx' tables. Since it is not required, the 'vmtx' table is
certainly not alone involved in this process. When this table is missing, I
do not know from where come the informations. I remember Werner implementing
some sort of hack to deal with such fonts, and comenting the hack was not
really

<URL:http://www.freetype.org/pipermail/devel/2000-March/004786.html>, posted
by... Werner (!), is a copy of a VERY interesteing message from Greg
Hitchcock (the head of the Truetype rasterizer at Microsoft, at least some
years ago). It says what are the versions returned with GETINFO[] depending
of the capabilities. The important point here, is that if we implement these
vertical metrics, we really should update the values returned by GETINFO[]
from the current 3 (meaning Windows 3.1, no vertical support) to something
more in line with current reality! Since we do support gray rendering, I
believe 35 (Rasterizer 1.7) is a good value; particularly since the comment
about GETINFO[] in
<URL:http://www.microsoft.com/typography/otspec/ttinst2.doc> says:

<BLOCKQUOTE>
The result pushed onto the stack contains the requested information.  More
precisely, bits 0 through 7 comprise the Scaler version number. Version 1 is
Macintosh System 6 INIT, version 2 is Macintosh System 7, version 3 is
Windows 3.1, version 33 is MS rasterizer v.1.5, version 34 is MS rasterizer
v.1.6, version 35 is MS rasterizer v.1.7). Version numbers 0 and 4 through
255 are reserved.
Note: Before hinting vertical phantom points or asking for grayscale
information, use GETINFO to check that the rasterizer in use is MS
rasterizer v.1.7 or later.

Bit 8 is set to 1 if the current glyph has been rotated. It is 0 otherwise.
Setting bit 9 to 1 indicates that the glyph has been stretched. It is 0
otherwise.

Bit 12 is set to 1 if the rasterization is done for grayscale (for MS
rasterizer v.1.7 and later).

</BLOCKQUOTE>

<URL:http://www.truetype.demon.co.uk/ttraster.htm> relates (a) story of the
Microsoft rasterizer.



Antoine