I really hate Codea ...

… so I’d like to teach it about kerning.

(You can do an internet search yourselves for the reference.)

Actually, not kerning itself - that’s a step further - but at least about proper positioning of characters. This relates to something a few have noticed about characters in italic or swash fonts being truncated.

Way, way back many centuries ago - not long after Codea began - it didn’t have a builtin text renderer, so a few of us wrote our own. Mine was based on the BDF specification. In that, you get the information on how to build a character and the result is an image containing a rendering of that character. But the image isn’t enough because it is just a box containing the character so putting them all together in a line would end up with the characters all aligned by their bottoms. So letters with descenders would be too high. To correct for that, the font includes information - for each character - that defines an offset for the character. Essentially a correction between where you claim you want the character to be (namely, on the baseline) and where it ought to be. It also contained the information on where the next character should start, so that wide characters and narrow characters were all positioned correctly.

In Codea’s text positioning, the former is mitigated slightly by the fact that all the boxes are the same size, so every character has the same space for descender and ascender, even if it doesn’t have them. This means that all the boxes can be placed in a row (though to put them in the right place, you should lower them by the descent - fortunately, this is provided by the font metrics). What is missing is the information on where to place the next character.

Well, actually that information is there and is being used. But it is also being used for deciding how to clip the the character and this is wrong. This is what leads to swash letters being clipped because they overhang the next character. On the other hand, the vertical information seems to be being used the other way: the line height is big enough to contain the whole character but this is (probably) too big: the line height for, say Zapf Chancery is huge - far higher than what anyone would actually write.

So, in summary, when placing a character there are two boxes: the bounding box of the character and the effective size with regard to placing other characters. These should be separate, should be used correctly, and should both be available to the user via queries.

Now, a lot of the above is conjectural which is why I’ve posted it as a discussion here and not yet on the issue tracker. If I’m right in my analysis, I’ll post it there. If I’m wrong, there’s still something wrong so I’d like to know what it is.

This issue arises because of the relatively cheap way Codea uses iOS to render text.

Codea constructs a native iOS UIKit element called a UILabel. It sets up the label with the necessary font and style information, then asks UIKit to get its dimensions (using the sizeToFit method). Codea allocates an image this big (double in retina), and renders the UIKit control into the image, then loads that as a texture into OpenGL.

So the problem lies in the UILabel control. When it computes its size, it computes bounds that are best suited for positioning it amongst other text. When iOS renders a UILabel, by default it does not clip its graphics to its logical boundaries, so it renders correctly.

What we will have to do is measure the font using a lower level API, Core Text, and use that to compute the image bounds.

The problem with this is that we then lose the nice logical bounds that can be used for positioning, and it may cause code that renders existing text strings to render them slightly offset. (i.e. the size returned by textSize.)

My intuition is to leave textSize returning the clipped bounds — because these are useful for positioning, and have the internal image extended such that it does not change the position of the text but allows it to render outside those bounds.

Since we’re on the subject of text alignment not sure if this belongs here but here I go.

Is it possible to flip text upside down somehow? In the past I’ve tried using rotate on it but to no avail it’s always rightside up. I only ask because I have an idea that could use this.

Yes, I don’t want to lose the textSize facility for positioning text - I use that a lot. That’s essential for lining up text that’s rendered not all in one command.

@yuboji Simplest is to render to an image and use that as the texture for a mesh. Then you can do lots of things with it.

.@yujobi the rotate command should work just fine. You can also actually flip text by negatively scaling the Y axis.




text("Test", 0, 0)


.@Andrew_Stacey - “I really hate Codea…” seems a tad harsh. Codea is a mistress who must be wooed with affection and compliments. She is a saucy minx who can be tempestuous if not handled gently. Next time I suggest flowers and chocolates.