[Top][All Lists]

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

Re: [ft] FT_Glyph_Get_CBox inaccuracy

From: Michiel Kamermans
Subject: Re: [ft] FT_Glyph_Get_CBox inaccuracy
Date: Fri, 26 Feb 2010 11:29:38 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv: Gecko/20091204 Thunderbird/3.0

Hi Werner (et al),

Uuh, you haven't looked up the email I've cited, have you?

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.


- Mike

reply via email to

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