possible bug -annotate IM 6.8.5.10 Q16

[fmw42]

It seems to me that I should be able to closely replicate creating a text image from the use of -annotate to match what I have from label:

In the following it does not seem that -annotate is properly respecting the specified (height) size. The resulting image is clipped from a specified height of 165 to 138..

Note the trim is not the reason for the clipped data. I added -trim so that the resulting sizes would be close. The trim can be removed and the image is still clipped.



convert -background none \
-fill skyblue -strokewidth 1 -stroke black -font Arial -pointsize 300 \
-gravity center label:"so" \
-trim +repage 2tmp1.png
identify 2tmp1.png
2tmp1.png PNG 298x165 298x165+0+0 16-bit sRGB 39KB 0.000u 0:00.000


convert -size 298x165 xc:none \
-fill skyblue -strokewidth 1 -stroke black -font Arial -pointsize 300 \
-gravity center -annotate 0x0+0+0 "so" \
-trim +repage 2tmp2.png
identify 2tmp2.png
2tmp2.png PNG 297x138 297x138+0+0 16-bit sRGB 31.7KB 0.000u 0:00.000


convert -size 298x165 xc:none \
-fill skyblue -strokewidth 1 -stroke black -font Arial -pointsize 300 -undercolor pink \
-gravity center -annotate 0x0+0+0 "so" \
-trim +repage 2tmp3.png
identify 2tmp3.png
2tmp3.png PNG 297x138 297x138+0+0 16-bit sRGB 30.5KB 0.000u 0:00.000


Is this a bug or am I misunderstanding ... -annotate?

It is even worse when using -gravity northwest.


convert -size 298x165 xc:none \
-fill skyblue -strokewidth 1 -stroke black -font Arial -pointsize 300 -undercolor pink \
-gravity northwest -annotate 0x0+0+0 "so" \
-trim +repage 5tmp3.png
identify 5tmp3.png
5tmp3.png PNG 285x52 285x52+0+0 16-bit sRGB 12.1KB 0.000u 0:00.000

[fmw42]

Further testing with and without -undercolor, shows that there are two different issues.

1) Without undercolor, the label image is fine, but the annotate image comes out too short and thus the result loses some text at the bottom.

2) With undercolor, the label image is too big, but the annotate image is OK.


Without undercolor:

font="Arial"
convert -background white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -gravity center label:"so" -trim +repage 1test1.png


dim=`convert 1test1.png -format "%wx%h" info:`
echo "$dim"
convert -size $dim xc:white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -gravity center -annotate 0x0+0+0 "so" -trim +repage 1test2.png




With undercolor:

font="Arial"
convert -background white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -undercolor pink -gravity center label:"so" -trim +repage 2test1.png
dim=`convert 2test1.png -format "%wx%h" info:`


echo "$dim"
convert -size $dim xc:white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -undercolor pink -gravity center -annotate 0x0+0+0 "so" -trim +repage 2test2.png

[magick]

We can reproduce the problem you posted and have a patch in ImageMagick 6.8.6-0 Beta available by sometime tomorrow. Thanks.

[fmw42]

We can reproduce the problem you posted and have a patch in ImageMagick 6.8.6-0 Beta available by sometime tomorrow. Thanks.

It would seem that only the undercolor part was fixed in label. The annotate problem still exists in IM 6.8.6.1 with part of the image cut off.


Without undercolor:

font="Arial"
convert -background white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -gravity center label:"so" -trim +repage 1test1.png


dim=`convert 1test1.png -format "%wx%h" info:`
echo "$dim"
convert -size $dim xc:white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -gravity center -annotate 0x0+0+0 "so" -trim +repage 1test2.png




With undercolor:

font="Arial"
convert -background white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -undercolor pink -gravity center label:"so" -trim +repage 2test1.png
dim=`convert 2test1.png -format "%wx%h" info:`


echo "$dim"
convert -size $dim xc:white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -undercolor pink -gravity center -annotate 0x0+0+0 "so" -trim +repage 2test2.png

[anthony]

It looks like trim is over trimming the resulting image for some reason.
What does it look like without the trim.

