Width of Text Mismatch

[extol]

I am unable to predict the size of a block of text that I generate. In fact, it seems that IM is lying to me about widths.

Let's say I use the annotate debug trick for getting the metrics of a font.

convert xc: -font arial.ttf -pointsize 24 -debug annotate -annotate 0 'MyTestString' null: 2>&1

I get this ...

Metrics: text: 'MyTestString'; width: 147; height: 28; ascent: 22; descent: -6; max advance: 48; bounds: 0,-5 17,17.3438; origin: 148,0; pixels per em:
4,24; underline position: -3.39063; underline thickness: 2.34375

So, we see that my width should be 147 pixels for this string, at this pointsize.

OK, so let's actually create the text, and see if it really is that size...

convert -fill blue -font arial.ttf -pointsize 24 label:"MyTestString" test.gif
convert test.gif info:

I get this ...
test.gif GIF 139x29 139x29+0+0 8-bit PseudoClass 256c 1.79kb

So, I'm expecting a width of 147 pixels, and I get a width of 139 pixels. This effect gets more pronounced, the longer the string that I'm testing.

I'm attempting to create a database so I have width information for each character at various pointsize and density values. My database is not predicting actual string widths, and the above description shows the reason I believe my database is not working.

Can anyone point me to where I'm messing up?

[fmw42]

I am unable to predict the size of a block of text that I generate. In fact, it seems that IM is lying to me about widths.

Let's say I use the annotate debug trick for getting the metrics of a font.

convert xc: -font arial.ttf -pointsize 24 -debug annotate -annotate 0 'MyTestString' null: 2>&1

I get this ...

Metrics: text: 'MyTestString'; width: 147; height: 28; ascent: 22; descent: -6; max advance: 48; bounds: 0,-5 17,17.3438; origin: 148,0; pixels per em:
4,24; underline position: -3.39063; underline thickness: 2.34375

So, we see that my width should be 147 pixels for this string, at this pointsize.

OK, so let's actually create the text, and see if it really is that size...

convert -fill blue -font arial.ttf -pointsize 24 label:"MyTestString" test.gif
convert test.gif info:

I get this ...
test.gif GIF 139x29 139x29+0+0 8-bit PseudoClass 256c 1.79kb

So, I'm expecting a width of 147 pixels, and I get a width of 139 pixels. This effect gets more pronounced, the longer the string that I'm testing.

I'm attempting to create a database so I have width information for each character at various pointsize and density values. My database is not predicting actual string widths, and the above description shows the reason I believe my database is not working.

Can anyone point me to where I'm messing up?

Possibly different padding with annotate and label. Consider the following on my system:

convert xc: -font arial -pointsize 24 -debug annotate -annotate 0 'MyTestString' null: 2>&1

Gives a size of 140x28

convert -fill blue -font arial -pointsize 24 label:"MyTestString" test.gif
convert test.gif info:
test.gif GIF 142x29 142x29+0+0 8-bit PseudoClass 256c 1.89kb

But

convert -fill blue -font arial -pointsize 24 label:"MyTestString" -trim +repage test.gif
convert test.gif info:
test.gif GIF 136x23 136x23+0+0 8-bit PseudoClass 256c 1.86kb


However, I hope to hear from the experts also.

[el_supremo]

You may be having a problem with interpretation of single and double quotes.
In your first result:

Metrics: text: 'MyTestString';

this indicates that the single quotes are part of the string that is being rendered. To check this, instead of using null: as the output file, use test.gif and look at the resulting image.

If it were not including the quotes it would say:

Metrics: text: MyTestString;

For example, in Windows (which does not understand single quotes and therefore includes them in the string):

Code: Select all

convert -fill blue -font arial -pointsize 24 label:MyTestString test.gif
identify test.gif
test.gif GIF 139x29 139x29+0+0 8-bit PseudoClass 256c 1.79kb

But putting single quotes around the string:

Code: Select all

convert -fill blue -font arial -pointsize 24 label:'MyTestString' test.gif
identify test.gif
test.gif GIF 149x29 149x29+0+0 8-bit PseudoClass 256c 1.83kb 

In the second case, looking at the image shows that the single quotes are included as part of the string which is why the second image is 149x29 instead of 139x29.

Pete

[extol]

You may be having a problem with interpretation of single and double quotes.
... <snip> ...
In the second case, looking at the image shows that the single quotes are included as part of the string which is why the second image is 149x29 instead of 139x29.
Pete

Thanks Pete. I was being stupid in my code. I was creating my database perfectly, but when I went to use it, my path variable to my font file was broken, causing me to use the default font.

I then tried to do a "sanity check" at the command line, which seemed to confirm that the problem was IM's, and not mine. You have shown that my "sanity check" was actually insane, and I have found the original problem in my code, and have fixed the path to my font file.

Thanks again guys.

[anthony]

I am unable to predict the size of a block of text that I generate. In fact, it seems that IM is lying to me about widths.

That information from annotate is the raw low level information about the text and its bounds, from the font developers, and is used to fit together
and move the current 'caret' position and check if a 'word' fits on the current line or not (word wrapping).

However 'label' does only uses that as a starting point. It will expand on
the 'drawing bounds' the font has declared, to try and catch the real drawing bounds, of a fonts that do unusual things.

For example get the 'LokiCola' font and compare what a label generates for say a Capital "C" and what the font specified for that same character!

They are VERY different. label correctly captures the whole printed character! The "H" is even worse!

For example of LokiCola label output see...
http://www.imagemagick.org/Usage/text/#bounds


Trimming a label is completely different again!!! A Font can draw anything in the 'box it defined for a character. Space for example has NOTHING drawn so it will trim to the special 1 pixel sixed with negative offset, 'missed image'.

See IM Examples, Crop, Missed Image
http://www.imagemagick.org/Usage/crop/#crop_missed

For example...

Code: Select all

convert -size 100x100 xc: -trim info:

returnes

xc: XC 1x1 100x100-1-1 16-bit DirectClass

and the warning (which can be turned off)

convert: geometry does not contain image `' @ statistic.c/GetImageBoundingBox/217.