Glyph width problem, overlaying fonts

[djlspeed]

I try to overlay two versions of the same text using different fonts (to create text effects like outlines and multi-color letters).
The fonts are defined with identical glyph widths, if I use Photoshop (or any text processing software) to generate the two texts and overlay them, they fit perfectly.
But ImageMagick doesn't seem to care about glyph widths but uses its own positioning system. So the two layers don't fit even if it's only a one-letter-text to be displayed.
What font definitions are used by ImageMagick?

Here my command for displaying a "4":

Code: Select all

convert -size 500x500 xc:transparent -antialias -stroke none -pointsize 140 -gravity southwest -fill "#00ff00" -font FontBack.ttf -annotate 0x0+0+0 "4" -fill "#ff0000" -font FontOverlay.ttf -annotate 0x0+0+0 "4" -trim -virtual-pixel Background temp.png

To position the layers with the annotate options won't be a solution, as texts are generated dynamically in an imageprocessor.

Any ideas?

[snibgo]

IM uses dimension information from the font. Your command works for me, IM v6.8.6-0, using the same font twice.

What version IM do you use, on what platform?

It would help if you can supply the resulting image and, preferably, the ttf files.

[djlspeed]

Thanks for your help, I really appreciate that.

Command:

Code: Select all

convert -size 5000x500 xc:transparent -antialias -stroke none -pointsize 60 -gravity southwest -fill "#00ff00" -font FontBack.ttf -annotate 0x0+0+0 "123456789012345678901234567890123456789012345678901234567890" -fill "#ff0000" -font FontOverlay.ttf -annotate 0x0+0+0 "123456789012345678901234567890123456789012345678901234567890" -trim -virtual-pixel Background temp.png

Image:


As you can see, it's fine in the beginning, but the further right the text moves the more the back font is running away from the overlay.

I tried it on Windows 7 with IM 6.8.6-3 as well as on Ubuntu 12.04.2 LTS with IM 6.6.9-7 and got exactly the same result. (So at least IM works reliably.)

Here you can download the fonts:
http://www.vielzulangedomain.de/test/im ... ntBack.ttf
http://www.vielzulangedomain.de/test/im ... verlay.ttf
Please notice that the overlay only provides extra characters for numbers, so you should stick to numbers while testing.

Thanks a lot.

[snibgo]

I see what you mean; there is a problem in IM which doesn't seem to be present in OpenOffice, for example.

I don't know much about fonts, and don't have the tools to analyse the differences between the font files. An IM developer would need to look into this. Perhaps IM is rounding a number when it shouldn't.

Meanwhile, I note that setting pointsize to 50 results in the strings lining up, at least visually. As a workaround, perhaps you could use this (or other pointsize that works), then resize.

[djlspeed]

Thanks again.

My first workaround actually was to use a really big pointsize and scale the rendered result down.
The bigger the font size is the less important is the IM specific spacing. So your guess that it's caused by some rounding might be not too bad.

Because of performance problems (everything got really slow when images grew too big) I had to change that, and, right now, my imageprocessor renders each letter on its won and puts everything together afterwards.
This works but it's not really what I would call elegant.

Another hint:
Just rendering one single letter (with two different fonts) but centering it, instead of aligning it to the left (using south gravity instead of southwest) already leads to bad positioned letters. So whatever causes the back font to run away from its overlay also is used for calculating the centered position.

[snibgo]

The pointsizes that work become sparser as the pointsizes increase. Windows script:

Code: Select all

for /L %%i in (20,1,200) do ^
%IM%convert ^
  -size 5000x500 xc:gray -antialias -stroke none ^
  -pointsize %%i -gravity southwest ^
  -fill "#00ff00" -font FontBack.ttf ^
  -annotate 0x0+0+0 "123456789012345678901234567890123456789012345678901234567890" ^
  -fill "#ff0000" -font FontOverlay.ttf ^
  -annotate 0x0+0+0 "123456789012345678901234567890123456789012345678901234567890" ^
  -trim ^
  font_shift_%%i.png

Pointsizes that work: 22, 24, 25, 29, 30, 32, 34, 35, 37-39, 42, 43, 45, 47, 50, 51, 55, 57, 62, 64, 67, 70, 92, 97, 105, 117, 130, 155, 163, 175, 188.

(Your final "-virtual-pixel Background" should do nothing. I have changed the background colour to "gray" merely so that viewers show the image boundary.)

[djlspeed]

Hm...
Interesting. Is there a pattern, a secret code, something Imagemagick wants to tell us with these working pointsizes?
I still stuck to your rounding problem suggestion.
Guess you already recognized: I posted this issue in the developers' list. There should be somebody out there having coded all this and maybe she/he/it had some kind of a plan.
We will see...

But thank you very much for now. It's nice knowing there are helpful enthusiasts like you.
I keep you informed.

[fmw42]

What happens if you use -gravity center and be sure the size is larger than needed so that -trim +repage will cut out the excess afterwards?

You might still get misalignment but should not get cutoff text.

[snibgo]

If the developers list can't help, you might put it in the bugs forum (viewforum.php?f=3), linking back here.

However, IM may use some standard library software to do the work, and it may need someone with knowledge of those internals.

[anthony]

The problem is gravity needs information about the overall final size of the font for positioning.

Avoid that and position it with -gravity none. The fonts should (if designed that way) then line up perfectly as you are starting the 'caret' point at exactly the same place, rather than letting IM calculate that position independently.


However if the fonts are simply different in that one is an outline of the other. well you can just use one font and different colors for fill and stroke.