Re: [ft-devel] [GSoC] CID font support, and others

[Dave Arnold]

Hi Ewald & Werner,

The initial hintmap feature is relatively new in Adobe's CFF rasterizers. It does not exist in CoolType (the rasterizer used in Acrobat). CoolType uses an interpreter that handles either Type 1 or CFF in one pass. But because it does not build an initial hintmap, it is able  to process Type 1 hint declarations that occur mid-charstring. Hint processing in CoolType is very different from the rasterizer that Adobe contributed to FreeType.

The main motivation for the initial hintmap feature was to deal with distortions caused by blue zones. Consider the letter 'E', where the top hstem is captured by a blue zone and moved up. The middle hstem is not captured by a blue zone, so it is initially placed on the unhinted map, and in many cases would move down when grid-fit. Our type designers objected strongly to a rendered 'E' where the upper counter (space between stems) was larger than the lower counter. The solution was to build an initial hintmap that accounted for blue zones and then place other hstems using that initial hintmap instead of the unhinted map.

As you discovered, the construction of the initial hintmap depends on a CFF font declaring all hints at the start of the charstring, so this feature would not be available in a Type 1 interpreter. When I designed the CFF interpreter, Type 1 support was not a requirement, so I did not realize this.

I suppose you could disable the use of the initial hintmap for Type 1 charstrings only. But your two pass approach has the advantage of making the initial hintmap feature work for Type 1. As long as the performance impact is acceptable, I think this is a good choice.

Thanks.

-Dave

On 8/7/2017 3:49 AM, Werner LEMBERG wrote:

The only other solution that comes to mind is doing an extra pass
just to build the initial hintmap, after which hint moves should
presumably work right.

I like your first suggestion better.

I would prefer changing the logic too, but that doesn't seem
feasible.  Look at this output from another font (ztm-Reg): [...]

The initial hintmap is wrong, affecting the first set of hints.
Because the (-10,48) pair is not in the first hint group, but is in
a blue zone (hence locked and in the initial map).  For Type 1, the
interpreter cannot know this until later in the charstring when that
pair is actually inserted, and hence cannot possibly build the
correct initial hintmap unless a preliminary pass is made to collate
all the hints.

Hmm, hmm, hmm.  I'm not sure whether there is a tricky thinko
somewhere (actually, I hope that :-).  Let's see whether Dave Arnold
can give advice.

Until then, I suggest to do some more research.  Looking around in the
web for Type1->CFF converters I always read that hint conversion is
`trivial' [not sure whether those guys just report hearsay or whether
they have actually tried and tested it].  Your findings seem to
suggest that this is not the case – so I ask you to find out whether
the problem you encounter indeed affects other rendering engines also
– as far as I know, the Acroread engine for CFF is not the same as the
engine Adobe has contributed to FreeType.  It also comes with native
Type1 support, so there is a chance to directly compare results.

  . Test with Acroread whether Type1 fonts and its CFF conversions
    yield identical rendering results.

  . Try a program like `cfftot1' (from TeXLive or the LCDF bundle) to
    do the opposite conversion, again checking with Acroread for
    identical results.

  . Compare conversion results between different tools, for example,
    Adobe's `tx' tool, fontforge, and maybe others.  Maybe this gives
    further hints how Type1 fonts should be handled within a CFF
    environment.


     Werner