baseline property for field objects

[Ledigimate]

Mark and Jacque,

The ratio cannot be a constant because I've found that it varies among different fonts, e.g. it is different for "Times New Roman" and "Raavi", even if the textSize and textHeight are the same for both fonts. I agree about our having to examine the engine's source code -- perhaps the "showLines" property can give us a hint. I just don't have the source code in order to have a look yet.

Gerrie

[bn]

Hi,

I would like to join the fun of determining the base line of text and position objects accordingly.

My proposal needs LC 6.5 and up. It uses

measureText(text,object reference,[mode]) and the formattedRect

I used 4 standard buttons that are about 2 pixel above text baseline, in other incantations of the button that is only 1. But that is consitent across all textSizes from 10 to 72. You might want to adjust an offset taking into account the type of object you want to display with its bottom set the the baseline of the text.

When opening the stack all available fonts are rendered into a field and that takes a short while, your system/LiveCode does not hang...

It is supposed to be a convenience afterwards...

BTW contrary to what one would expect the formattedRect of text is often not exactly the boundary of the visible text, especially for weird fonts. But that seems to be irrelevant for the stack I post.



Kind regards

Bernd


EDIT: Sorry I uploaded an early version of the stack that did not work, now the stack is the stack that works for me.

[Ledigimate]

Hi Bernd,

Thanks for joining in the fun. I tested your stack on my system (Windows 8.1) and unfortunately the buttons doesn't line up to the baselines. I don't know if I'm the only one it doesn't work for. I also tried subtracting the descent from the lower boundary of the formattedRect, but for me it doesn't yield the baseline's vertical position.
Before I submitted the first post in this topic, I found a workaround that takes a snapshot the size of the formattedRect and then analyses the pixel data, but this workaround is way too slow.

I'm so curious about how the LiveCode engine knows where to draw the baselines, so I'll be heading over to GitHub to get my hands on the source code right after submitting this post. I'm not an expert at analysing C++, so I hope I can make enough sense of it, heh.

Regards,

Gerrie

[bn]

Hi Gerrie,

Where do the buttons line up? Is it a constant offset from the baseline across various textSizes?

You do have fixedLineHeight true for the field your testing on and all lineHeights are the same?

I also tried subtracting the descent from the lower boundary of the formattedRect

That is what the stack I posted does.
I am a bit surprised. Though I do this on a Mac there should not be anything platform specific to formattedRect and measureText. Unless it is a bug in LC running on Windows 8.1.

I found a workaround that takes a snapshot the size of the formattedRect and then analyses the pixel data, but this workaround is way too slow.

I did this once for the "real" rect of text which is not equal to the formattedRect. And you can get this so fast that it would probably not be noticeable, especially in your case where all you probably need is the baseline once and add the textheight for the rest of the lines. (it would be enough to get a snapshot from a single space when showLInes is on, then compare row-wise a from the bottom up the snapshot against a row of 255,255,255 you set up before. I bet it is less than 10 milliseconds for that.)
But actually you should not have to make this workaround, the code I posted should work.

I would be interested in someone testing the stack I posted on Windows in its various flavors.

Kind regards
Bernd

[Ledigimate]

Bernd,

I played again with your stack, and it WORKED once I corrected an incorrect variable name (tFormRect) and replaced pValue with the effective textHeight of the field! THANK YOU, BERND! You've just made my day! So that solves it then. I must have confused the formattedHeight and formattedRect properties.

Now, to bring Mark and Bernd's suggestions together, one could implement the baseLine property as follows:

Code: Select all

getProp baseLine[theLineNr]
   local tBaseline
   put the short id of the target into tID
   if there is a field id tID then
      put item 4 of the formattedRect of line 1 of field id tID into tLowerBound
      put item 4 of measureText(line 1 of field id tID, field id tID, bounds) into tDescent
      put 2 + (tLowerBound - tDescent) + (theLineNr - 1) * the effective textheight of field id tID into tBaseline
      -- I added 2 above because it was off by 2 pixels
   end if
   return tBaseline
end baseLine

setProp baseLine theBaseLine
   put the short id of the target into tID
   if there is a field id tID then
      put item 4 of the formattedRect of line 1 of field id tID into tLowerBound
      put item 4 of measureText(line 1 of field id tID, field id tID, bounds) into tDescent
      put 2 + (tLowerBound - tDescent) into tBaseline
      set the top of field id tID to theBaseLine - (tBaseline - the top of field id tID)
   end if
end baseLine

And to prove that is works, I've attached the modified version on Bernd's stack to this post. Have a look at the card's script and the slider's script.

Thank you so much for all your help, Mark, Jacque, and Bernd!

Kind regards,

Gerrie

[bn]

Hi Gerrie,

Sorry, I caused confusion by uploading a early version of the stack (not working as you noticed) and corrected this now by uploading the real stack.

I am glad you found your way around in my early fumbling, but this is the one I think solves the problem of the baseline of text.

Kind regards
Bernd


Edit: I attach the same original stack here to avoid confusion as to which stack I mean. So now both of my uploads are the same stack.

[Ledigimate]

Hi Bernd,

It works beautifully! Thank you so much; I owe you one.

Regards,
Gerrie