Re: Start points of contours & rasterizer [was: Need help on dvi viewer with freetype]

[Tom Kacvinsky]

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

On Sun, 8 Oct 2000, Tom Kacvinsky wrote:

> Hi all,
> 
> I found what I think may be the source of the problem:
> 
> /integraldisplay has *exactly* one coutour, and the start point of this 
> coutour
> is at a cusp (i.e., the contour is not differentiable at this point).
> 
> The glyph /contintegraldisplay has three contours, the first contour of which
> also starts at a cusp.
> 
> If I change the start point of /integraldisplay so that it is not on a cusp, 
> the
> problem goes away.
> 
> Since I beleive that the Type 1 parser is working correctly for this font, I
> suspect something with the rasterizer.  It makes no sense for the parser to 
> fail
> on /integraldisplay and succeed on /contintegraldisplay.  It makes some sense
> that the rasterizer would fail on both if it fails on one, but why does it
> succeed on /contintegraldisplay and not /integraldisplay ?
> 
> Tom
> 
> On Sun, 8 Oct 2000, Tom Kacvinsky wrote:
> 
> > Well, it is not the descender depth that is the problem; I just found
> > another glyph (/contintegraldisplay) that has matching metrics, and it
> > displays just fine.  As do other glyphs with deeper descenders.
> > 
> > Still looking at the font...
> > 
> > On Sun, 8 Oct 2000, Tom Kacvinsky wrote:
> > 
> > > Unlike the other fonts from the Computer Modern family, CMEX10 has
> > > many glyphs with *deep* descenders.  These glyphs are completely
> > > below the baseline and are in excess of 1500 Type 1 units (1000 Type 1
> > > units per em) deep.  I suspect that this is the cause of the problem.
> > > I am looking into it right now; ftview fails to display glyph number
> > > 90 (/integraldisplay).
> > > 
> > > Tom
> > > 
> > > On Sun, 8 Oct 2000 address@hidden wrote:
> > > 
> > > > hi! right now i have a pretty functional dvi viewer written for ggi
> > > > and using freetype for fonts. sometimes, however, weird things happen,
> > > > and i hope someone can help me.
> > > > 
> > > > as an example, if i'm viewing a file that uses cmex10, for example:
> > > > when the dvi files uses glyph number 90, freetype signals an error.
> > > > here's what happens: the code below, executed with ch=90, and
> > > > curr_font->face being from cmex10.pfb, scaled correctly
> > > > 
> > > > -----------------
> > > > if(FT_Load_Glyph(curr_font->face,ch,FT_LOAD_NO_HINTING) ||
> > > >    FT_Get_Glyph(curr_font->face->glyph,curr_font->glyphs+ch))
> > > > {
> > > >   fprintf(stderr,"Could not load glyph %d from font 
> > > > %d.\n",ch,curr_font->number);
> > > >   terminate(1);
> > > > }
> > > > -----------------
> > > > 
> > > > terminates my program (could not load glyph 90 from font 18). i would
> > > > like to release my viewer for the public, but while these types of
> > > > errors keep popping up i can't... (btw, that never happens with cmr10
> > > > and the likes. it also works fine with other glyphs from cmex10) since
> > > > i'm no font expert, i hope some of you guys can pinpoint where the
> > > > error is occurring (in freetype, in cmex10, encoding, my code...).
> > > > 
> > > > thanks!
> > > > 
> > > > --
> > > > 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
> > > > 
> > > 
> > 
>