Posted by danielb on February 14, 2008 at 3:04am
Jump to:
| Project: | Textimage |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | minor |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I notice that textimage's with certain letters that are taller than other letters (such as j, g, y) cause a difference in the height of the image.
Perhaps we could make a new field for 'line-height' where we could set a target height for the dimension of the image?
Comments
#1
Note: actually I guess if the text wraps to two lines, the image would be twice the target line height. Just to make that point clear.
#2
I've been working on this and thing I've come up with a solution (although this is my very first attempt at fixing anything at drupal.org, so please forgive any newbiness). The root of this issue is due to due to the inconsistent behavior of php's imagettfbbox() function, which you can read loads about at: http://us.php.net/imagettfbbox
The problem boils down to two issues:
My solution involves a few patches to textimage_text_to_image() in textimage.module (I'm working with 6.x-2.x-dev):
// Get dimensions of a generic, one-line string using all chars, just in case something has a crazy height.$bboxblank = imagettfbbox($fontsize, 0, $font, "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890");
if($bbox[1] < $fontsize) { // If the text is one line, use our generic box.$height = $bboxblank[3] - $bboxblank[5];
}
else {
$height = $bbox[1] - $bbox[7]; // Else, do it the original way.
}
// If no angle and not wrapped, then calculate the baseline from our generic box.if($angle == 0 && $height < $fontsize*2) {
$ty = -$bboxblank[7] - ((-$bboxblank[7] + $bboxblank[3]) / 2);
}
else {
$ty = -$bbox[7] - ((-$bbox[7] + $bbox[3]) / 2); // Else, use the original method.
}
I believe these should clear up most of the issues with 0-angle text. I coded them specifically not to mess with any text that's not flat, and also so that they don't break wrapped text. If people could take a look at these and give me some feedback, I'd appreciate it.
#3
I agree that something needs to be done with this issue as it has popped up as an issue for myself.
The quick fix is to simply set 'vertical-align: top;' in the css for the items you want to line up correctly, however I understand that that should not be required.
As for froboy's fix, it did technically work, but as I have made a large amount of changes to that particular section in the latest dev builds it will need to be re-worked. I will have a look at implementing it when I get the time.
@froboy
I appreciate you giving this a go, it's always fantastic to see someone taking the step to become a contributor, but I would suggest you take a few minutes to have a look at http://drupal.org/patch to get an idea on how patches should be rolled.
If you have any questions, use the contact form on my user page and I will do whatever I can to help you out.
#4
A fix for this should be committed within the next few days.
#5
Fixed and committed to HEAD, DRUPAL-6--2 and DRUPAL-5--2.
Cheers,
Deciphered.
#6
You're the man now dog.
#7
:)
Take note, if you're a pixel perfectionist like myself, you may need to make some modifications to your existing presets. The increased heights may break some designs, but it's easy enough to remedy with negative margins.
Also, check out the integration with Vertical Tabs.... much nicer UI.
Dev release should be built in an hour or so.
Cheers,
Deciphered.
#8
Automatically closed -- issue fixed for 2 weeks with no activity.
#9
This bug came back with the latest 6.x-2.x-dev. I have two images, one with "test" and one with "gtest" and the height of the two is different because of the "g". Do I open a new bug or can I reopen this one?
#10
// $yoffset = ($firstline_coords[1] - $firstline_coords[5] >= $fontsize) ? $baseline_coords[1] + 1 - ($fontsize * 0.3) : 0;$yoffset = ($firstline_coords[1] - $firstline_coords[5] >= $fontsize) ? $baseline_coords[1] + 1 - ($fontsize * 1.0) : 0;
#11
Dimm... can I just point out that
$fontsize * 1.0equals$fontsize... and that multiplying anything by 1 is pointless...Secondly can I point out that this issue is closed, and that it's generally not good practice to comment in a close issue, either re-open the issue, or open a new issue.
#12
#13