[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] New FreeType release within a week

From: Ewald Hew
Subject: Re: [ft-devel] New FreeType release within a week
Date: Thu, 4 Jan 2018 21:09:00 +0800

>> I looked at the example that Ewald gave, ztm-Reg.pfb gid 479
>> 'shade'.  While the [hv]stem operators are used 344 times in this
>> charstring, the hints are not all unique.  There are just 10 unique
>> hstems and 10 unique vstems.  When converted to CFF, this font would
>> therefore declare just 20 hints, easily within the limit.
> This is a very good point.  It seems that T1 support could be improved
> by adding one additional step, namely to make hints unique.  However,
> such an extra step costs time.  If an arbitrary number of hints is
> allowed (using dynamic allocation) – which we eventually have to
> support anyway – this extra step might not be necessary.

Actually, the hintmap already does this - overlapping hints are not
inserted. So I went with a different approach, to switch off hinting
only if the hintmap is full. Compare attached patches.

With this, none of the fonts across TeXLive fail (as in fall back to
non-hinted). However, I wonder if the hinted output of such glyphs are
actually better. See attached pictures.

`stems.png' is the result of turning off hinting since 344 hints is
more than the allowed 96 (I'm not sure why the outline shifts a

`hintmap.png' does not, since there are only 20 hints in the initial
hintmap. However, it introduces some jagged edges on the output due to
the alignment. Likewise with the "4111 hints" glyph, hinted output
sort of stretches the uniform grid of circles outwards on the ends.
Although, these may be isolated cases...


Attachment: nohint.png
Description: PNG image

Attachment: stems.png
Description: PNG image

Attachment: hintmap.png
Description: PNG image

Attachment: 0001-off-hinting-if-hintmap-full.patch
Description: Text Data

Attachment: 0001-off-hinting-if-too-many-stems.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]