Bounty proposal: Paint

It’s also not uncommon for people to want to run selected applications from one version on another

It is regrettable when the latest version of an Application refuses to run in an environment that happily supported the previous version.

It is unacceptable when that Application runs for an hour without complaint and then explodes because the user’s click was ‘slightly slidey’.

There is no blame attached to this assertion, just determined expectation management.

the goal is to exceed the capabilities of Adjust’s !Paint

Absolutely. And that version’s instability is one of the things that must be surpassed!

/* GNU Ghostscript algorithm -- this is better*/
int colors = 255 - black;
rgb[0] = colors * (255 - cyan)/255;
rgb[1] = colors * (255 - magenta)/255;
rgb[2] = colors * (255 - yellow)/255;

Yup. Though you don’t do it quite like that with integer maths.

CMYK to RGB:

R=255*(1-K)*(1-C)
G=255*(1-K)*(1-M)
B=255*(1-K)*(1-Y)

The equivalent formula the other way (below) shows first the slightly flawed formula used by ArtWorks to translate an incoming vector graphic draw file into CMY process colours followed by the ‘correct’ version (which is the equivalent of the CMYK to RGB formula above):

However there are difficulties: pale pastel shades of pink and turquoise are difficult to specify in RGB (whatever the translation formula) as there are only 8 bits for each primary colour. In CMYK space there is much more control. It is also difficult to get a dark maroon or brown colour right as different printers will produce the same CMYK process colour in slightly different shades.

Some commercial printers will accept a CMYK image, convert it themselves using a poor algorithm to rgb and then send it to a printer for them to convert back to CMYK for printing (flashbay.com). So even the professionals are somtimes clueless.

The correct formula is as given below:

I’d say “a very much better formula” rather than “the correct formula,” but I’m not convinced it’s the best possible. I say that without being able to offer a better one!

In particular, it doesn’t give the blackest possible black, which is K = C = M = Y = 1.

I’d say “a very much better formula” rather than “the correct formula,”

Yes, in absence of a more complicated formula based on a calibrated monitor and known target printing equipment.

In particular, it doesn’t give the blackest possible black, which is K = C = M = Y = 1.

Yes it is possible to get richer blacks by over saturating but CMYK(1,1,1,1) is too much ink and may not be absorbed by the paper. Using a test programme:

      10 : REM >Test
      20 : :
      21 : ink=0
      30 : FOR r%=0 TO 255
      31 :   PRINT "Testing red=";r%;"   ";:VDU 13
      40 :   FOR g%=0 TO 255
      50 :     FOR b%=0 TO 255
      60 :       k=1-r%/255
      70 :       IF k>1-g%/255 THEN k=1-g%/255
      80 :       IF k>1-b%/255 THEN k=1-b%/255
      90 :       IF k=1 THEN c=0 ELSE c=(1-r%/255-k)/(1-k)
      91 :       IF k=1 THEN m=0 ELSE m=(1-g%/255-k)/(1-k)
      92 :       IF k=1 THEN y=0 ELSE y=(1-b%/255-k)/(1-k)
      93 :       IF ink<c+m+y+k THEN ink=c+m+y+k
      94 :     NEXT
      95 :   NEXT
      96 : NEXT
      97 : PRINT "Max ink=";ink

Yup. It’s complicated…in my journal publishing days, apart from colour half-tone photographs (which we left to the printers (Cambridge University Press) to worry about), we only ever used spot colour (and only for covers) – we were able to do decent half-tones monochrome or spot colour for diagrams, but no way could we do decent CMYK half-tone photos producing camera ready copy on Calligraph printers from RISCOS.

We were allowed 100% K with 100% each of two spot colours, but only ever did it once – never tried to do three spot colours! Not a huge lot of point, although of course you can actually get colours like that that CMYK can’t produce…

even the professionals are sometimes clueless

Sigh.

this is exactly equivalent but is a bit simpler as a formula and takes CMYK as 0..1

We were talking about CMYK sprites. So the input domain is [0,255].

