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

[Werner LEMBERG]

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

This works in FT.

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

AFAIK, there is no problem in FT: For rendering, it works without
problems (check the famous `Aring' glyph in times.ttf).  Of course,
converting to real outlines is not implemented; it would be necessary
to do topological analysis to merge overlapping paths.  BTW, do you
have a (free) C implementation to do that?  It would be a very useful
module for FreeType!  Volunteers?  [I only know a Metafont package
called `roex' which is also part of the `mftoeps' package (so says the
readme file -- I haven't used either package.]  Not being able to
solve this problem was one of the reasons that I've stopped working on
ttf2pfb.  Does somebody know whether ttf2pt1 handles this gracefully?

> 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, I think so.  Currently I don't know whether FT's rasterizer
changes blackened pixels back to white if necessary.  David may give a
better answer.


    Werner