Text metrics

[scottgarner]

textWidth() seems to only return the correct value after calling text().

function setup() {

  background(0);
  fill(255);
  noStroke();

  textSize(20);
  s = "String.";

  // Returns 28.9013671875
  console.log(textWidth(s));

  text(s, 0, 50);
  // Returns 57.802734375

  console.log(textWidth(s)); 

}

I think it's just a matter of setting this.drawingContext.font before calling this.drawingContext.measureText(), but I'm not sure what would be the preferred approach.

I'm thinking the best plan is to take this out of text(), which is inefficient since there's no reason to set the styling for every call if it hasn't changed, and instead set this.drawingContext.font anytime a relavant property (size, style, font) is updated. This way everything is always up to date for text(), textWidth() and textHeight();

[scottgarner]

Okay, so the above changes work, but I think there's a bigger problem. measureText() returns a TextMetrics object that doesn't actually include height. Maybe some browsers support it, but it isn't in the spec. I checked on a Mac in Safari, Chome and Firefox and doesn't look like textHeight() works at all in its current form?

[dhowe]

I just noticed this (separately) as well. textHeight() returns undefined in all my tests. Seems that also textAscent() and textDescent() are missing from Typography/attributes.js. I'm not aware of a simple fix for this, so I'm wondering if we might use Font.js (https://github.com/Pomax/Font.js) to grab these values (its MIT-expat licensed). Thoughts?

[scottgarner]

I've looked on SO for a good solution and found a few articles. Looks like the only way to get the true pixel height of a given string is to manually calculate it by drawing to a canvas and examining the pixels. Bummer! That's what Font.js seems to do to get the ascent and descent, which it adds to get the height.

Some reading:

http://videlais.com/2014/03/16/the-many-and-varied-problems-with-measuring-font-height-for-html5-canvas/
http://mudcu.be/journal/2011/01/html5-typographic-metrics/#baselineCanvas

[lmccart]

thanks for looking into this @scottgarner and @dhowe.

font.js looks light enough and seems to do what we want. I'd propose trying to wrap this in. alternatively, we leave textHeight etc out of the API and refer users to adding font.js or similar themselves. but I think it'd be nice to take the burden off and support these methods if possible.

[scottgarner]

Thoughts on handling the wrapping? At a minimum, at startup and whenever textFont() is called a new Font object would need to be created. Kind of a bummer since it creates a giant canvas even if you don't use any text. Maybe this should all live in a typography addon?

We could also try to build our own version with a similar technique, perhaps only creating the test canvas when the height, ascent or descent are checked.

[dhowe]

One idea might be to detect font-face rules in the css -- if one or more is found, then it creates the offscreen canvas, does the measurements, and creates one or more font objects (we might also add the loading into the preload routines)...

So we would only be creating the extra canvas when fonts are used -- or, since in the p5.js case, as we already have a canvas, we may be able to use it for the measurements rather than creating an additional one (though if the text is larger than the user-created canvas, the measurements may not be correct).

[scottgarner]

Size would definitely be a concern using the default canvas. Font.js goes with 1000x1000. It has placeholder logic for slicing up longer segments, but it isn't implemented. I might also worry about state? If you were in the middle of a draw loop and added some text, you'd have some time where your canvas was taken over to be solid white with black text. Since there's lots of looping through pixels, it might even last a couple of frames?

Looking for font-face is an interesting idea, but we'd want it to work with system fonts, too, and even generics like "serif" and "sans-serif".

I experimented with some techniques from this SO post that use spans instead of a canvas, but the results aren't quite what I'd expect:

http://stackoverflow.com/questions/1134586/how-can-you-find-the-height-of-text-on-an-html-canvas/25355178#25355178

[dhowe]

I think we are only talking about (max) ascent + descent (which can be computed once in preload), no? If we scale these values to the font-size, we get a (max) height measurement for any text string. This will not be a tight bound (taking into account descenders, etc.), but this is also the case in the Processing API -- it is only textWidth() that takes a string argument, textAscent() and textDescent() are constant for a given font/size. So I'm not clear on the problem mentioned above in the draw() loop...

And I'm not sure we can get measurement data for system fonts -- or at least not according to Font.js: 'system font files cannot be inspected, as they do not have an associated font.metrics object...'

But the span option looks interesting -- what kind of results did you see @scottgarner ?

[scottgarner]

Oh, right. I see what you mean. I guess my expectations for textHeight would be the actual pixel height for a given string. And actually, textHeight() doesn't seem to exist in Processing proper? I'm remembering now just adding the ascent and decent on a project years ago.

In that case, the span trick might be the right solution for ascent and decent? It also looks like the HTML "living standard" has a much more robust treatment of text metrics, including bounding boxes, that we might consider down the line.

http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting.html#textmetrics

[dhowe]

Yes, I think whatever we do is probably a stop-gap until better support in the browsers... I also just tested the span solution and it seems OK, at least for system fonts. Also, and perhaps this is (or should be) a separate issue, but is there a method for loading non-system fonts (font-face fonts, etc., and also making sure they are preloaded before drawing starts)?

[scottgarner]

I think the idea is that PFont would handle that? It's mentioned in #60.

[lmccart]

yeah the whole pfont thing needs some rethinking, and I think we could feel free to change up the API with this to suit the web. at the minimum it'd be nice to have an easy way to hook in a font without having to touch css. with the text metrics. if some end up just being more hassle than they're worth we could probably cut things for now, considering support will likely change and improve in the future.

it sounds like both of you have more thoughts and experience with text so I'm happy to go with whatever you conclude.

[scottgarner]

I'll take a stab at ascent and descent next week based on the span method,
which seems fairly reliable. I'd vote we drop textHeight() to avoid
confusion and since it isn't in Processing.

One question of approach: Do you think it would be better to calculate the
measurements whenever font properties were changed, or to calculate on the
fly when textAscent() or textDescent() are called?

On Sat, Sep 6, 2014 at 6:43 PM, Lauren McCarthy notifications@github.com
wrote:

yeah the whole pfont thing needs some rethinking, and I think we could
feel free to change up the API with this to suit the web. at the minimum
it'd be nice to have an easy way to hook in a font without having to touch
css. with the text metrics. if some end up just being more hassle than
they're worth we could probably cut things for now, considering support
will likely change and improve in the future.

it sounds like both of you have more thoughts and experience with text so
I'm happy to go with whatever you conclude.

—
Reply to this email directly or view it on GitHub
https://github.com/lmccart/p5.js/issues/356#issuecomment-54734489.

[lmccart]

maybe calculate once when textAscent or textDescent is called if font properties have changed since last calculation?