[RESOLVED] Text rendering: label overflows

[qubodup]

Hello,

I render text using label to a pre-defined area, not knowing up front, how long the text is. Unfortunately, if the string is long enough, it will overflow, rather than scaling to fit the given area.

Code: Select all

convert -size 1656x250 -background white -fill black -font URW-Gothic-L-Demi -gravity Center -extent 1676x260 label:"what what what what what what what what" test.png

Result: http://i.imgur.com/ySikHpJ.png

Arch Linux 64bit, imagemagick 6.8.2.3-1

It seems like a bug to me. If in fact my expectation is incorrect, please let me know what I'm missing.

Cheers & Thanks

PS: Perhaps this has something to do with the font size being low enough to fit into two lines with long texts?

[snibgo]

I don't get that problem with v6.7.9-6, 6.8.2-0 or 6.8.3-0 on Windows 7. For me, the font size changes correctly. Does the problem occur with all fonts?

I'm curious about "-extent 1676x260". Why is this larger than the imgage size? What do you hope it does?

[qubodup]

Thank you for answering!

Does the problem occur with all fonts?

The default font (not sure which it is, not sure how to check. Also I believe that on many Linux distros many popular font names are aliases for other fonts) has the same problem. I used the command

Code: Select all

convert -size 1656x250 -background white -fill black -gravity Center -extent 1676x260 label:"what what what what what what what what" test.png

http://i.imgur.com/IAOxqIZ.png

Of course this could also mean that the issue is specific to both my default font and URW-Gothic-L-Demi.

I'm curious about "-extent 1676x260". Why is this larger than the imgage size? What do you hope it does?

Removing the -extent parameters doesn't change the overflow issue. If I remember correctly, I hoped to "pad" the image using this parameter, so that there is a white "border" around the white-bg image.

Cheers

PS: about -extent http://www.imagemagick.org/Usage/crop/#extent

[fmw42]

With label: you should not specify both the width and height. Just use one or the other.

However, there is a current bug in label: when you do that, which is being fixed .

see
viewtopic.php?f=3&t=22946

[qubodup]

Thanks for your reply!

The issue persists in 6.8.5.3 on Arch Linux.

With label: you should not specify both the width and height. Just use one or the other.

label: is not supposed to fit the box, when both width and height are given? Or is just not working as intended?

[fmw42]

Thanks for your reply!

The issue persists in 6.8.5.3 on Arch Linux.

With label: you should not specify both the width and height. Just use one or the other.

label: is not supposed to fit the box, when both width and height are given? Or is just not working as intended?

Label will only fit if one or the other of the box sizes are specified and no pointsize is specified. Label: is for everything on one line. If you want to fill a box and specify the width and height and no pointsize, then use caption:

see
http://www.imagemagick.org/Usage/text/

[anthony]

First.... remove your irrelevent '-extent' option in the bug report.

Second when you do add it, add it AFTER you created the the image with label. not before.

arguments to convert/magick are not 'option's but settings and operations (more script like) and processed in order, the only reason you do not get an error in IMv6 is due to legacy argument handling. In IMv7 the "magick" would give you an error (no image) for -extent, as you have no image at that point.

Code: Select all

