Next message: Peter Wood: "Re: Scaling fonts not working as expected"
On Wed, Mar 20, 2013 at 01:51:04PM +0000, Peter Wood wrote:
> Thanks for your reply.
> I had previously tried doing this by changing the font size, but the
> results I got were odd. Here's an example:
> * Using font BodoniXT.TTF, initial size 70, image width 615px. Test string
> WWWWWWWWWWWWWWWWWWWW (20 'W's) display_width was initially 1298px. Got
> scaling ratio of 0.473805855161787, resulting in new font size of
> 33.1664098613251. Applied this new size and got display_width of 619px.
> Exceeded the boundaries of the image by just 4px.
> * Same font, size, image width, but new, shorter test string. Test string
> was same as above less one 'W'. display_width was initially 1233px. Got
> scaling ratio of 0.498783454987835, resulting in new font size of
> 34.9148418491484. Applied this new size and got display_width of 644px,
> exceeding the image width by 29px.
> * The first test string that actually fit inside the image width was 15
> 'W's. This had an initial width of 973px, which resulted in a scaling
> ratio of 0.632065775950668 and a new font size of 44.2446043165468. With
> the new size, this rendered at a width of 613px, just 2px inside the
> Other fonts had different points where the final size would fit or not fit
> inside the boundaries.
> One of my colleagues suggested that this was due to font hinting, which
> could change at different font sizes and result in different string
> widths. We felt that trying to scale the font rather than change its size
> might give better results, in particular because this was supposed to
> disable font hinting.
You can also disable font hinting manually, which may get you closer
to an exact width, but whatever you do, you're not going to reliably
get an exact pixel width for a multicharacter string.
For both transformed and untransformed output, Imager works character
by character, maintaining the draw location for the next character
only as an integer. I suppose this could be changed for transformed
output to apply an extra transformation for the current advance
position, but that's a fair amount of work for a feature I'm not sure
is used much.
Also reducing precision, the transformation matrix and the specified
font sizes are handled by FT2 as 6-bit fixed precision numbers - not
as floating point.
I suspect the simplest solution is to find a width that fits within
the image (round down a little) and then render character by
character, adjusting the output position incrementally to fill the