Suggestion: Maximum pointsize for captions

[wallerdev]

I think it would be a useful feature if when using imagemagick to generate text on an image, you could specify a maximum pointsize of the font. This way if you have a large image and some of your text is very short, it doesn't come up as gigantic text, and you can still use the caption feature to get a best fit in an image. This would be helpful when you are generating a lot of images from text where the text can either be very short or longer.

For reference, this is the command I'm using now:

Code: Select all

convert -background "#7250AF" -gravity center -interline-spacing 10 -fill white -size 1280x720 -border 20x20 -bordercolor "#7250AF" caption:"abc" output.png

[snibgo]

I overcome this issue by artificially lengthening the text with spaces at the start and end.

Personally, I hate pointsizes -- a meaningless concept for abstract images, videos etc.

[wallerdev]

Thanks for the tip, that's a great idea on how to tackle the problem!

[Markster]

I fully support this idea of adding an option of specifying the MAXIMUM and MINIMUM font size to use!

I have a program that creates movie sheet information and I have no idea how many characters, like a movie plot, might be.
If the plot is really small, I get a very ugly LARGE font size. Padding it with blanks does not help as it is a guessing game as to how many to add, plus the box changes depending on the sheet style used, as does the font in use, which means different fonts have different widths. In addition, different languages imply different widths even for small plot.

So, the best method here is to allow an option to tell ImageMagick to not choose any font larger than XX to start with, which ensures that small plots show at a font size that is what users would like, without the need for padding of blanks. I assume this would also speed up the internal logic as it won't try font sizes that are clearly not going to work (too large).

In addition, having a limit to how small the font size can go is also a user request as squishing something down that it can't be read makes no sense, so adding an option to restrict would at least allow the plot to be readable, even if it gets truncated. This again would speed up internal logic as ImageMagick could quit when it reaches the minimum font size and just use it vs. trying to continue to find smaller fonts until one finally works (which is unreadable in the end).

Lastly, being able to retrieve an error status from the command when the minimum font size was selected would also be good to know, or better yet if the minimum font size resulted in text being truncated because it fell outside the dimensions, as then users could be notified that some of the fields produced need to be reviewed.

It's near to Christmas time, so this is my Santa wish list.

[fmw42]

The developers of ImageMagick have nothing to do with IMagick. If you need a limit in Imagemagick and if they implement it, you then need to get the Imagick developers to implement it also.

[Markster]

The developers of ImageMagick have nothing to do with IMagick. If you need a limit in Imagemagick and if they implement it, you then need to get the Imagick developers to implement it also.

I wasn't aware there was a difference. I use the command line interface provided by ImageMagick. I'll edit my post.

[fmw42]

For Imagick, see viewforum.php?f=18

[fmw42]

You can always specify a pointsize and just the Width or just the Height when using label: or caption:. It will then use that pointsize and adjust the height or width, respectively. Does that help?

[Markster]

You can always specify a pointsize and just the Width or just the Height when using label: or caption:. It will then use that pointsize and adjust the height or width, respectively. Does that help?

Unfortunately no, as the data needs to fit within a specified location on the sheet, as does other data.

So I read the dimensions from the sheet layout XML which gives me the X and Y coordinates, along with the WIDTH and HEIGHT of the box. Then I need to fit the string of characters into that box.

I know that I don't want the font-size to be any bigger than MAXFONT, and any less than MINFONT. Believe me when I say I have spent days writing elaborate font metric calculations to try and determine the number of characters per line, and height for number of lines. I even tried to adjust for word wrapping, but because of the variations in character size, which gets more complicated with different languages, it just doesn't work well. I assume you guys know this otherwise you would have done it yourself (smile).

[fmw42]

Seems to me that using caption: with the exact width and height and no pointsize specified should work to fill your box. Can you show an example where it does not? Are you worried about having only one word, for example, and a large box, so that you get huge text. However, if you have lots of text and a small box, any attempt to limit the lower bound would write text too big for your box.

[Markster]

Seems to me that using caption: with the exact width and height and no pointsize specified should work to fill your box. Can you show an example where it does not? Are you worried about having only one word, for example, and a large box, so that you get huge text. However, if you have lots of text and a small box, any attempt to limit the lower bound would write text too big for your box.

I think I stated this all in my first post above, but apologies if it was not clear.

The issue is not that the box is not filled properly based on the rules of the CAPTION property when no pointsize is provided. It is working properly.

The issue is that for small strings the font size used is way too big and distracts from the other fields on the screen. When there is a lot of characters in the string, the font is way too small and not readable even on a 52" TV. I said that allowing for a MAXIMUM font size prevents the FONT being too big for small strings, and having a MINIMUM FONT prevents the font size chosen being unreadable, thus pointless. Yes, restricting to a MINIMUM FONT could result in text being cut-off, which my users (and myself) would prefer as at least most of the plot is readable vs. none of it being readable. I also stated that providing an error status that could be checked in situations in which the MINIMUM FONT result in truncation would be great, but not required.

I also speculated that internally this might speed up a lot of trial\miss and thus time to generate as you don't have to waste your time on larger fonts than MAXIMUM, or smaller fonts than MINIMUM.

[snibgo]

When IM chooses a value for pointsize, we can't find what value has been chosen. If we could find out (eg "%[pointsize]") then we could do a caption then, if the chosen pointsize was too large or too small, redo the caption with explicit pointsize.

This would also be an easy new feature. So I propose that it is added.

("-minpointsize n" and "-maxpointsize n" would also be good, of course.)

[fmw42]

One possible solution to snibgo's suggestion would either to have it be part of the information returned when adding -verbose to the caption: command line or to have a new string format [caption:pointsize].

With regard to the former request, that might be implemented by a -define caption:max-pointsize and a -define caption:min-pointsize or some combined way.

I don't think it would make things quicker. IM would have to find its optimal solution and test against the min and max values an override them with on or the other, if too large or too small.

If implemented, it should be done for each of caption:, label: and pango:

[fmw42]

Actually you can get the pointsize by adding -debug annotate, but you have to find the last instance of each iteration IM tries.

For example:


convert -debug annotate -size 200x100 xc:white -fill black -verbose caption:"this is a test" null:

Code: Select all

2013-11-26T16:59:27-08:00 0:00.040 0.040u 6.8.7 Annotate convert[205]: annotate.c/RenderFreetype/1222/Annotate
  Font /Library/Fonts/Arial.ttf; font-encoding none; text-encoding none; pointsize 12
...
2013-11-26T16:59:27-08:00 0:00.280 0.260u 6.8.7 Annotate convert[205]: annotate.c/RenderFreetype/1222/Annotate
  Font /Library/Fonts/Arial.ttf; font-encoding none; text-encoding none; pointsize 44.25

[snibgo]

Ah, yes, I'd forgotten about "-debug annotate". Thanks. This provides a workaround for the original problem.