Gabe Schaffer write...
| If you put glyphs (letters) on fractional pixel boundaries, they can
| get hard to read. For example, consider a letter 'i' or lowercase 'L',
| which may only be a single pixel in width. When your text rendering
| engine decides to draw that letter at a half-pixel boundary, it can
| either draw a black vertical line 2 pixels wide or draw a vertical
| 2-pixel line in 50% grey. Both options look ugly if you're actually
| trying to read a large block of text.
|
| The way to solve the problem is to draw the 1-pixel line as an actual
| 1-pixel black line. This means that each particular glyph may be off
| by one pixel for each vertical line, although the truth is much more
| complicated than that.
|
| In other words, if your only goal is to draw legible text (and don't
| care about exact text metrics), the characters aren't guaranteed to
| line up. If your goal is exact text metrics (so line breaks always
| stay in the same place), you have to give up a bit of legibility.
Scott Nebor wrote...
| Normally I would expect some distortion at different font sizes. However,
| the way that imagemagick renders some lines of text can be dramatically
| different depending on the font size
Glenn Linderman wrote...
| Indeed, that talks a lot about rendering individual glyphs, but it
| doesn't talk much at all about the inter-glyph spacing (kerning) at
| various sizes, which probably has as much or more impact on the overall
| horizontal space consumption as the individual glyph rendering does.
|
| Modern printers typically have more dpi than most images, which would
| reduce the visible effects of aligning things on pixel boundaries. This
| might have an impact on your testing... what dpi are the images you are
| testing with? If you use images with 10 times the dpi, does the effect
| remain, or is it reduced, or visually eliminated?
|
Now for my own 2 cents and some quick tests from the IM command line.
Using the latest IM beta test, built under Linux with Q16.
I chose to use "Arial Bold" at default pointsize, and the '+' character to see
what is happening, using the -annotate operator. The "x:" output is for
display to the screen, change it to a image file if you can't use this.
I am not sure if this operator only accepts integers or floats,
but that should not effect inter-glyph spacing tests.
Position tests.
convert -size 15x15 xc:lightblue -font ArialB \
-annotate +2+11 '+' -scale 1000% x:
convert -size 15x15 xc:lightblue -font ArialB \
-annotate +2.5+11.5 '+' -scale 1000% x:
No change so position is rounded to neared interger by something.
Eg: IM operator parsing, font drawing function, or freetype library.
Inter-glyph spacing tests
convert -size 25x15 xc:lightblue -font ArialB \
-annotate +2+11 '+' -scale 1000% x:
convert -size 25x15 xc:lightblue -font ArialB \
-annotate +2+11 '++' -scale 1000% x:
convert -size 25x15 xc:lightblue -font ArialB \
-annotate +2+11 ' +' -scale 1000% x:
convert -size 25x15 xc:lightblue -font ArialB \
-annotate +2+11 'm+' -scale 1000% x:
All the plus glyphs look the same so each character is aligned to a whole pixel
Increasing the point size by .5 should pointsize is a float, and that the
seperation between 'm' and '+' jumps to ensure characters are whole pixel
aligned.
convert -size 25x15 xc:lightblue -font ArialB -pointsize 12.5 \
-annotate +2+11 'm+' -scale 1000% x:
In Summary...
At this time IM command line (or posibily the "freetype delegate library")
seems to always use a whole number, to align individual characters to whole
pixel boundarys, so this should not be a problem.
Anthony Thyssen ( System Programmer ) <[EMAIL PROTECTED]>
-----------------------------------------------------------------------------
Backup is irrelevant, your C drive will be assimilated
-----------------------------------------------------------------------------
Anthony's Home is his Castle http://www.cit.gu.edu.au/~anthony/
_______________________________________________
Magick-users mailing list
[email protected]
http://studio.imagemagick.org/mailman/listinfo/magick-users
