Re: [Devel] Curves that make you hmmmmm....

[David Turner]

Hi Tom,

Tom Kacvinsky a écrit :
> 
> I just saw a proposed change go by one the ghostscript lists that started as
> (in effect):
> 
> in a TT font, there may be curves that *start* on an off-curve point...
> 
> The operative word being start, and the crucial point (no pun intended) being
> that this point is off curve.  This cannot happen with a Type 1 font just 
> because
> of how the Type 1 operators work.  But it may be possible in a TT font.   So, 
> how
> does FT handle this in the TT curve constructor?  I admit I haven't looked
> yet...
> 

FT handles these cases nicely, both in 1.x and 2.0 :-)
We ran into some Japanese fonts with this "feature" rather early
I think..

> Also, while I am at it, I ran across a True Type CID font in a PDF file (from
> some ghostscript testing I was doing) that when printed from Acrobat had 
> glyphs
> whose path intersections were "painted" white.  This, I think, is a bug in
> whatever Type 42 rasterizer exists in the printer.  But this raises a 
> question:
> how does FT handle TT glyphs which are drawn as a set of overlapping paths?  
> For
> a Type 1 font, one would find the paths that trace the overall shape of the
> overlapping paths (such that the final paths have no overlap) and use those 
> new
> paths in the actual font, but for a TT font, this has to happen on the fly.
> Actually, it may have to happen on the fly for Type 1 fonts.  If I recall
> correctly, the T1 spec doesn't explicitly state that it is technically 
> incorrect
> for two paths to overlap, though it does recommended that this not happen.
> 
The renderers use either the "non-zero" or "odd-even" winding rules to fill
overlapping segments. The default is "non-zero", but this can be changed
by toggling the "ft_outline_even_odd_fill" flag in the "flags" field
of a FT_Outline.

Overlapping paths are however not encouraged because they may be a lot harder
to hint properly in some cases :-)

> Anyway, I suspect that the path overlap problem is not taken care of during
> curve construction time (at least this is true for CFF and Type 1 fonts).
> Rather, the overlap problem is taken care of at rasterization time.  Just fill
> paths 1 through n, using some curve filling method that fills the 
> intersection of
> two overlapping paths with black.
> 
> Am I on the right track?
> 
Yes :-)

- David