In CMYK space there is much more control

There is not. CMYK is a smaller gamut than RGB.

different printers will produce the same CMYK process colour in slightly different shades

And different monitors produce different colours from the same RGB input.

Some commercial printers will accept a CMYK image, convert it themselves using a poor algorithm to rgb and then send it to a printer for them to convert back to CMYK for printing

Some commercial printers will accept a few lines of handwriting on a scrap of paper, typeset it themselves using a font I don’t like, and then print that. Garbage in, garbage out.

What kind of “CMYK image”? One with a profile attached? In PDF/X format?

Presumably you’d prefer ICC colour management in order to convert your CMYK to whatever device colourants they use? In which case you’re going to have a shock when you hear about colour profile connection space.

For the avoidance of any doubt there is no trivial linear mathematical conversion between RGB and CMYK. Proper conversion is highly nonlinear, multidimensional, and device-specific. But if it’s a choice between getting something on the screen and nothing at all, which is as I understand it what RISC OS 5 users have been enjoying all these years, then it is still possible to do a better job than RISC OS 4 very cheaply.

CMYK (1,1,1,1) is too much ink and may not be absorbed by the paper

In the case of lithographic printers it would probably destroy the paper, damage or at least mess up the press, and earn the lifelong hatred of the press operator.

CMYK (0.2,0.2,0.2,1) would give a richer black without overssaturating

No. “Rich black” is generally K with 20%M. Sometimes 20%C but that’s rather cold.

Pages that only contain K (i.e. with no C, M or Y) are usually cheaper to print.

It is often the case that your jobbing printer will have a double-unit (SpeedMaster) or even small single unit (QuickMaster) for cheap stuff, but commercial-scale short-run printing has been CMYK for as long as anyone can remember, and the only saving would be the price of the plates. The difference in the cost of ink is minute, and could only begin to be factored into the final price if you are printing millions of copies.

Clive said

you can actually get colours like that that CMYK can’t produce

Indeed, and I used to specialise in spot-colour work, which is what led to Vantage. Pantone of course tried to expand the limited gamut of CMYK with Hexachrome, which they’ve admitted (to me, anyway) has basically died except for the greetings card industry (where the packaging is the product).

The little scrollbar colour indicator is thrashing on resize, which is a bit odd as redraw isn’t required. It’s to do with the pointer coordinates not being updated (but it ought to be a child window so shouldn’t need any help from the code – something wrong there).

This issue is now fixed in Paint 2.30 along with a few other bugs ROOL and I found.

nemo I haven’t forgotten about that issue with extension areas. I’ll try and find some time to look into that at some point.

I’m currently coding the Undo / Redo feature. Don’t get too excited though, as knowing me it won’t be ready for months. It’s quite a biggie.

Just had time to play with the latest version of this. Well done! Lots of good additions here, and I think it’s looking very nice indeed.

Some quick comments:
- I think there might be a glitch with the New Sprite dialogue box (unless there’s something up with my setup). If you click away from it after its first appearance, and then invoke it again from the main menu, the title writable field is now empty, rather than ‘Untitled’ as before. Is that intended? I think it probably ought to have a default title every time, but can’t remember if Paint has always done this.
- Also in New Sprite, the text on the Colours dropdown menu is corrupted on my machine – it reads ‘2 \Us’, ‘4 \Us’, etc. Maybe a missing message token here?
- The Ctrl-Zoom is an interesting feature. I tend to use Paint to edit several icon-sized sprites at once, where I want the zoom factor to be consistent (say, 12:1) in order to compare sprites. Using Ctrl-zoom tends to give odd scaling ratios, but I guess that’s unavoidable, given the nature of the drag-to-zoom? Would be practical at all to drag upward in steps, so that the zoom factor goes 1:1, 2:1, 3:1, etc?
- The Sprite File window doesn’t appear to gain the input focus when clicked on, even if this option is set, making it impossible to see whether keypresses are going to be operating there.
- The New Sprite dialogue also never gets the input focus, meaning it doesn’t respond to standard keypresses (Enter, Esc, Ctrl-F2)
- If you click on a Sprite window to give it the input focus, then click on another app’s window, the input focus disappears as it should, and the Paint tools become inactive. However, if you have an input-focus Sprite window and click on another one of Paint’s own windows (such as the New Sprite dialogue box, or a Save dialogue box invoked by pressing F3), then the input focus is lost but the tools remain active, meaning that clicking back onto the Sprite window results in a ‘click of surprise’.

