>>> 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
. 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
Freetype-devel mailing list