[Top][All Lists]

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

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

From: Ewald Hew
Subject: Re: [ft-devel] [GSoC] CID font support, and others
Date: Wed, 2 Aug 2017 09:59:47 +0800

>> I think I've isolated the problem with hinting.  Suffice to say the
>> hinter works on the premise that all hints are known at the start.
>> This is generally not true for Type 1 fonts.  Perhaps it is possible
>> to change the logic to remove this condition.
> Hmm.  Please elaborate and give an example.

Refer to diff.txt. Each occurence of "Hints: ..." represents one hint
change (with OtherSubr 3 or hintmask respectively). Flags are, p=Pair,
g=Ghost, t=Top, b=Bottom, L=Locked, S=Synthetic. diffshort.txt is the
same but suppresses differences in `index' and `flags' for less

For glyphs that are rendering wrongly, the initial hintmap is
different in Type 1 and CFF versions of the fonts.

I eliminated other possible causes of differing blue zones, hint
order, during hint adjustment, etc., and found that errors occur when
mapping from CS to DS coordinates while the hints are being inserted
(cf. pshints.c:644~ (cf2_hintmap_insertHint)).

So, if the initial hintmap is wrong, the DS coordinates will generally
be wrong. See glyphs index 126 and 134. The initial dsCoords are
wrong, but sometimes after adjustment they are the same, more on that.

Now, only some hints are moved wrongly (cf2_hintmap_adjustHints).
Lines 14~27 is one example where hints are still correct after
adjustment. Lines 61~62, 68~69 is one example where this goes wrong.
(The other hints in this group differ too of locking). Note how hint
#2 has been adjusted downwards but hint #7 upwards, i.e., the error
was large enough that it went into the next "adjustment zone".

There is also a minor issue where stem hints never get locked in Type
1, since hint changes always remake the list of hints completely.
However, I don't think this causes problems if the initial hintmap is
correct (performance? adjustment must be done again). Example: Renders
correctly, glyph index 131, lines 277~292.

> I guess it's not `FT_Load_Glyph' but rather `FT_Get_Advance' that
> might cause slow-downs.  Behdad?

Hmm, the original bug report was for loading though (running ftbench
with `-b a').

> What did you exactly do?

I just followed the instructions in callgrind manual
( I
confirmed that FreeType was compiling with -g and used kcachegrind as
the visualiser.


Attachment: diff.txt
Description: Text document

Attachment: diffshort.txt
Description: Text document

reply via email to

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