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

[Werner LEMBERG]

>> I'll use `format-patch' to extract the patches, then construct
>> proper ChangeLog entries (based on your commit messages) and commit
>> them to master.
> 
> git cherry-pick SHA, vi ChangeLog, git commit -a, repeat...

Yep.

> Perhaps, Ewald is asking about specific plans to release his work.
> 2.8.1?

No, after 2.8.1.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Alexei Podtelezhnikov]

On Tue, Aug 22, 2017 at 9:38 AM, Werner LEMBERG  wrote:
>
>>> This mostly matters on 32-bit build without FT_LONG64. Forget about
>>> it for now but don't lose the patch. Do you mind sharing it?
>>
>> I've pushed it to `ewaldhew-wip'.
>
> Thanks.
>
>> Also, I have questions regarding final submission guidelines. I am
>> supposed to provide a stable link, I'm thinking of a commit range on
>> master on cgit, since Savannah has no "merge request" functionality.
>
> OK.
>
>> Werner, what are your plans for merging the code?
>
> I'll use `format-patch' to extract the patches, then construct proper
> ChangeLog entries (based on your commit messages) and commit them to
> master.  Finally, I'll walk over the complete code and apply cosmetic
> polishing where necessary :-)
>
>> Or any specific way you had in mind for us to consolidate all our
>> work for submission (for archival purposes too)?  Could also keep
>> the working clean branch forever, or push a clone to github.
>
> Yes, keeping your branch makes sense – it should probably renamed so
> that `GSoC 2017' appears in its name.  Additionally, all your other
> activity is already archived – one of the reasons I asked for
> communication over the `freetype-devel' list.
>
>
> Werner



-- 
Alexei A. Podtelezhnikov, PhD

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Alexei Podtelezhnikov]

>
>> Werner, what are your plans for merging the code?
>
> I'll use `format-patch' to extract the patches, then construct proper
> ChangeLog entries (based on your commit messages) and commit them to
> master.

git cherry-pick SHA, vi ChangeLog, git commit -a, repeat...

Perhaps, Ewald is asking about specific plans to release his work. 2.8.1?

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

>> Or any specific way you had in mind for us to consolidate all our
>> work for submission (for archival purposes too)?  Could also keep
>> the working clean branch forever, or push a clone to github.
> 
> Yes, keeping your branch makes sense – it should probably renamed so
> that `GSoC 2017' appears in its name.  Additionally, all your other
> activity is already archived – one of the reasons I asked for
> communication over the `freetype-devel' list.

Another suggestion is to write an e-mail to both the `freetype' and
the `freetype-devel' lists that details on the project, the
difficulties, and your solutions – with proper URLs to the code.  This
would be kind of a corollary of your commit messages and the e-mail
exchange on the `freetype-devel' list while doing the work.

Alternatively, open a FreeType bug tracker issue and fill it with all
the necessary data.

Or do both :-)

Whatever you are going to choose, please send a draft to me and Alexei
privately in advance so that we can review it.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

>> This mostly matters on 32-bit build without FT_LONG64. Forget about
>> it for now but don't lose the patch. Do you mind sharing it?
> 
> I've pushed it to `ewaldhew-wip'.

Thanks.

> Also, I have questions regarding final submission guidelines. I am
> supposed to provide a stable link, I'm thinking of a commit range on
> master on cgit, since Savannah has no "merge request" functionality.

OK.

> Werner, what are your plans for merging the code?

I'll use `format-patch' to extract the patches, then construct proper
ChangeLog entries (based on your commit messages) and commit them to
master.  Finally, I'll walk over the complete code and apply cosmetic
polishing where necessary :-)

> Or any specific way you had in mind for us to consolidate all our
> work for submission (for archival purposes too)?  Could also keep
> the working clean branch forever, or push a clone to github.

Yes, keeping your branch makes sense – it should probably renamed so
that `GSoC 2017' appears in its name.  Additionally, all your other
activity is already archived – one of the reasons I asked for
communication over the `freetype-devel' list.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

> This mostly matters on 32-bit build without FT_LONG64. Forget about it for 
> now but don't lose the patch. Do you mind sharing it?

I've pushed it to `ewaldhew-wip'.

Also, I have questions regarding final submission guidelines. I am
supposed to provide a stable link, I'm thinking of a commit range on
master on cgit, since Savannah has no "merge request" functionality.
Werner, what are your plans for merging the code? Or any specific way
you had in mind for us to consolidate all our work for submission (for
archival purposes too)? Could also keep the working clean branch
forever, or push a clone to github.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Dave Arnold]

