freetype
[Top][All Lists]
Advanced

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

FIXED: Start points of contours & rasterizer


From: Tom Kacvinsky
Subject: FIXED: Start points of contours & rasterizer
Date: Tue, 10 Oct 2000 11:04:53 -0400 (EDT)

Found it!

It is a (in my opinion) a subtle bug in the font.

The last drawing operator for the contour in /integraldisplay is:

-36 -25 23 0 hvcurveto

This translates to:

-36 0 -25 -23 0 0 rrcurveto.

Now, the last point on the curve is the firtst point on the curve, so the
closepath operator (which in freetype2 means call close_contour) result in the
last on-curve point being deleted.  Then endchar is called, which results in
another close_contour.  But because the last delta was (0,0), the last control
point also has the same coordinates as the last point.  So we remove yet another
point, which, in this case, is a control point!  Oops!

The fix, I think, is to check to make sure we don't delete a control point.

Attached is a patch for this. I recommend that the same ideas be incorporated
into the CFF driver.  I'll ask the folks at Adobe if it is legal to have such a
drawing command (as listed above).  ATM doesn't seem to mind it, so I think I 
know what the answer is...

Regards,

Tom

On Tue, 10 Oct 2000, Tom Kacvinsky wrote:

> I do not have the problem with /x from eurm10 nor with /X from eusm10.  ftview
> shows these glyphs properly.  I think that the problem you are having with /x
> and /X has not much to do with the rasterizer, but rathter, something in your
> code... :(
> 
> I am still looking into the /integraldisplay problem in CMEX10.  I am making
> some progress there...
> 
> Tom
> 
> On Mon, 9 Oct 2000 address@hidden wrote:
> 
> > >In reply to Tom Kacvinsky <address@hidden>
> > >>
> > >>Well, I think I might be mistaken (go figure. me, wrong? ;).
> > >>
> > >>I have an OpenType version of CMEX10 that I made with Adobe's OT FDK.  
> > >>When I
> > >>disassemble the CFF table, I see that the start point of /integraldisplay 
> > >>is
> > >>exactly the same as the start point in the Type 1 PFA/PFB.  Yet the CFF 
> > >>version
> > >>of the font views properly with ftview, and the Type 1 version does not.
> > >>Weird...
> > >>
> > >>Tom
> > >>
> > >
> > >but wait, there's more!
> > >
> > >glyph 120 from eurm10.pfb (a small and innocent looking "x")
> > >
> > >also breaks my code
> > 
> > and glyph 88 from eusm10...
> > 
> > --
> > Cesar Augusto Rorato Crusius    __o      __o      __o      __o      __o    
> > Stanford University           _`\<,    _`\<,    _`\<,    _`\<,    _`\<,    
> > e-mail:address@hidden    (_)/(_)  (_)/(_)  (_)/(_)  (_)/(_)  (_)/(_)   
> > www.stanford.edu/~crusius
> >                                        o      _     _         _
> >    __o      __o      __o      __o     /\_   _ \\o  (_)\__/o  (_)
> >  _`\<,    _`\<,    _`\<,    _`\<,    _>(_) (_)/<_    \_| \   _|/' \/
> > (_)/(_)  (_)/(_)  (_)/(_)  (_)/(_)  (_)        (_)   (_)    (_)'  _\o_
> > 
> > He who sacrifices functionality for ease of use
> > Loses both and deserves neither
> > 
> 

Attachment: psobjs.ch
Description: Text document


reply via email to

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