Seems to me the problem is that the text is not being 'centered' correctly. Though according to the image bounds, perhaps it is. You are triming the image after all.

I would have been suprised that you did get a correct result with what you are doing!

Remember fonts are not the physical drawn text bounds (whcih is what trim is getting), it is the draw area bounding box.
which may not actually match where the text is actually drawn. The undercolor fills the bounding box, whick his why using a undercolor box worked in the original post.

I would say the version before the patch was correct, and not the one after the patch!

[fmw42]

Worse without the trim. It is a problem in -annotate


Label with trim:

font="Arial"
convert -background white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -undercolor pink -gravity center label:"so" -trim +repage 2test1.png
dim=`convert 2test1.png -format "%wx%h" info:`



Annotate with trim:

echo "$dim"
convert -size $dim xc:white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -undercolor pink -gravity center -annotate 0x0+0+0 "so" -trim +repage 2test2.png



Annotate without trim:

echo "$dim"
convert -size $dim xc:white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -undercolor pink -gravity center -annotate 0x0+0+0 "so" 2test3.png



Similar results without the undercolor. Both label and annotate are not properly centering. IM 6.8.6.2 Q16

Here is the label without the trim.

font="Arial"
convert -background white -fill skyblue -strokewidth 1 -stroke black -font "$font" -pointsize 300 -undercolor pink -gravity center label:"so" 2test0.png
dim=`convert 2test1.png -format "%wx%h" info:`


The point is given the trimmed image size from label and the font pointsize, annotate should be able to reproduce the same result fairly closely (given both are gravity centered).

[anthony]

The key to the problem is you are trying to annotate the text in a space that is sized to fit the drawn letters, and not the bounding box of the text (untrimmed size in the first command). The text is centered according to the bounding box and not the draw text. IM has no way of easily determining the actual draw bounds from a font, so can't center on that aspect.

On solution... You have no decenders in the text. that is no 'y' 'p' 'g' etc...
so the bottom of the text should be basically the baseline for the text.
The location for annotation when not centered is the base line, so instead of centering in the second command, set the baseline to the bottom of the screen (using gravity none, us position using baseline).

The point is given the trimmed image size from label and the font pointsize, annotate should be able to reproduce the same result fairly closely (given both are gravity centered).

My point is the trimmed image size is completely different to the bounding bound size that is used for centering!

In short: It is the font that is centered, not the letters that is actually drawn.

If you want a worse case, try this with the text '_' or '.' or even a quote '''.
The trimmed size will be tiny in comparison to the font bounding box used for centering.

[fmw42]

First, I do not understand why the size of the image and pointsize and -gravity center are not enough for annotate. That does not make sense to me. However, I certainly do not understand the code and all the factors it uses.

This is affecting my texteffect script and that is where I first found it. I cannot use arbitrary -geometry along with -gravity none to align it.

My best solution so far has been to annotate with dimensions that are 50% taller than identified from the trimmed label and then trim after annotate.

If this is a feature of the drawing and font glyph parameters, then there is nothing that I can do or anyone else to match annotate to a given area and pointsize. That as I said above seems rather odd. I though -gravity center works with the font so as to properly center it. But there apparently are other factors and this is apparently not as straightforward as I had thought.

[anthony]

You can not match the annotate drawn output (trimmed output) to a given sized area, unless you specifically use a trial and error matching.

But then that is essentially what auto-sizing does, just using the fast font bounding box information, rather than a slower 'draw and trim' output. It will be slower, though you could get some speed up using interpolation from one result to the desired result.

One point... if you do this with a sting of '.' you will get a giant circle rather that what people would think of as a period.

I encountered similar problems a very long time ago when I was trying to display trimmed 'font glyphs' in a chart so I could see what the font looked like. Removing the bounding box may my period characters look more like a centered dot.

Fonts are more than just what is drawn, they are also the spacing around the drawn glyph, which is by bounding boxes are used.

PS: Remember font glyphs may also overflow the font bounding boxes. Especially in 'script'-like fonts. The LokiCola font is my standard example of this.

[fmw42]

OK. Thanks for the clarification.