(none) imager-devel
/ help / lists / applications / search /

Re: Scaling fonts not working as expected

From: Tony Cook (
Date: Wed 20 Mar 2013 - 23:22:24 GMT

  • Next message: Peter Wood: "Re: Scaling fonts not working as expected"

    On Wed, Mar 20, 2013 at 01:51:04PM +0000, Peter Wood wrote:
    > Tony,
    > 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
    > boundaries.
    > 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
    image width.