magick -size 1656x250 -background white -fill black -gravity Center -extent 1676x260 label:"what what what what what what what what" show:
magick: no images found for operation `-extent' at CLI arg 9 @ error/operation.c/CLIOption/4939.

Okay .. enough rant...

Just this screws up, with the generated label longer that it should be... This is a BAD start

Code: Select all

convert label:"what what what what what what what what"  show:

This gets clipped also bad

Code: Select all

convert -size 1656x250 label:"what what what what what what what what"  show:

BUT this does not! good!

Code: Select all

convert -size 1656x label:"what what what what what what what what"  show:

Looks like the bug is in that label is fitting itself to image height causing it to get clipped width-wise. -- or I think

Looking at the reported pointsize...

Code: Select all

convert -size 1656x label:"what what what what what what what what" -print '%[label:pointsize]\n' null:
86.1484375
convert -size 1656x250 label:"what what what what what what what what" -print '%[label:pointsize]\n' null:
95.2421875
convert -size x250 label:"what what what what what what what what" -print '%[label:pointsize]\n' null:
220.826171875

Yeap IM is definatally picking the wrong font size, but it is not fiting label to height either. (initial theory disproved)

Checking the font bounds for the 'larger' (bad fit) pointsize See Determining Font Metrics

Code: Select all

convert -size 1656x250 -debug annotate label:"what what what what what what what what" null:
...
  Metrics: text: what what what what what what what what; width: 1791; height: 109; ascent: 86; descent: -20; max advance: 190; bounds: 0,-1  67.8594,68.8438; origin: 1790,0; pixels per em: 95,95; underline position: -4.5625; underline thickness: 2.34375
2013-05-10T12:25:53+10:00 0:00.040 0.020u 6.8.5 Annotate convert[10709]: annotate.c/RenderFreetype/1219/Annotate
  Font /home/anthony/lib/fonts/truetype/sets/Arial.ttf; font-encoding none; text-encoding none; pointsize 95.2422

This is clearly NOT fitting the text into the requested width of 1656 (text width at this pointsize is 1791) Though the height (109) does not seem to match up to the requested height either.

Something is very wrong with the binary search to find the correct pointsize. Bug Confirmed.

BUT it may also be wrong in general.

Code: Select all

convert label:"what what what what what what what what" -print '%[label:pointsize]\n' null:
11.1875

default pointsize when no size or pointsize is given should be 12, not 11!

Tracing font selections...

Code: Select all

convert -debug annotate label:"what what what what what what what what" null:
...lots of font size tests...

Why is it doing lots of tests for font size when it should be just 12 point! another bug found


Adding -pointsize 12 to the above works fine, producing a label that perfectly the image size it determined form the font.
Though it still does 3 font metric tests.

[qubodup]

Thank you both for clarifying!

I do not expect word-wrap when using label with -size WxH.

I expect that the label is rendered on one line and fits inside the -size WxH area.

http://www.imagemagick.org/Usage/text/#label uses WxH parameters for -size, so I assumed it's a feature.

Images of what happens in ImageMagick 6.8.5-3 2013-04-27 Q16 on Arch Linux:

Code: Select all

convert -background black -fill white -size 200x20  label:T_T test.png

---

Code: Select all

convert -background black -fill white -size 200x20  label:T____________________________________T testlong.png

Both seem false.

Using only one parameter seems OK on the other hand (with the exception of the white space on the right in the 3rd test):

Code: Select all

convert -background black -fill white -size 200x  label:T_T test.png

----

Code: Select all

convert -background black -fill white -size x20  label:T_T test.png

---

Code: Select all

convert -background black -fill white -size 200x  label:T____________________________________T testlong.png

---

Code: Select all

convert -background black -fill white -size x20  label:T____________________________________T testlong.png

For historical purposes, in case the preview images above get deleted, a screenshot of this post:

[fmw42]

I expect that the label is rendered on one line and fits inside the -size WxH area.

You cannot fit text to both width and height when no pointsize is provided (without distortion). So which dimension do you want? That is why I said you have to specify either Width or Height but not both. If it fits the width, then it may be too big for the height and vice versa.

[magick]

Fred, is label broken then? If so, what is an example that fails-- and shouldn't? We'll get a patch in ImageMagick 6.8.5-6 Beta to fix the problem if its truly a bug. Thanks.

[qubodup]

You cannot fit text to both width and height when no pointsize is provided.

By "fit" I do not mean "fill" but that the left/right (text too long for area) or top/bottom (text too short for area) whitespace is filled with -background color.

300x100 and 100x300 areas should have text in them that "fits", not "fills" the space. The following images have been created in GIMP to illustrate what *should* be:




PS: I am aware that it does not work this way right now. But as far as I understand, it's supposed to, when giving -size WxH parameters.

[fmw42]

These 3 tests work fine for me in IM 6.8.5.5 Q16 Mac OSX Snow Leopard. So perhaps it is a bug in the poster's version of IM. You have fixed numerous bugs over time.

Width only (best fit)
convert -size 500x label:"This is a long test of label" label1.png



Height only (best fit)
convert -size x75 label:"This is a long test of label" label2.png


WxH with pointsize (not best fit)
convert -size 500x500 -pointsize 24 -gravity center label:"This is a long test of label" label3.png

[qubodup]

Width only (best fit)
convert -size 500x label:"This is a long test of label" label1.png

This one has possibly superfluous whitespace on the right.

WxH with pointsize (not best fit)
convert -size 500x500 -pointsize 24 -gravity center label:"This is a long test of label" label3.png

Not having "best fit" is a bug, as far as I can tell. EDIT: I'm wrong, I missed the "pointsize" here. Sorry.

Please test

Code: Select all

convert -size 200x20  label:T_T test.png
convert -size 200x20  label:T____________________________________T testlong.png

[fmw42]

PS: I am aware that it does not work this way right now. But as far as I understand, it's supposed to, when giving -size WxH parameters.

It has to pick one or the other of W or Height to fit. You cannot fit both without one font size and without distorting the text in the other dimension.

In this case it uses the height. If it had used the width, the text would be too big for the height
convert -size 300x100 -gravity center label:"Test" label4.png


In this case it used the width. If it had used the height, the text would be too big for the width.
convert -size 100x300 -gravity center label:"Test: label5.png



So as far as I am aware, label: is working fine and the way it should.

[fmw42]

This one has possibly superfluous whitespace on the right.

That is the best fit to any give pointsize. The way to handle that is to use optionally -gravity center and/or -trim +repage.

The second example uses pointsize and WxH, so there is no intended best fit. If you leave off the pointsize, it will fit one or the other dimension so that one dimension fits and the other will have white space so that it does not overfill the box.

There is no bug. That is just the way it works.