Page 1 of 1
Glyph width problem, overlaying fonts
Posted: 2013-07-08T05:11:24-07:00
by 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?
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-08T06:39:36-07:00
by 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.
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-10T02:31:10-07:00
by 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.
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-10T06:50:18-07:00
by 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.
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-10T07:11:30-07:00
by 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.
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-10T08:56:22-07:00
by 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.)
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-10T16:35:20-07:00
by 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.
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-10T17:15:38-07:00
by 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.
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-10T17:23:26-07:00
by 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.
Re: Glyph width problem, overlaying fonts
Posted: 2013-07-25T18:52:59-07:00
by 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.