Font Painting with Logical Operations

I think I already know the answer to this, but can anyone think of a way to paint a font using a logical operation (AND / OR / EOR) onto the background?

I’m planning to do it by rendering the text using Font_Paint into a 2-colour sprite with a mask and then plotting the resulting sprite using the logical operation. I just wondered if there might be another way to do it, although I couldn’t see one in the PRM.

2 colour will look awful unless the text is massive.

It’s for the text tool on Paint, primarily because it has the text follow the mouse pointer to show where the tool will place it, and that’s normally drawn and erased using EOR, although I suppose that will still work with more colours. The bonus is that sprite will then allow use of the Set / OR / AND / EOR radio buttons on the tool window, which as far as I know otherwise wouldn’t work with fonts (other than the system font) on the text tool.

Is this just for the preview on screen, or is it for the actual font rendering?

Because it might be better to forgo EOR/AND/OR in order to allow fully background blended font insertion.

I wouldn’t use it for the usual “Set” mode of editing the user’s sprite (which would be done via a direct Font_Paint), so yes proper blending should work in that mode.

Rick you may have saved me a lot of future trouble with your tip in another thread not to specify “current font” when setting the font colour, thank you!

Edit: Thinking about it some more, it would probably only break if RISC OS ever gets pre-emptive multitasking, otherwise you’d hope “current font” would stay as whatever you selected up until the next Wimp_Poll.

Rick you may have saved me a lot of future trouble with your tip

;)

otherwise you’d hope “current font” would stay as whatever you selected

You would have thought so, but if anything running “in the background” makes use of FontManager, this could mess things up. Unlikely, but not impossible. ¹

Better to always specify font handles and not make assumptions.

¹ Consider making a nice looking bitmap for an OLED or eink display.

This would probably mess with the current font, if I ever get around to implementing font drawing…

https://heyrick.eu/software/oled/

You cannot rely upon ‘current font’ being a font you selected earlier, even in the same Wimp_Poll. It is better to use explicitly the font handle that was returned.

“Edit: Thinking about it some more, it would probably only break if RISC OS ever gets pre-emptive multitasking, otherwise you’d hope “current font” would stay as whatever you selected up until the next Wimp_Poll.”

It wouldn’t be unreasonable to have a per-task current font, to go along with per-task graphics contexts and sprite redirection.

Once the OS knows what a task is, certainly. ;)

It wouldn’t be unreasonable to have a per-task current font, to go along with per-task graphics contexts and sprite redirection.

Aren’t current printer drivers intercepting graphic vectors to do their job? I suspect the whole graphic and printing system will need to be redesigned to cope with multiple graphic contexts.