It should be pretty common when stem darkening is in effect. But it is not used 
otherwise.

-Dave


On 8/20/2017 10:31 PM, Werner LEMBERG wrote:

It is interesting that `cf2_glyphpath_computeIntersection' never
seems to get called...

I think `normal' CFFs don't do that...

Dave, do you have an example font that actually needs this function?


 Werner
.



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Alexei Podtelezhnikov]

On Aug 21, 2017, at 00:23, Ewald Hew  wrote:

>> [...]
>> This is just two things I noticed quickly. If you have time, you might
>> find some speed gains this way.
> 
> I tested after doing other similar changes, but any improvement was
> within margin of error. It is interesting that
> `cf2_glyphpath_computeIntersection' never seems to get called...

This mostly matters on 32-bit build without FT_LONG64. Forget about it for now 
but don't lose the patch. Do you mind sharing it?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

> It is interesting that `cf2_glyphpath_computeIntersection' never
> seems to get called...

I think `normal' CFFs don't do that...

Dave, do you have an example font that actually needs this function?


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

> [...]
> This is just two things I noticed quickly. If you have time, you might
> find some speed gains this way.

I tested after doing other similar changes, but any improvement was
within margin of error. It is interesting that
`cf2_glyphpath_computeIntersection' never seems to get called...

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Dave Arnold]

Hi Werner,

You are correct that CoolType does not have the improvement that the initial 
hintmap was designed for. It also does not have some of the heuristics that 
improve rendering of complex CJK glyphs. On the other hand, CoolType has more 
code devoted to rendering bilevel bitmaps. (In the early days of PostScript, 
that was the only kind of rendering.)

-Dave


On 8/15/2017 10:27 PM, Werner LEMBERG wrote:

Hello Dave,


thanks for your detailed response.


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.

OK, I thought something along this line.  Given that you write

   The main motivation for the initial hintmap feature was to deal with
   distortions caused by blue zones.  [...]

I wonder whether CoolType's hinting engine produces inferior results
compared to the engine Adobe has contributed to FreeType...


I suppose you could disable the use of the initial hintmap for Type 1
charstrings only.

If I understand correctly, this is what Ewald started with, and he got
bad results...


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.

Thanks for confirmation!

Ewald, have you already done some benchmarks?


 Werner
.



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Alexei Podtelezhnikov]

Ewald,

Here
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/psaux/pshints.c?h=ewaldhew-wip#n1251
FT_DivFix is followed by 2 FT_MulFix's. It could be faster to do
combine them into two FT_MulDiv's.

Here
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/psaux/pshints.c?h=ewaldhew-wip#n1583
The fixed number is the first argument. This is contrary to FT_MulFix
recommendation to place larger bit-value second.

This is just two things I noticed quickly. If you have time, you might
find some speed gains this way. I did this a while back for the rest
of FreeType when the Adobe engine was just donated. I did not want to
mess with it then.

Alexei


On Thu, Aug 17, 2017 at 10:34 PM, Ewald Hew  wrote:
>> Are you benchmarking a 32-bit build? How unfashionable of you :)
>
> The system-provided version is 32-bit (not sure why??). After properly
> linking I have a 64-bit build, and FT_DivFix does not seem to be a
> problem any more :-)
>
>> https://savannah.nongnu.org/bugs/?43248
>
>> Now I have that the glyphpath procedures take a bulk of the time.
>> What's interesting is the hinting functions get called from these,
>> regardless of the load flags, and probably explains why it's roughly
>> the same hinted or not. This seems wrong IMO, as we should be ignoring
>> hints accordingly, but the call graph shows `cf2_hintmap_build',
>> `cf2_hintmap_insertHint', and the like being used, which account for a
>> sizeable chunk of time.
>>
>> I will investigate this further. Probably the `hinted' flag is being
>> ignored somehow.
>
> Some success here.
>
> Disabling hinting stuff properly when hinting is off gave a speed
> boost of about a third. Still not as much an improvement as turning
> off hinting in the old engine.
>
> Here is my data from testing:
> FT_Load_Glyph:`adobe' (units: us/op)
> flags  time
> 0x07.844
> 0x15.212
> 0x25.079
>
> I've pushed the code changes to `ewaldhew-wip'. Please check.
>
> Ewald