Anyway, great stuff, and thanks for sticking at this :)

- The Ctrl-Zoom is an interesting feature. I tend to use Paint to edit several icon-sized sprites at once, where I want the zoom factor to be consistent (say, 12:1) in order to compare sprites. Using Ctrl-zoom tends to give odd scaling ratios, but I guess that’s unavoidable, given the nature of the drag-to-zoom? Would be practical at all to drag upward in steps, so that the zoom factor goes 1:1, 2:1, 3:1, etc?

Maybe Ctrl-Zoom could be free-form, and Ctrl-Shift-Zoom could introduce the clamping? Or maybe Adjust-drag to have clamping to “nice” scale factors.

Thanks for the feedback.

However, if you have an input-focus Sprite window and click on another one of Paint’s own windows (such as the New Sprite dialogue box, or a Save dialogue box invoked by pressing F3), then the input focus is lost but the tools remain active, meaning that clicking back onto the Sprite window results in a ‘click of surprise’.

This bit is by design. When I first coded the feature so that any click outside the Sprite window lost the focus, it made it incredibly annoying to use. Doing some painting, then clicking on a different tool in the Tools window, then having to click twice to resume painting with it interrupted the flow of using Paint by adding an extra step. I figured that the ‘click of surprise’ issue is most likely to happen when Paint has been left open while other program windows are brought to the foreground and used and then the sprite window is clicked afterwards perhaps accidentally. Clicks in other windows within Paint therefore do not necessitate an extra click in the sprite window to continue using the tool.

The Sprite File window doesn’t appear to gain the input focus when clicked on, even if this option is set, making it impossible to see whether keypresses are going to be operating there.

I didn’t code keyboard shortcuts for the Sprite File window and don’t think I’ve altered the way that behaves, but I’ll give it a test.

Doing some painting, then clicking on a different tool in the Tools window, then having to click twice to resume painting with it interrupted the flow of using Paint by adding an extra step.

Yes, the Tools and Colours toolboxes shouldn’t take the focus, but any window that has keypresses associated with it needs to pick it up. That includes dialogue boxes with Default action buttons, etc. If these are opened from the Sprite window’s menu tree, then they can hand the focus back once all’s done.

One tricky issue is that the Tools window has writable icons in it, which will automatically steal the input focus when clicked on. I’m not sure what the solution is, there. Ideally, the input focus in a Sprite window should be the visual indicator that the tools are active.

Chris,

- I think there might be a glitch with the New Sprite dialogue box (unless there’s something up with my setup). If you click away from it after its first appearance, and then invoke it again from the main menu, the title writable field is now empty, rather than ‘Untitled’ as before. Is that intended? I think it probably ought to have a default title every time, but can’t remember if Paint has always done this.

It’s always done it. I think the thinking must be that often on the first appearance a user will make a sprite with the default name (it’s actually “newsprite”), so it’s left blank on subsequent attempts to avoid a name collision. The modern convention of course would be to append a number to the end, but, hey, out of scope… :)

- Also in New Sprite, the text on the Colours dropdown menu is corrupted on my machine – it reads ‘2 \Us’, ‘4 \Us’, etc. Maybe a missing message token here?

NEWCOL0:2 colours

NEWCOL1:4 colours

NEWCOL2:16 colours

NEWCOL3:256 colours

NEWCOL4:4 thousand

NEWCOL5:32 thousand

NEWCOL6:64 thousand

NEWCOL7:16 million

