Re: Please review documentation changes

Ralph,

> From: <[email protected]>
> To: "Igor V. Melichev" <[email protected]>
> Cc: <[email protected]>
> Sent: Tuesday, January 13, 2004 2:19 AM
> Subject: Re: Please review documentation changes


> I've made some changes which I think clarify your intent while improving
the english. Thanks for
> the reminder.

Thank you. Now it looks fine, but I've fixed some punctuation.

> One thing that wasn't clear to me: are the Dynalab fonts handled correctly
with the default value
> of GridFitTT=2, or should one set GridFitTT=3 in those cases?

Dynalab fonts work in any case independently on GridFitTT.

> I think it's important to give
> instructions for this if the fonts to do not work by default.

That's up to you. Here are some hints.

Dynalab uses the TT bytecode interpreter in some unusual way.
They apply point movement and interpolate instructions to
implement a non-affine transformations of CJK subglyphs
when composing a glyph from subglyphs.

For example, take a look at Adobe Japan1 character collection,
glyphs 1125, 1126. Both them contain a horizontal bar with a tooth at right
end.
They have a different length, but the size of the tooth is same.
Dynalab make both them from a single template with a non-affine transform.

I run a TT bytecode interpreter to perform this transform.
Fortunately Dynalab fonts don't need patented instructions.
This interpretation gives 2 effects : (1) the Dynalab's transform,
and (2) a True Type grid fitting.

But many other fonts involve patented instructions for a grid fitting.
A common example is to grid fit the diagonal stem in 'N'.
When a patented instruction is involved, the interpretation is discontinued
and undone, the glyph is rendered with no bytecode applied.

All this together means that a glyph applies the bytecode iff it has no
patented instructions. As a consequence, the TT grid fitting
is applied iff a glyph has no patented instructions. Such result isn't
practical (some glyphs are grid fitted, some others are not),
therefore I apply a special effort to avoid the effect of the TT grid
fitting.
For doing that I use the design scale when running the TT interpreter.
For most cases this implies the glyph size of 4096 pixels and
the TT bytecode disables the grid fitting for large glyphs.
Thus the Dynalab transform performs fine, obtaining a 4096 pixels glyph.
Then I scale the glyph to the correct size requested by the document,
and this scaling gives a non-grid-fitted glyph.

After that I apply the topological grid fitting, if (GridFittTT & 2) != 0.
If (GridFittTT & 1) != 0, the TT bytecode is interpreted in device pixels
(i.e. the font size requested by the document) rather than the design scale
as explained above. So actually GridFitTT is a set of 2 bits with 4 possible
combinations.

The "topological" grid fitting is my new algorithm. It applies the
trapezoid fill (with minor improvements) to the "spotan" device
defined in gzspotan.c . The latter reconstructs the spot topology from the
set
of trapezoids, and recognizes stems in there. Then it generates
hints for the stems, reducing the problem to the problem of Type 1 hinting,
which was implemented a long ago. It would be better to use special new
(simpler)
type of hints for this case because spotan could specify exact contour point
indices,
but this was not done just to simplify the 1st release and due to the
representation of paths in Ghostscript. I don't want to use the term
"hinting" in this process,
because the hints is not its important feature.

Igor.