-- 
Alexei A. Podtelezhnikov, PhD

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

> Are you benchmarking a 32-bit build? How unfashionable of you :)

The system-provided version is 32-bit (not sure why??). After properly
linking I have a 64-bit build, and FT_DivFix does not seem to be a
problem any more :-)

> https://savannah.nongnu.org/bugs/?43248

> Now I have that the glyphpath procedures take a bulk of the time.
> What's interesting is the hinting functions get called from these,
> regardless of the load flags, and probably explains why it's roughly
> the same hinted or not. This seems wrong IMO, as we should be ignoring
> hints accordingly, but the call graph shows `cf2_hintmap_build',
> `cf2_hintmap_insertHint', and the like being used, which account for a
> sizeable chunk of time.
>
> I will investigate this further. Probably the `hinted' flag is being
> ignored somehow.

Some success here.

Disabling hinting stuff properly when hinting is off gave a speed
boost of about a third. Still not as much an improvement as turning
off hinting in the old engine.

Here is my data from testing:
FT_Load_Glyph:`adobe' (units: us/op)
flags  time
0x07.844
0x15.212
0x25.079

I've pushed the code changes to `ewaldhew-wip'. Please check.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

> Ewald, are you using freetype2-demos/bin/* wrapper scripts? They
> supposed to LD_PRELOAD from the neighboring freetype2/objs/.libs
> folder. Even standard (not devel) build works for me like this.

Hm... when I used those, callgrind seemed to be unable to capture the
process, grabbing statistics for bash, libc, etc instead. Strangely it
captures around 5 or 6 processes. I then switched to using
freetype2-demos/bin/.libs/* which were captured properly and only
produced one output file.

> By the way, there is this outstanding bug
> https://savannah.nongnu.org/bugs/?43248. Perhaps you can profile the
> engine and post the details.

Yes, that is the bug I am referencing here.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

> By the way, there is this outstanding bug
> https://savannah.nongnu.org/bugs/?43248.  Perhaps you can profile
> the engine and post the details.

Uh, oh, he is doing this partly for this very bug report – you
recommended to him to have a look :-)


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

>   git clean -fdx
>   git reset --hard  # or manually check for missing files/interfering changes
>   make devel
>   make

Thanks, it works now.

I've managed to reproduce the slow load times, turns out I had forgot
to compile CFF old engine and it was using the new engine
regardless(whoops!).

Now I have that the glyphpath procedures take a bulk of the time.
What's interesting is the hinting functions get called from these,
regardless of the load flags, and probably explains why it's roughly
the same hinted or not. This seems wrong IMO, as we should be ignoring
hints accordingly, but the call graph shows `cf2_hintmap_build',
`cf2_hintmap_insertHint', and the like being used, which account for a
sizeable chunk of time.

I will investigate this further. Probably the `hinted' flag is being
ignored somehow.

As for FT_DivFix, maybe it is a good idea to optimize this but this
kind of specific optimization is somewhat beyond me right now... might
be an area for me to research into first.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Alexei Podtelezhnikov]

>> In fact, it seems like the demos
>> are linking to my system-provided libfreetype instead of the git
>> devel one, hence no debug information. I'm trying to fix that right
>> now.
>
> Are you doing a `developer's build' (i.e., `make devel; make' in
> `freetype2', then a simple `make' in `freetype2-demos')?  This should
> create statically linked binaries quite easily.

Ewald, are you using freetype2-demos/bin/* wrapper scripts? They
supposed to LD_PRELOAD from the neighboring freetype2/objs/.libs
folder. Even standard (not devel) build works for me like this.

>> I have noticed that FT_DivFix (and it's callees) account for a
>> decent proportion of the runtime, around 18% or so.
>
> We only provide assembler code (or compiler-specific optimizations)
> for `FT_MulFix'.  Maybe it makes sense to try something similar for
> `FT_DivFix' also...

Are you benchmarking a 32-bit build? How unfashionable of you :) Only
on 32-bit platforms with 64-bit division available (like x86), it is
worth doing assembly optimization. Divisions are slow and should be
avoided in cycles. I would suggest analyzing the code first.

By the way, there is this outstanding bug
https://savannah.nongnu.org/bugs/?43248. Perhaps you can profile the
engine and post the details.

Alexei

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

>>   git clean -fdx  (Use with caution!  Check before with `git clean -ndx)
>>   make devel
>>   make
> 
> I get:
>  config.mk:25: builds/unix/unix-def.mk: No such file or directory
>  config.mk:26: builds/unix/unix-cc.mk: No such file or directory
>  make: execvp: ./include/freetype/freetype.h: Permission denied
>  make: *** No rule to make target 'builds/unix/unix-cc.mk'.  Stop.

Ah, my mistake.  It's

  git clean -fdx
  git reset --hard  # or manually check for missing files/interfering changes
  make devel
  make

> After running `configure' in freetype root directory, it gives me
> make: Nothing to be done for 'devel'.

For `make devel' you must not run `configure'.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

>   git clean -fdx  (Use with caution!  Check before with `git clean -ndx)
>   make devel
>   make

I get:
 config.mk:25: builds/unix/unix-def.mk: No such file or directory
 config.mk:26: builds/unix/unix-cc.mk: No such file or directory
 make: execvp: ./include/freetype/freetype.h: Permission denied
 make: *** No rule to make target 'builds/unix/unix-cc.mk'.  Stop.

After running `configure' in freetype root directory, it gives me
 make: Nothing to be done for 'devel'.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

>> Are you doing a `developer's build' (i.e., `make devel; make' in
>> `freetype2', then a simple `make' in `freetype2-demos')?  This
>> should create statically linked binaries quite easily.
> 
> Strange... make insists that there is nothing to be done for
> `devel'.  What am I missing?

  git clean -fdx  (Use with caution!  Check before with `git clean -ndx)
  make devel
  make

works for me.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

> Are you doing a `developer's build' (i.e., `make devel; make' in
> `freetype2', then a simple `make' in `freetype2-demos')?  This should
> create statically linked binaries quite easily.

Strange... make insists that there is nothing to be done for `devel'.
What am I missing?

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

>> Ewald, have you already done some benchmarks?
> 
> I finally got the freetype2-demos to work with callgrind, but many
> of the calls have no debug label.  In fact, it seems like the demos
> are linking to my system-provided libfreetype instead of the git
> devel one, hence no debug information. I'm trying to fix that right
> now.

Are you doing a `developer's build' (i.e., `make devel; make' in
`freetype2', then a simple `make' in `freetype2-demos')?  This should
create statically linked binaries quite easily.

> I have noticed that FT_DivFix (and it's callees) account for a
> decent proportion of the runtime, around 18% or so.

We only provide assembler code (or compiler-specific optimizations)
for `FT_MulFix'.  Maybe it makes sense to try something similar for
`FT_DivFix' also...


   Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

Thanks Dave for the helpful explanation!

>> I suppose you could disable the use of the initial hintmap for Type 1
>> charstrings only.
>
> If I understand correctly, this is what Ewald started with, and he got
> bad results...

No, it was always enabled, but built wrongly as we don't have all the
hints at the start.

> Ewald, have you already done some benchmarks?

I finally got the freetype2-demos to work with callgrind, but many of
the calls have no debug label. In fact, it seems like the demos are
linking to my system-provided libfreetype instead of the git devel
one, hence no debug information. I'm trying to fix that right now.

I have noticed that FT_DivFix (and it's callees) account for a decent
proportion of the runtime, around 18% or so.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

Hello Dave,


thanks for your detailed response.

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

OK, I thought something along this line.  Given that you write

  The main motivation for the initial hintmap feature was to deal with
  distortions caused by blue zones.  [...]

I wonder whether CoolType's hinting engine produces inferior results
compared to the engine Adobe has contributed to FreeType...

> I suppose you could disable the use of the initial hintmap for Type 1
> charstrings only.

If I understand correctly, this is what Ewald started with, and he got
bad results...

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

Thanks for confirmation!

Ewald, have you already done some benchmarks?


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

>> OK, I'll be finding a way to add this in with minimal clutter to
>> the code.  I'm thinking to add an extra check to the top to skip
>> stuff other than stem hints first time round, then rewinding on
>> `endchar'.
>
> Done. Pushed along with some other minor changes.
>
> I've checked this with all the known bad glyphs, and they render
> fine now, with the correct initial hintmap.

Great!  As I can see, the changes are surprisingly small and clear,
which is good.

> One issue remains, from MunhwaGothic if you recall, the right
> pointing hand (U+261E).  I checked against another font, which looks
> fine.  From the debug output, it's likely the former has
> bad/insufficient hints, and perhaps the Adobe hinter is slightly
> overzealous in moving points.
>
> In this case, it is better to use the autohinter or turn off
> hinting, but I wonder if we could, or should, detect such a case, or
> to leave the judgement call to the user?

Using the auto-hinter for a single glyph among other glyphs controlled
by PS hints is no option here; the vertical scaling differences are
usually far too noticeable.  What I can imagine – in case it is really
possible to detect such bad hints – is to apply a glyph-wide scaling
derived from the initial hintmap so that the glyph has the same
vertical size as other glyphs do have, ignoring all other, faulty
hints.

> OTOH, it only goes messy at low ppem, at usual reading sizes, the
> wonkiness is considerably less.  Perhaps nothing needs to be done
> (the fault does lie with the font...).

Yes, this is always an option :-)


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

> OK, I'll be finding a way to add this in with minimal clutter to the
> code. I'm thinking to add an extra check to the top to skip stuff
> other than stem hints first time round, then rewinding on `endchar'.

Done. Pushed along with some other minor changes.

I've checked this with all the known bad glyphs, and they render fine
now, with the correct initial hintmap.

One issue remains, from MunhwaGothic if you recall, the right pointing
hand (U+261E). I checked against another font, which looks fine. From
the debug output, it's likely the former has bad/insufficient hints,
and perhaps the Adobe hinter is slightly overzealous in moving points.

In this case, it is better to use the autohinter or turn off hinting,
but I wonder if we could, or should, detect such a case, or to leave
the judgement call to the user?

OTOH, it only goes messy at low ppem, at usual reading sizes, the
wonkiness is considerably less. Perhaps nothing needs to be done (the
fault does lie with the font...).

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

>> 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).
>
> Well, yes.
>
> Monochrome?  Please explain.  I think there no longer exists an
> environment where Acroread would return monochrome images...

Never mind, I wanted to have the same conditions as my ftgrid/ftview
results so as to compare on the same basis, but I'll just change those
to LCD mode instead.

> Attached are two solutions for xelatex; [...]

Thanks, I'll try it.

> OK.  So it seems we have to go this route.  Given that Type 1 fonts
> are no longer important today (combined with faster and faster
> computers), we certainly can live with a second pass.

OK, I'll be finding a way to add this in with minimal clutter to the
code. I'm thinking to add an extra check to the top to skip stuff
other than stem hints first time round, then rewinding on `endchar'.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

> \documentclass{article}
> 
> \input{binhex}

Oops, outdated version.  Here's a better one for the compact output.


Werner
\documentclass{article}

\usepackage{fontspec}

\setmainfont{Linux Libertine O}

\usepackage{multido}

\setlength{\parindent}{0pt}

\begin{document}

\multido{\i=0+1}{"11}{% from U+ to U+10
  \iffontchar\font\i
\symbol{\i}
  \fi
}

\end{document}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

> Our complication is that we must be placing outline points alongside
> reading the hints, and adjusting the former accordingly.

OK, makes sense.  So it seems boiling down to the question how to
optimally hint Type1, right?

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

Well, yes.

> They're certainly the two different formats (looking at the line
> gap), and the problematic glyph "u" looks hinted correctly.

OK.

> However, to reproduce the results from ftgrid, I'll need it to
> render in monochrome.

Monochrome?  Please explain.  I think there no longer exists an
environment where Acroread would return monochrome images...

> What do you do to test fonts with Acroread?

Nothing special.  In most cases, people report a problem with a font
already embedded in a PDF.

> If only there is a utility that could take in a font file, and
> generate a pdf with all glyphs?

Attached are two solutions for xelatex; you just have to set the right
font (using font names returned by fontconfig's `fc-list') in the
`\setmainfont' macro, then call

  xelatex charlist

for the compact version or

  xelatex charlistx

for a version that shows character codes also (using the same font).

[This should work on Windows and Macs also, BTW – I assume that you
have TeXLive installed :-)]

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

OK.  So it seems we have to go this route.  Given that Type 1 fonts
are no longer important today (combined with faster and faster
computers), we certainly can live with a second pass.


Werner

\documentclass{article}

\input{binhex}
\usepackage[margin=1cm]{geometry}
\usepackage{fontspec}

\setmainfont{Linux Libertine O}

\usepackage{multicol}
\usepackage{multido}

\setlength{\parindent}{0pt}

\begin{document}

\multido{\i=0+1}{"11}{% from U+ to U+10
  \iffontchar\font\i
\symbol{\i}\,
  \fi
}

\end{document}
\documentclass[landscape]{article}

\input{binhex}
\usepackage[margin=1cm]{geometry}
\usepackage{fontspec}

\setmainfont{Linux Libertine O}

\usepackage{multicol}
\usepackage{multido}

\setlength{\parindent}{0pt}

\begin{document}

\begin{multicols}{9}
\multido{\i=0+1}{"11}{% from U+ to U+10
  \iffontchar\font\i
\makebox[5em][l]{0x\nhex{4}{\i}}%
\symbol{\i}\endgraf
  \fi
}
\end{multicols}

\end{document}
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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:

  -13 -10 58 -12 14 386 14 hstemhm
  80 84 178 84 hintmask 0000
  488 50 rmoveto
  -35 callsubr
  hintmask 10111000
  -34 callsubr
  hintmask 0000
  -33 callsubr
  endchar


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
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

>>> 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
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

>> 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):

T1_Load_Glyph: glyph index 86  | cff_glyph_load: glyph index 86
Initial hintmap  Initial hintmap
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
 0.00 0.00655  gbLS|-10.00 0.00655  pbL
   > 48.0058.00655  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
(adjusted)   (adjusted)
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
 0.00 0.00731  gbLS|-10.00 0.00655  pbL
   > 48.0052.54723  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
Hints:   Hints:
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
36.0040.99655  pb  | 36.0046.00655  pb
50.0054.99655  pt  | 50.0060.00655  pt
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
(adjusted)   (adjusted)
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
36.00 0.00655  pb  | 36.0086.05655  pb
50.0011.45801  pt  | 50.00   100.05655  pt
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
Hints:   Hints:
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
   -10.00 0.00655  pbL  -10.00 0.00655  pbL
48.0058.00655  ptL   48.0058.00655  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
(adjusted)   (adjusted)
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
   -10.00 0.00655  pbL  -10.00 0.00655  pbL
48.0052.54723  ptL   48.0052.54723  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
Hints:   Hints:
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
36.0040.99655  pb  | 36.0086.05655  pbL
50.0054.99655  pt  | 50.00   100.05655  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
(adjusted)   (adjusted)
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
36.00 0.00655  pb  | 36.0086.05655  pbL
50.0011.45801  pt  | 50.00   100.05655  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
ptsize =10   ptsize =10
Execution completed successfully.Execution completed successfully.

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.

Ewald
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

> Please give an exact recipe how you configure and compile FreeType (on
> what platform?), and how you call valgrind (which version, BTW?) –
> I'll try to reproduce.

I'm using Debian 8.9 (jessie).

I've always compiled FreeType with the provided makefile, which calls
gcc with -g and -O2 for everything. The only option I changed from
master branch is defining FT_DEBUG_LEVEL_TRACE.

Then I ran:
 $ valgrind --tool=callgrind bin/ftbench -b a -f 1 ~/SourceHanSans-Regular.otf
 $ kcachegrind

valgrind is of version 3.10.0 and kcachegrind is of version 0.7.4kde

In other words, I'm running with mostly default settings, and the
documentation for callgrind did not mention any special steps to take,
it seemed like it should have worked straight out of the box...

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

>> What did you exactly do?
> 
> I just followed the instructions in callgrind manual
> (http://valgrind.org/docs/manual/cl-manual.html#cl-manual.basics). I
> confirmed that FreeType was compiling with -g and used kcachegrind
> as the visualiser.

Please give an exact recipe how you configure and compile FreeType (on
what platform?), and how you call valgrind (which version, BTW?) –
I'll try to reproduce.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

[Dave, please comment!]

> Refer to diff.txt.

Nice!

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

Maybe it makes sense to mention the abbreviations once in the tracing
output.

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

I wouldn't have thought that...

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

Dave, how is that handled in Adobe's Type1->CFF converter?  Do you get
similar rendering differences?  Does the old Adobe Type1 engine hint
on the fly, or does it perform two passes, where the first pass builds
a hintmap so that hints are `optimized' for the whole glyph, and the
second pass does the actual hinting?


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

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

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
(http://valgrind.org/docs/manual/cl-manual.html#cl-manual.basics). I
confirmed that FreeType was compiling with -g and used kcachegrind as
the visualiser.

Ewald
FT_Stream_Open: could not open `/home/ewaldhe | cff_glyph_load: glyph index 126
FT_Stream_Open: could not open `/home/ewaldhe <
T1_Load_Glyph: glyph index 126<
Initial hintmap Initial hintmap
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00655  gbL   0   0.00 0.00
655  gbL
  > 6 672.00   739.44
655  pbL
  > 6 733.00   800.44
655  ptL
(adjusted)  (adjusted)
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00655  gbL | 0   0.00 0.00
721  gbL
  > 6 672.00   739.44
655  pbL
  > 6 733.00   800.44
655  ptL
Hints:  Hints:
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00655  gbL   0   0.00 0.00
655  gbL
1 120.00   120.00655  pb  | 1 120.00   135.16
655  pb
1 181.00   181.00655  pt  | 1 181.00   196.17
655  pt
2 252.00   252.00655  pb  | 3 252.00   280.52
655  pb
2 314.00   314.00655  pt  | 3 314.00   342.52
655  pt
(adjusted)  (adjusted)
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00759  gbL   0   0.00 0.00
759  gbL
1 120.00   139.11655  pb1 120.00   139.11
655  pb
1 181.00   142.01923  pt1 181.00   142.01
923  pt
2 252.00   300.16655  pb3 252.00   300.16
655  pb
2 314.00   362.16655  pt3 314.00   362.16
655  pt
Hints:  Hints:
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00655  gbL   0   0.00 0.00
655  gbL
1 133.00   133.00655  pb  | 2 133.00   148.82
655  pb
1 181.00   181.00655  pt  | 2 181.00   196.82
655  pt
2 252.00   252.00655  pb  | 3 252.00   300.16
655  pbL
2 314.00   314.00655  

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

[Werner LEMBERG]

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

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

> As for the profiling, I was unable to reproduce the difference in
> load times.
> 
> ftbench results for font `SourceHansSans-Regular.otf':
> FT_Load_Glyph(units: us/op)
> flags  adobe   freetype
> 0x014.628  14.193
> 0x113.088  13.160
> 0x213.674  13.147
> 
> Note: This was done on master branch.

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

> I ran it with valgrind too but couldn't get useful information.

What did you exactly do?


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Ewald Hew]

> I suggest that you add tracing messages.  For example, the attached
> excerpt from a log file shows what the auto-hinter emits for glyph
> index 2 of the font `c059013l.pfb' (URW Century Schoolbook L Roman
> version 1.06).  I called
>
>   FT2_DEBUG=any:7 ftview 20 c059013l.pfb &> c059013l.log
>
> then pressing key `f' to enforce full auto-hinting.
>
> As you can see, it is quite detailed.
> Table of points:
> Table of horizontal segments:
> Table of vertical segments:
> Table of horizontal edges (1px=48.13u, 10u=0.21px):
> Table of vertical edges (1px=50.00u, 10u=0.20px):

These would be really useful, I guess I'll start by adding something
of this sort to the Adobe hinter too. I somehow hadn't seen these
tables before, despite running with "any:7" most of the time.

> A starting point might be running ftbench with a profiler.  I
> sometimes use valgrind for that:
>
>   valgrind --tool=callgrind ...
>
> The resulting data can then be visualized with `kcachegrind'.  There
> are certainly other profiling tools that you might find helpful.

Thanks for the advice!

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

[Werner LEMBERG]

> You might (or might not?) have noticed, I've pushed all changes into
> `ewaldhew-cleaned' a few days ago.

I noticed, thanks, but I'm still on vacation, so it will take some
time until I can comment on more details.

> I've been comparing the charstrings and hinter movements, but the
> lack of visualization makes this tedious.  Nothing stands out as
> being the culprit, and each time I find a possible cause, I'd find
> the same pattern in some other glyph that renders fine.

I suggest that you add tracing messages.  For example, the attached
excerpt from a log file shows what the auto-hinter emits for glyph
index 2 of the font `c059013l.pfb' (URW Century Schoolbook L Roman
version 1.06).  I called

  FT2_DEBUG=any:7 ftview 20 c059013l.pfb &> c059013l.log

then pressing key `f' to enforce full auto-hinting.

As you can see, it is quite detailed.

In general, more tracing data is always a good thing; it might also
help later developers follow your changes (and earlier ones) step by
step.

> Besides this issue, I'm also meaning to look into the issue of slow
> CFF loading (bug #43248) mentioned by Alexei at the start. Not sure
> where to start, so I'd be glad for any advice.

A starting point might be running ftbench with a profiler.  I
sometimes use valgrind for that:

  valgrind --tool=callgrind ...

The resulting data can then be visualized with `kcachegrind'.  There
are certainly other profiling tools that you might find helpful.

> For now, this is what I'll be doing for this final phase.  Of
> course, there's also fixing up all the documentation, and more bugs
> may yet rear their ugly head...

:-)


Werner
T1_Load_Glyph: glyph index 2

Start charstring
 (0) 87 296 hsbw
 (0) -14 125 hstem
 (0) 716 20 hstem
 (0) 82 191 rmoveto
 (0) 1 176 4 50 19 94 rrcurveto
 (0) 14 70 4 31 0 29 rrcurveto
 (0) 64 -20 31 -41 vhcurveto
 (0) -41 -21 -32 -62 hvcurveto
 (0) 0 -30 4 -31 14 -70 rrcurveto
 (0) 19 -94 3 -47 2 -179 rrcurveto
 (0) closepath
 (0) 20 -80 rmoveto
 (0) -35 -28 -28 -34 hvcurveto
 (0) -35 28 -28 34 vhcurveto
 (0) 35 28 28 35 hvcurveto
 (0) 34 -28 28 -34 vhcurveto
 (0) closepath
 (0) endchar

  x advance: 296
  y advance: 0
  linear x advance: 296
  linear y advance: 0
latin vertical edge hinting (style `latn_dflt')
  ANCHOR: edge 0 (opos=1.77) and 3 (opos=4.22) snapped to 2.00 and 4.22
  LINK: edge 3 (opos=4.22) linked to 4.09, dist was 2.45, now 2.09
  STEM: edge 1 (opos=2.55) linked to 2 (opos=3.38) snapped to 3.00 and 4.00
  ADJUST: edge 3 (pos=4.09) moved to 4.09

latin horizontal edge hinting (style `latn_dflt')
  BLUE_ANCHOR: edge 0 (opos=-0.30) snapped to 0.00, was -0.30 (anchor=edge 0)
  LINK: edge 1 (opos=2.31) linked to 2.84, dist was 2.61, now 2.84
  BLUE: edge 3 (opos=15.30) snapped to 15.00, was 15.30
  SERIF_LINK1: edge 2 (opos=3.97) snapped to 4.39 from 1 (opos=2.31)

Table of points:
  index  hedge  hseg  vedge  vseg  flags   xorg  yorg  xscale  yscale   xfit
yfit
  0  2 1  2 0  strong   169   1913.383.974.00   
 4.39
  1 ----  2 0   weak170   3673.417.624.00   
 7.81
  2 ---- ----   weak174   4173.488.674.02   
 8.80
  3 ---- ----   weak193   5113.86   10.624.05   
10.62
  4 ---- ----   weak207   5814.14   12.084.08   
11.98
  5 ----  3 1   weak211   6124.22   12.724.09   
12.58
  6 ----  3 1   weak211   6414.22   13.314.09   
13.14
  7 ----  3 1   weak211   7054.22   14.664.09   
14.41
  8  3 0 ----   weak191   7363.81   15.303.75   
15.00
  9  3 0 ----   weak150   7363.00   15.303.05   
15.00
 10  3 0 ----   weak109   7362.19   15.302.36   
15.00
 11 ----  0 2   weak 88   7041.77   14.622.00   
14.38
 12 ----  0 2   weak 88   6421.77   13.342.00   
13.17
 13 ----  0 2   weak 88   6121.77   12.722.00   
12.58
 14 ---- ----   weak 92   5811.84   12.082.11   
11.98
 15 ---- ----   weak106   5112.12   10.622.48   
10.62
 16 ----  1 3   weak125   4172.508.673.00   
 8.80
 17 ----  1 3   weak128   3702.567.693.00   
 7.88
 18  2 1  1 3  strong   130   1912.593.973.00   
 4.39

 19  1 2 ----   weak150   1113.002.313.06   
 2.84
 20  1 2 ----   weak115   1112.302.312.47   
 2.84
 21 ----  0 4   weak 87831.731.722.00   
 2.20
 22 ----  0 4   weak 87491.731.022.00   
 1.44
 23 ----  0 4   weak 87