Would be practical at all to drag upward in steps, so that the zoom factor goes 1:1, 2:1, 3:1, etc?

- The Sprite File window doesn’t appear to gain the input focus when clicked on, even if this option is set, making it impossible to see whether keypresses are going to be operating there.

- The New Sprite dialogue also never gets the input focus, meaning it doesn’t respond to standard keypresses (Enter, Esc, Ctrl-F2)

Yes, the Tools and Colours toolboxes shouldn’t take the focus, but any window that has keypresses associated with it needs to pick it up. That includes dialogue boxes with Default action buttons, etc.

One tricky issue is that the Tools window has writable icons in it, which will automatically steal the input focus when clicked on. I’m not sure what the solution is, there. Ideally, the input focus in a Sprite window should be the visual indicator that the tools are active.

It’s always done it.

Fair enough :)

Could you have a look in your Messages file for Paint

The values are different in the copy of Messages in Resources; they read ‘NEWCOL0:2 \Us’, etc. So something’s odd there – maybe I’ve got a corrupt copy?

[Sprite File window focus is] working on my dev build.

Hmm. No, it’s not showing the focus when I click on it, although a click does get rid of the focus if another window has it, either in Paint or in another app. Again, not sure why this isn’t working here.

[New Sprite window focus] is working fine for me, as long as I click in the sprite name field to set the caret (note the title bar doesn’t turn yellow here, but it never has)

The template file for this window has an input focus colour 2 (mid grey) rather than 12 (light yellow). As this window is now a proper dialogue box with key shortcuts, I guess the template value ought to be updated, so the focus is visible. Hopefully that explains why I’m not seeing it update, anyway.

We need to sort out why the focus isn’t transferring on your machine first.

Slight misunderstanding, I think – on my build here, the input focus is being picked up when I click on the Tools window (if using a tool with a writable icon) or the Colours window (if using the Colour Picker with writable fields). I was querying whether it should. In ArtWorks, for example (which has the same selection model proposed for Paint in this mode), clicks on toolboxes never take the focus, meaning that if the canvas window has the focus then it’s always ready for drawing on, and if it hasn’t, then it’s never ready. Meaning there’s never a ‘click of surprise’. However, given that Paint is using writable icons that always nick the focus, I’m not sure how possible/desirable that would be to implement.

I don’t think this is a massive issue, tbh (and I really like the ‘click to gain focus’ model in general). It would be good to see if the Sprite File focus issue can be fixed, though – if it’s just my copy, I can download a fresh copy and try again.

The values are different in the copy of Messages in Resources; they read ‘NEWCOL0:2 \Us’, etc. So something’s odd there – maybe I’ve got a corrupt copy?

That syntax, a backslash followed by a letter, gets used in Messages to save space, as shorthand for a word that appears frequently (in this case, it should be “colour”). However, the file I submitted to ROOL that is in Gitlab doesn’t have that there. I don’t know whether it’s possible their build scripts are performing further compression on the file, or as you say, whether it’s just your copy that’s corrupt.

Also in New Sprite, the text on the Colours dropdown menu is corrupted on my machine – it reads ‘2 \Us’, ‘4 \Us’, etc. Maybe a missing message token here?

The NEWCOL/NEWPAL text has been put in the {HelpTokens} section of the Messages file, so gets tokenised with !Help’s dictionary in ROM. The disc version doesn’t get compressed, so would appear OK even though the text is in the wrong section.

The NEWCOL/NEWPAL text has been put in the {HelpTokens} section of the Messages file, so gets tokenised with !Help’s dictionary in ROM. The disc version doesn’t get compressed, so would appear OK even though the text is in the wrong section.

Thanks for spotting that Sprow. That’s what happens when I dive into these things without developing a full understanding of the file format and how it gets used. :)

Hi everyone, I could do with a little bit of help please testing an issue that Chris has spotted. If you’re running a recent beta image, please can you run Paint and tell me when you click on the working area of the Sprite File window, whether its title bar changes from grey to yellow to indicate acquisition of the input focus?

