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

[Ewald Hew]

> 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].

I wouldn't call it trivial, but it's certainly simple enough. A
Type1->CFF converter only needs to collate hints when there is a hint
change, replacing it with the appropriate `hintmask' command and later
insert the entire list of hints into the front of the charstring, so
can be done in a single pass. Effectively, converters do nothing with
outline commands. Our complication is that we must be placing outline
points alongside reading the hints, and adjusting the former
accordingly.

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

Sorry, I'm not sure how I should go about this. I went with exporting
PDF from LibreOffice, but when I opened that in Acroread I get LCD
rendering (see attached). They're certainly the two different formats
(looking at the line gap), and the problematic glyph "u" looks hinted
correctly. However, to reproduce the results from ftgrid, I'll need it
to render in monochrome. What do you do to test fonts with Acroread?

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

The CFF->Type1 conversion is what I've already done to obtain the
comparisons. Again, not sure how to test using Acroread. If only there
is a utility that could take in a font file, and generate a pdf with
all glyphs?

>   . 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.

On default settings, both `tx' and fontforge put the hints at the top
of the charstring, as they should. The generated `hintmask' commands
are the same too. Only difference seems to be that fontforge
subroutinizes outline commands (which I'm sure `tx' does too, with the
right options set). Here's the plaintext output converted from
`ztm-Reg.pfb', glyph "u". The original Type1 renders bad, but
both converted CFF render fine.

Fontforge:
<CharString name="u">
  -13 -10 58 -12 14 386 14 hstemhm
  80 84 178 84 hintmask 01111000
  488 50 rmoveto
  -35 callsubr
  hintmask 10111000
  -34 callsubr
  hintmask 01111000
  -33 callsubr
  endchar
</CharString>

tx:
[86]={
  -15 -10 58 -12 14 386 14 hstemhm
  80 84 178 84 hintmask[78]
  488 50 rmoveto
  -5 hlineto
  -49 2 -7 8 -1 47 rrcurveto
  343 -158 -17 vlineto
  62 -3 12 -10 -50 vvcurveto
  -235 vlineto
  -28 -5 -14 -14 -11 vhcurveto
  hintmask[B8]
  -22 -27 -31 -12 -30 hhcurveto
  -39 -32 34 42 hvcurveto
  326 -146 -14 vlineto
  47 -2 14 -14 1 -48 rrcurveto
  -252 vlineto
  -79 48 -51 73 37 39 16 27 27 vhcurveto
  43 43 rlineto
  -83 vlineto
  4 -2 rlineto
  hintmask[78]
  50 20 36 11 51 14 rrcurveto
  endchar
}

What I draw from this is that a bad Type1 font (actually not the font,
but the way we do hinting doesn't allow mid-charstring hints)
can be made compliant to the spec, i.e. all hints declared at
the start by, and only by, making an extra preprocessing/conversion
pass.

Ewald

Capture.PNG
Description: PNG image