Re: [ft] FT_Glyph_Get_CBox inaccuracy

[Michiel Kamermans]

Hi Werner (et al),

> Uuh, you haven't looked up the email I've cited, have you?
>
>    http://lists.gnu.org/archive/html/freetype/2010-02/msg00065.html
>
>    
> > You don't have to actually render a glyph (in the sense that it
> > is rasterised to a pixel map) to analyse the vector coordinates.
> >
> > Just run through the 'glyf' table at the correct index, and resolve
> > the coordinate list.
> >      
> Well, you haven't understood the problem, I believe: If you ask for a
> bounding box which returns font units, you get *exact* values.
> However, if you ask for a bounding box at a given DPI value, returning
> pixels, you can't get an exact answer without rendering the glyph, as
> the image in the above cited email clearly shows.
>    

I did (on both accounts), and perhaps the phrasing of my mail was 
misleading. I did not mean to suggest that what I suggest solves the 
problem -because of course raster coordinates are not glyph box 
coordinates- but I did mean for this function suggestion to be considered.

Basically, it'd be nice to have a function that returns the 
pre-rasterised coordinates, so that a programmer has more accurate 
numbers to work with. Knowing the desired font point size and dots per 
inch will then allow a programmer (if they so choose) to do any custom 
arithemetic to determine the "true" bounding box in whatever raster the 
text will end up in.

Esssentially, getting the bounding box in pixel units with the implicit 
promise that things will go wrong without a way to obtain the 
pre-rounding data seems like something that can easily be resolved, and 
would give programmers more power in dealing with situations in which 
rounding introduces an off-by-one-pixel value. As a new function it 
won't alter the functioning of any existing code, but would offer a 
finer-grain control to the programmer.

So again, see this as a recommendation in relation to a problem that is 
highly related to, but not quite the same as, the original poster's 
problem. If you have access to values before and after they get rounded 
lets you perform corrections (and tricks) that are impossible if you 
only have access to rounded-with-possible-error values.

Regards,

- Mike