Add TextBox background about embedded-text HOT 9 OPEN

OK, I'll return to my evil plan of removing all code from e-t and will implement background colors for all renderers.

from embedded-text.

I guess this will need some magic if drawing a rectangle before anything else isn't desirable.

For my reference, there are three or four tasks here:

• figure out which colors to apply to text rendering
• draw the "rest of the line" which can be 0, 1 or 2 rectangles per line, depending on the alignment (left, right is 1, center is 2, justified is (theoretically) 0)
• draw background between the lines if line_height > font_height. Maybe simpler to go word by word, to prepare for changing font size inline (either via ANSI sequences or using middleware). Also, per-character bounding boxes can be a headache, but as long as embedded-graphics can draw the background as a neat rectangle, e-t will be covered ;)
• also the planned paragraph spacing must be taken into account - luckily it's a single rectangle per paragraph

from embedded-text.

I guess this will need some magic if drawing a rectangle before anything else isn't desirable.

It might even need some tweaks to the text rendering API. There is no requirement for text renderers to support character backgrounds and without this it won't be possible to render the background without overdraw. But at the moment there is no way for e-t to detect if the renderer supports character backgrounds, so that it cannot fall back to simply drawing a background rectangle first in these cases.

Possible solutions would be:

• Some kind of TextRendererCapabilities struct that can be queried by e-t to figure out if the renderer supports backgrounds. This could be extended to other capabilities in the future.
• Change the setters in CharacterStyle to try_set_... and return an NotSupported error in the default impl.

from embedded-text.

There is no requirement for text renderers to support character backgrounds

That's inconvenient. e-t would love to have this as a requirement, I think. Silently ignoring some of the otherwise supported ansi sequences is certainly not an ideal end result.

from embedded-text.

I'm not sure if I want to make this a requirement. I don't think that, for example, eg-seven-segment would benefit from supporting character backgrounds.

from embedded-text.

I think can understand why, but to be fair, it's a lot simpler to decide between "just drawing a rectangle" vs drawing the background in a more sophisticated way in the font renderers.

To be fair, I'm not sure eg-seven-segment will be widely used together with e-t anyway :)

from embedded-text.

I think can understand why, but to be fair, it's a lot simpler to decide between "just drawing a rectangle" vs drawing the background in a more sophisticated way in the font renderers.

Are we talking about character backgrounds or box backgrounds in this case? I wouldn't expect e-t to try to emulate character backgrounds for a text renderer that doesn't support this feature. And box backgrounds can easily be handled by e-t, if it's able to detect that the renderer doesn't support character backgrounds.

If a text renderer doesn't support character backgrounds in normal Text why would a user expect there to be a background when it's activated using an ANSI sequence?

To be fair, I'm not sure eg-seven-segment will be widely used together with e-t anyway :)

I already used it once ;), but probably won't use this combination ever again. But there might be other crates in the future that also use the text rendering API that could benefit from any issues we identify and fix now.

from embedded-text.

Are we talking about character backgrounds or box backgrounds in this case?

I think box? I'm not sure we want to go down the rabbit hole of actual character bounds.

And box backgrounds can easily be handled by e-t, if it's able to detect that the renderer doesn't support character backgrounds.

This is true enough - drawing a rectangle isn't a big deal by itself. But we have multiple options: Either the font renderers draw a background, or Text / TextBox does. A "maybe" on both fronts is IMO more complicated than necessary.

If a text renderer doesn't support character backgrounds in normal Text why would a user expect there to be a background when it's activated using an ANSI sequence?

Users may not be aware right away what the font renderes can or cannot do. A try_... method call can fail, an ansi sequence can't.

from embedded-text.

Otherwise you need to clear the text box region before redrawing the text box to make sure none of the previous content remains. This can lead to a flickering display, if it is updated directly and doesn't use a framebuffer with explicit flushing.

I came looking for this same feature, because I had this exact problem. With left aligned text I could work around it by figuring out where the text ends after it is drawn and then drawing the rest of the background separately. But with centered text this is harder.

I was hoping the the background color could be extended to the full size of the bounding rectangle.

from embedded-text.