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

Version:5.x-2.0-beta1» 6.x-2.x-dev
Status:active» needs review

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:

  1. The height of the image depends on the presence of ascenders or descenders in the text - so for example "acorn", "Box", and "Any" would all have different heights.
  2. The baseline of the text works out to be the lowest point of any letter there, so if you had an image of "acorn" and an image of "any" next to each other, they would look misaligned.
  3. My solution involves a few patches to textimage_text_to_image() in textimage.module (I'm working with 6.x-2.x-dev):

    1. After $bbox=... around like 658 I've added:
        // 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");
    2. Next, 6 lines down, I've changed the $height... line to:
          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.
          }
    3. Finally, near the bottom of the function (line 726 after the additions above), I've changed $ty... to:
        // 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

Status:needs review» needs work

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

Status:needs work» fixed

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

Status:fixed» closed (fixed)

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

Assigned to:Anonymous» Dimm

//  $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.0 equals $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

Assigned to:Dimm» Anonymous
Status:closed (fixed)» closed (cannot reproduce)

#13

Status:closed (cannot reproduce)» closed (fixed)