|Subject:||Re: [ft-devel] [GSoC] CID font support, and others|
|Date:||Thu, 10 Aug 2017 09:58:14 -0700|
|User-agent:||Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1|
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.
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
|[Prev in Thread]||Current Thread||[Next in Thread]|