Calculating Text baselines in pixels

[capellan]

Hi All,

How could we calculate text baselines in pixels
starting from the top of the stack?
(Number 5 in the image)

Livecode offers closely related properties.
For example:

formattedLeft measures the left of the
character starting from stack's left.

formattedTop measures the top of the
character starting from stack's top.

formattedRect measures the enclosing rectangle
of the character starting from stack's topleft.

Thanks in advance!

Al

LiveCode text baseline.png

[dunbarx]

Capellan.

But you have answered this yourself. If you have, say, the formattedRect of line 2 of fld "yourField", then the last item of that function is the baseline of that line, no?

Perhaps you have to make sure the bottom margin is "0"?

Craig Newman

[capellan]

Hi Craig,

But you have answered this yourself. If you have, say, the formattedRect of line 2 of fld "yourField", then the last item of that function is the baseline of that line, no?

No, is not.

The last item of the formattedrect is 359 pixels from top (the bottom of the green rectangle) while the text baseline is at 346 pixels from top (the orange line)

Al

[dunbarx]

Hmmm.

As usual, a bit more complicated than first appears. I tested with a field, and the fourth item of the formattedRect of a line is exactly where the baseline should be

If I set the hGrid, the baseLine moves. If the margin bottom is not "0", there is yet another displacement. I assume all these are able to be taken into account.

But I feel that Capellan has more in mind than these simplistic musings.

Craig

[dunbarx]

Hi.

We are both on line, I see.

Starting with a simple field with margins set to 0, are you able to verify that the baseline of any arbitrary line is at item 4 of the formattedRect?

I have a "mouseMove" handler in the card script that sets the cursor to arrow and reports the mouseLoc.

Craig

[bogs]

Not sure I understand what your looking for Al, if your looking for the bottom of the text, wouldn't that just be the item of the rect of the text for the bottom?

If your looking for something else, take another shot at it, or hopefully someone else knows what your asking for.

Edit - DOH! I see Craig and I were answering at similar times, and thinking similar thoughts

[capellan]

Hi All,

Probably a screenshot and scripts for finding a pixel difference
could make the job. By the way, looks like the font baseline
rest 1 pixel above the line visible after setting the showlines
property.

http://livecode.wikia.com/wiki/ShowLines

The purpose of getting the exact x,y coordinates of the text baseline
is to save the text fields in svg format that requires this info.

For example:
https://developer.mozilla.org/en-US/doc ... ement/text

Al

LiveCode text baseline 2.png

LiveCode text baseline 3.png

[jacque]

Hmmm.

As usual, a bit more complicated than first appears. I tested with a field, and the fourth item of the formattedRect of a line is exactly where the baseline should be

If I set the hGrid, the baseLine moves. If the margin bottom is not "0", there is yet another displacement. I assume all these are able to be taken into account.

But I feel that Capellan has more in mind than these simplistic musings.

Craig

In typography the baseline is not the bottom of the text, it is the imaginary line where the main part of the character sits. The capital D does sit directly on the baseline, whereas the descender of a lower case p will hang below it.

I'm not sure how to calculate the percentage for the height of the baseline, but in the past I've guessed at 2/3 the textheight and then adjusted it visually with trial and error. There's probably a formula for it somewhere.

I suspect LC adds a pixel when drawing gridlines just for esthetics.

[capellan]

Hi All,

After consulting other sources, the most accurate method is
read truetype or opentype font and get the value directly
from the font binary data.

I will try this now.

Update: This works!

Code: Select all

put url ("binfile:" & specialFolderPath("fonts") & slash & "arial.ttf")

Now, I just have to convert the binary data in hexadecimal to
study TTF and OpenType internal structure.

Al

[[-hh]]

Did you already try mode "bounds" of measureText(text,objectReference,[mode])?

[dunbarx]

Hermann.

"measureText"

I am always surprised that there are native gadgets in LC that I have never heard of.

Craig

[[-hh]]

Hi Craig.

MeasureText and its sister measureUnicodeText probably do in mode "bounds" what Al intends to do.
• In LC Script I used these very seldom.
• In LC Builder there is also "measure <text>" and "layout bounds" and "image bounds" of <text>. We can't draw text exactly on a canvas without using one of these.

[bn]

Hi Alejandro,

here is a very rough stack that determines a lot of measures for fonts. It is not cleaned up but maybe it helps.

It uses measureText and formattedText, lets you choose text size and font interactively and indicates with graphics the different values.

Kind regard

Bernd

HowFontsMeasure.livecode.zip

(9.51 KiB) Downloaded 192 times

[[-hh]]

Hi Bernd,

if I remember right, the formatted-"thingies" and measureText work correctly only if the margins are the default value (I think now 8 and 7 in the past). I had a long time ago an info from Peter about this bug.
May be this explains (part of) the offsets in your demo?

[bn]

Hi Hermann,

I think most of the variability is the fonts. They vary widely in what they report as baseline, upstroke and downstroke. This affects very much Asian fonts that have other requirements to display and when they display roman/ASCII text this shows.

One of the wildest outliers is Zapfino. Which is handcrafted and has weird metrics.

But I also added a snapshot of the text to determine the visible top of the text. Works quite well.

Kind regards
Bernd