[TYPO3-core] RFC: Bugfix #7452: GIFBUILDER: wrong bounding box calculation with TEXT and spacing

[Ralf Hettinger]

Hi Olly,

thanks for bumping into this issue again...

Am 02.05.2009 20:14 schrieb Oliver Hader:
> Hi Ralf,
> 
> Ralf Hettinger schrieb:
>> This is a SVN patch request.
>>
>> Bugtracker references: http://bugs.typo3.org/view.php?id=7452
>>
>> Branches: trunk only
>>
>> Problem:
>> This issue is somehow mentioned in TSRef GIFBUILDER's section
>> GIFBUILDER.(GBObj).TEXT and concerns the parameter spacing. TSRef states for
>> spacing: "Pixel-distance between letters. This may render ugly!"
>> Indeed it will render especially ugly, if you have antialiasing (ie upscaling
>> and downscaling again) applied to the TEXT object by niceText or antialiasing
>> properties to GIFBUILDER.(GBObj).TEXT.
>> It will as render even more "ugly" if you rely on correct determination of the
>> image width when using [.w] in XY of the whole GIFBUILDER object, with ugly
>> meaning that the resulting "bounding" box of the TEXT object will be generally
>> to small.
>>
>> Solution:
>> Applied patch solves the problem.
>>
>> Notes:
>> The SVN is still open for bugfixes - am I correct? Thanks for clarification.
> 
> Summarizing the rounding error is a nice idea here - it can be compared
> to drawing a line with an angle of 30° in computer graphics. When no
> antialiasing is available it's handled the same (Bresenham's line
> algorithm).

Yep, good old Bresenham might come to mind, only that we're not trying
to draw lines here. Funny you mention it, since have used his algorithm
quite extensively in my diploma thesis ;)

> However, there are also some extra spaces even if niceText is not used.
> The best thing would be if the text rendering would support character
> spacing by default. In general I thing, that there are some flaws in the
> niceText disposal in the GIFBUILDER.

I would tend to agree but admittedly it's been some time since I last
had a dive into GIFBUILDER's internals. I think to remember that I found
some things not quite clear in the code, especially that there are some
roundings here and there which I felt could be resolved exactly as well.

> I attached a modified version of your patch - but I'm still not really
> happy with that...

Haven't testet it, but I think I understand what's being done.

Some comments:

- rescaleValueUsingDelta works properly with other values than 'ceil'
for $adjustment? That looks a bit odd to me.

- We should avoid operations like division ($value /= $factor;) in this
function; I think that could be done outside the loops, couldn't it?

- I feel passing $delta by reference is not that pretty. Shouldn't it be
set to 0 before entering the outer function? Maybe passing an array back
is more understandable, but admittedly ugly as well...

- And (hint to myself!) better comment what we're doing ;)

Looking forward to test&play around that bit during t3dd...

Cheers
Ralf