Posted by popepiusx2 on September 21, 2009 at 1:55pm
| Project: | Signwriter |
| Version: | 6.x-2.0-beta2 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
I'm using the font Anivers Regular and whenever Signwriter creates an image, it slices off the descenders of the letters (the bottom parts of g, p, q, j, y). Will there be a value in the next release that is the same as the CSS property "line-height" so that the descenders can be kept? At the moment the problem can be solved by setting a drop shadow to the same colour as the page background then increasing the y-offset of the shadow but this is only a workaround. For more info see http://en.wikipedia.org/wiki/Descender).
Comments
#1
I worked around this issue with a combination of specifying the height of the image and the offset until it matched my expectations, there was no need to set drop-shadow. Not that convenient, but it works. Wether you have to tweak depends on the font you are using and also on the text size. I'm not sure wether reading a font family's line-height property is done by the library or not.
ed. Actually, to be more specific, here's an example:
font size: 24px
height: 40px
y-offset: -8px
#2
sub
#3
I too am seeing this new behavior. Not seen before. Wondering what's causing it? Is there anywhere to add room to the bottom of the image in code?
#4
Hello again!
I wonder wether there has been a patch or otherwise solution for this which doesn't need setting height/y values. Setting those values renders the multiline feature useless. I read on some forums that this might have something to do with the versions of FreeType used on the servers. I suggest adding a version check and maybe adding a default +7px to the bottom of the image for the affected versions, if it really is a problem of specific versions of the used libraries. I recently played around with 6.x 2.x-dev but the problem's still there and prohibits me from fully using it's great potential.
Versions of libraries on my shared hosting: GD 2.0.34 / FreeType 2.2.1
Also, I propose to handle this as a critical bug, instead of a feature request, because it clearly isn't a feature to have descenders, more like a very annoying bug to *not* have them. :-) Even more so because having to use a workaround à la height/y-offset values renders actual features useless, like the multiline-rendering of text, which makes the module actually really interesting in the first place.
Let me know if there's a way I could help to resolve this particular problem by donating a small amount, since this is really important for me (and a lot of other users I think) and I'd rather not switch to JS/Flash text/image replacement methods for the time being.
Thanks in advance and have a nice jumping over to 2010 :-)
Ed. Maybe it would be already enough to handle the height of images like the module currently handles the width, by using a "soft" minimum value for the height of an image in case there's only one line of text to be rendered. Setting the height value currently (at least I imagine that's the problem in case of multiline-text here) crops the image.
Here's how the problem could be handled using ImageMagick instead of GD/FreeType: http://www.imagemagick.org/Usage/text/#font_info
#5
I have the same problem, the multiline texts are cut off at the bottom. I was able to "fix" this the dirty manner so this is only to work around till the good guys have fixed the error ;)
In one of the last updates, this code was added:
// calculate the maximum possible height of the text to properly vertically align multiple images$biggest_box = imagettfbbox($image->fontsize[0], $angle, $image->fontfile[0], "ÅßåŮůÃÕÑÁÉÍÓÚÄËÏÖÜÀÈÌÒÙÂÊÎÔÛÇçabcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789");
foreach (array(1, 3, 5, 7) as $i) {
$box[$i] = $biggest_box[$i] +7;
}
I changed only the last part => "+7" and it works so I guess the calculation done in this code isn't OK for multiline text height.
btw. The font I'm using is SyntaxLTStd.ttf
Hope this helps.
Jan
#6
You could also try my dirty hack. I've also noticed that generated text depends on OS. On WAMP (Widnows) there is no problem with cutting but on LAMP every text is cutted and generally looks worse.
#7
I'm having the same issue and can't seem to find why. I have 2 environments. One renders fonts correctly (vertically centered in the img); the other renders them too low and cuts off the bottom. Maybe this belongs in text get cropped in the image. The code is the same in both environments so I assume it's some other problem (php version, gd library, etc). *shrugs* All the previews at admin/settings/signwriter are also incorrectly rendered and admins see a different theme so it shouldn't be a matter of line-height or any CSS.
Signwriter version is 6.x-2.0-beta2 for both environments.
The attached screenshot shows the first environment on top and the second environment on bottom.
Some status report differences:
Environment 1:
- MySQL database: 5.0.91
- PHP: 5.2.13
- Web Server: Apache/2.2.15 (Unix) mod_ssl/2.2.15 OpenSSL/0.9.8e-fips-rhel5 mod_bwlimited/1.4
- GD Library: bundled (2.0.34 compatible)
Environment 2:
- MySQL database: 5.1.50
- PHP 5.2.10
- Web Server: Apache/2.2.3 (CentOS)
- GD Library: bundled (2.0.34 compatible)
**UPDATE** PHP version bug: http://bugs.php.net/48732