Re: Bug in T1 rendering?

[Tom Kacvinsky]

Attached is a patch that fixes this problem.

The general problem is that the h/v/rmoveto operators were implemented
in such a fashion that path_begun was set equal to zero.  So, at the
end of a flex path, the next operator after the "0 callsubr" was
setting path_begun to 1 (be it a rrcurveto, v/h/rlineto, etc...), and
so now the path has more than one start point.

Without delving into the internals of path representation, the paths
were then closed twice:  once to take to the start point at the end of
the flex path, and then again to the actual start point of the path.

The patch just makes sure that if h/v/rmoveto is invoked while a flex
path is being built that path_begun is not set back to 0.

Regards,

Tom

On 5 Oct 2000, Alan Shutko wrote:

> I just checked out freetype2 and ft2demos from CVS to try out the T1
> renderer.  Overall, it rendered remarkably well.  But I discovered
> some problems with one of my favorite fonts: Spectrum purchased from
> Adobe.
> 
> Take a look at http://rescomp.wustl.edu/~ats/ftview-bug.png .
> Naturally, that weird inverse effect doesn't happen with any other
> renderer I've tried.  This is the ekrg____.pfb (Spectrum MT Regular),
> but it happens with all the fonts in the family.  I have not yet seen
> this happen with any freely available fonts (or any other fonts at
> all.)  Happens with or without hinting, with or without aliasing.
> 
> Any clues on how to track this down?
> 
>

t1decode.ch
Description: Text document