It’s working for me but not for Chris, even though the caret is being set successfully. At the moment we just need an idea of whether this is affecting just his system or any of yours as well. Thanks.

I could do with a little bit of help please testing an issue that Chris has spotted. If you’re running a recent beta image, please can you run Paint and tell me when you click on the working area of the Sprite File window, whether its title bar changes from grey to yellow to indicate acquisition of the input focus?

Yes, input focus is gained. Paint 2.30 on Titanium OS5.27 16Feb20, and on both RPi3B+ and RPi4 on OS5.27 01Feb20.

If Paint is not getting the yellow title bar, where is it?

Yes, input focus is gained.

Same here on RPi2 Model B (earlier version, Cortex-A7), Paint 2.30, OS5.27, 16-Feb-20.

Hmm. That’s good news, in that it seems to confirm that Paint’s OK. But bad news (for me) that it’s such a baffling issue.

To confirm, it’s only the titlebar turning yellow that doesn’t work for me – clicking in the Sprite File window enables key presses to work, so the input focus is being gained. All other Paint windows, and all other apps, seem to be fine. So, for some reason, the Sprite File window doesn’t get a visual indication that the input focus has been picked up. Very odd.

I’ll keep playing around, in case something I’ve got set up here could be interfering.

I’ll keep playing around, in case something I’ve got set up here could be interfering.

Are you definitely running all the latest RISC OS modules? I must confess I’m uncertain exactly which ones could be involved here, but it would be good to double check UtilityModule, SharedCLibrary, WindowManager.

Hmm. That’s good news, in that it seems to confirm that Paint’s OK.

Not necessarily! I’m still wondering if there’s some data Paint’s getting on your system that’s overflowing memory somewhere (although it would be quite odd that it only seems to break exactly that feature and nothing else).

Chris one other thing to try, and I’d be amazed if this had any effect, but click to give your Sprite File window focus, then use the resize button to shrink and expand the width to force the OS to redraw the title bar. Any chance it turns yellow then?*

_{*Nah, didn’t think so! It was worth a try anyway. ;)}

please can you run Paint and tell me when you click on the working area of the Sprite File window, whether its title bar changes from grey to yellow to indicate acquisition of the input focus?

RISC OS 5.23 (21st March 2017), latest Paint ¹ – yes it works as expected when loading an arbitrary sprite and clicking either the blank area around the sprite (it was an icon) or one of the pixels of the icon itself; both in 1:1 and when zoomed.

Which means…

Are you definitely running all the latest RISC OS modules?

Not really relevant. My OS build is from three years ago. I guess I ought to update sometime soon(ish).
I believe I’ve been saying that for a couple of years already, how time flies.

¹ Download latest harddisc4 nightly beta; then go to !Boot.RO350Hook.Apps and Paint is in there as a useful standalone app that can be run in preference to the built-in version.
Of course it’s a bit of a mess claiming a copyright of 1992, a version of “2.30 (28-Dec-19)”, and an executable timestamp of twelve hours ago. ;-) I think the date part of the version ought to reflect the actual build date, like RISC OS itself does. That way, it’ll be simpler to determine “this version as opposed to that version”.

yes it works as expected when loading an arbitrary sprite and clicking either the blank area around the sprite

Can I just check we’re all talking about the same window? The Sprite File window is the one I can’t get to work – that’s the grey window with all the thumbnails in it. The Sprite Editor windows (the ones that the tools work on) are fine here.

that’s the grey window with all the thumbnails in it.

Ah, the list not the editor. Fair enough.

<clicky> <clicky>

Yup. Works. Tested with NetSurf’s ASprites22 file, and a new sprite using default (1280×1024) settings.

The Sprite Editor windows (the ones that the tools work on) are fine here.

How very strange. You’d have thought if one works…

Does it behave differently if you start Paint afresh and click the iconbar icon?
[it’ll open the listing window, empty, and the create sprite dialogue]