Text Wrapping behavior is unexpected about scenic HOT 9 CLOSED

For this, and also the fact that leading spaces are skipped, I'm thinking of re-writing the text renderer. Will introduce subtle behaviour changes, so really want to thinking it through.

In a previous iteration, I actually had a text renderer that probably did all the right things. When I moved the rest of it over to render via nanovg, I went with its text renderer, which is where these issues are.

Anyway, good issue. If I'm going to take a crack at it, please come up with any other things it should do here. I'd rather not keep cracking it open to add more things.

For example: Maybe support for ascii color change codes? That would be great for terminal and code renderers, but is logically inconsistent with the way you set colors in Scenic. Is that acceptable? Any other ideas?

from scenic.

Things I'd like to see:

• Unicode support for text (possibly already there?)
• API for estimating size of font being rendered (would be useful for text-wrapping anyways)
• RTL support for text rendering
• Support for font kerning

Things I don't think are a good idea:

• Color escape codes (are we going to support blinking? how should this interact with transparency? what about later support for theming/palette-swapping?)
• Unicode emoji support (inconsistent across platforms, further grossness with coloring, etc.)
• Animated text codes (blinking, marquee, etc. effects)

from scenic.

It's a good list. Had some of it in previous versions. If I finish the size estimator, then it would be easy for the scene to do whatever color effects it wants and doesn't need to be in the font renderer.

Kerning is tougher, but doable. Part of what makes this hard is that ultimately, I'd like to be able to move away from truetype. The more I write code specific to it, the tougher that gets. (Is similar to the shader discussion in that way). The truetype format is complex enough it pretty much has a turing machine inside of it... Am hoping to be able to use something like Slug in the future...

from scenic.

Ah, Slug is pretty sick. That said, that pretty much requires a license for a commercial driver, no?

from scenic.

I'm also not in favor of ascii color codes. Although controlling the color is necessary for more advanced use-cases.

Having worked primarily with HTML I haven't worked much with systems at this (relatively low) level before so I'm not really sure what to suggest. Of course a font metrics system (#6) would be useful. I'm also wondering if it makes sense to split text rendering into two logical pieces, a plain/simple text rendering that would not support any color/formatting changes within one piece of text, and a rich-text formatting that would support things like bold, color, and transparency changes within the text.

Also I think it may be helpful to describe my current use-case for wanting this in the first place. I am working on a simple Pianobar (pandora.com client) graphical interface for the Raspberry PI 7" official touchscreen (using Nerves). It will look somewhat like this:

[Picture of album cover]
Title: Blaze of Glory
Album: Blaze of Glory
Artist: Jon Bon Jovi

[play button] [next song button]

Of course not all song titles are as short as "Blaze of Glory". Some are more like "An Der Schönen, Blauen Donau (On The Beautiful, Blue Danube), Waltz For Orchestra (With Chorus Ad Lib), Op. 314 (Rv 314)".

Here's a full snippet of the actual data for a longer song:

artist=Johann Strauss II
title=An Der Schönen, Blauen Donau (On The Beautiful, Blue Danube), Waltz For Orchestra (With Chorus Ad Lib), Op. 314 (Rv 314)
album=Weiner Philharmoniker, New Year's Day Concert In Vienna, 1979 [Australia]

What I want is for the title, album, and artist lines to wrap once (so display up to two lines), but if they're still to long to fit, the end of the text should be "..." to indicate that the full name doesn't fit. The play/next song buttons will always be at the bottom of the screen. Of course this would be easier with an actual layout engine (as alluded to in #6) but as long as I can detect the wrapping of the text I can compute the layout myself.

If you want to peek at the code it is https://github.com/axelson/piano_ex but everything is very messy right now and there aren't any instructions (but the PianoUi.Scene.Splash.show_example/0 function will display the issue with the current text wrapping).

from scenic.

Thank you so much for describing your use case! That really helps a lot.

From this, I think the two pieces you need are the text metrics engine and a few fixes in the text renderer. I'm resigned to the fact that I'm going to need to re-write the text renderer and not have nanovg do that piece. Am still hoping to use its font-management as that is a huge pain in the rear.

Let me know your timeframes. I'm still planning to get back to Scenic work in a week or two. If it is urgent, let me know and I might be able to move it up a little, at least in master...

from scenic.

I'm glad that it's helpful. I don't have much timeframe pressure since this display is just for fun, a week or two sounds fine 👍

from scenic.

Basic wrapping api is now in master via font_metrics.

from scenic.

Awesome!

from scenic.