Improve Text Measuring API

[araid]

Increasing access

This would make the text API more redundant and accessible to those not familiar with OOP.

Most appropriate sub-area of p5.js?

• [ ] Accessibility
• [ ] Color
• [ ] Core/Environment/Rendering
• [ ] Data
• [ ] DOM
• [ ] Events
• [ ] Image
• [ ] IO
• [ ] Math
• [X] Typography
• [ ] Utilities
• [ ] WebGL
• [ ] Build process
• [ ] Unit testing
• [ ] Internationalization
• [ ] Friendly errors
• [ ] Other (specify if possible)

Feature enhancement details

Problem

Right now, there are 2 ways to measure text in p5.js: textWidth() and Font.textBounds(). These 2 calls sit in different parts of the API, and have slightly different behaviors across renderers and font types:

		textWidth	textBounds
P2D	system font	✅	❌
P2D	opentype	✅	✅
WGL	system font	❌	❌
WGL	opentype	✅	✅

A couple additional issues:

• textWidth and textBounds.w show slightly different values (bounds often feels like the more precise one)
• textWidth on WebGL + system font returns 0 with no error

Suggestion

This separation of functionality feels arbitrary and potentially confusing to new users. These small changes could be implemented as part of the 2.0 typography push or just as an improvement to the current API:

1. Make both functions available in the global scope and in p5.Font. This should ensure backwards compatibility.

   • Add textWidth to p5.Font
   • Add textBounds to p5.Renderer

2. Allow textBounds to work with system fonts in P2D by using the native measureText

[Vishalll07]

Hey @araid , I am new to OpenSource contribution..can you help me contributing to it ? As I understand the problem both the functions textWidth() and textBounds.w() don't work properly across renderer and p2d font class. So I need to add textWidth function to the p5.Font and textBounds function to the p5.Renderer. and adapt the method to use the native measureText API... Is it so ?

[dhowe]

Hi all. So these are actually two different functions, with different intended behavior. The latter operates on a custom/loaded font only, and returns the exact bounds for a specific string of text, based on the actual paths of the various characters. The former measures the width similarly for a loaded-font, but uses measureText() in the browser case, as we don't have access to the font paths for browser fonts. It may simply be that the documentation needs to be clearer about how the measurements differ. Regardless this is all being rethought for v2.0, and its likely that p5.Font will be removed and/or moved into a library

[araid]

Thanks for the clarification @dhowe. I understand the differences, and still think the API is potentially confusing for newcomers. Why offer only textWidth() at a global level, when textBounds() could do the same and more? That's why I tried to phrase it as an enhancement, not a bug.

Glad to know that's being rethought for 2.0. Would love to be a part of those conversations.

[dhowe]

v2.0 will provide textBounds() and textWidth() for tight (string-specific) bounds, and fontBounds() and fontWidth() for loose (font-specific) bounds, for all fonts - hopefully this should resolve any lack of clarity in the current api