5.24: odd undercolour in pdfs of Draw files

I’ve come across a really weird problem trying to print a calendar containing Draw files, using OvationPro for page layout, to file as a PDF on a Pi3 running RO 5.24. The resulting PDF shows a pale cream or yellow undercolour over the whole area of the Draw file, when viewed using !PDF on RISC OS or Adobe Acrobat or GSview on a Win PC, and also – crucially – when printed out. The tint is not visible in the original OvPro page, and was not set up to print so. Printing the file to Postscript in RISC OS and using !PDF3 to output it makes no difference, nor does using GSview to output the RO postscript file on the Windows machine. This effect appears on a Pi2 running 5.24 as well as the Pi3. Reverting to 5.23 (bcm048) cures the problem entirely on both machines, as does replacing the Draw file with an Artworks bitmap, and the effect is not seen when printing the Windows version of OvPro, so I’m confident this is not a problem in Ovation: it seems pretty clear that it’s generated by 5.24 in some way. Has anyone else come across this oddity?

Do you have a sample Draw file and resulting PDF file so that I can investigate please?

You don’t seem to say what you’re using to create the PDF? There are some known gotchas, which are doumented in the PS3 manual. Using a custom optimisation (in PrintPDF’s terminology) instead of one of GS’s presets can help, IIRC.

@ Chris, Steve: I’m using the PDF3 driver (my copy dated 11 Nov 2015) supplied along with the PostScript 3 printer driver (v.1.20) from Martin Wuerthner and John Tytgat, which sends a file to PrintPDF; but as I said, using the Postscript 3 driver to generate a PS file makes no difference. I’ve now prepared three test pages: a pdf generated by PDF3 from the OvPro original, a screengrab of the page as displayed by Acrobat on a PC, and a screengrab of the page as displayed by GSView on a PC, both of which show the yellow tint underlay absent in the original OvPro page: I can send these (plus a sample drawfile) if you care to email me at george dot greenfieldbt at btinternet dot com. When printed out, the yellow tint is clearly visible. Just to complete the conundrum, when printing the page using whatever pdf renderer is built into the iPhone, the tint is absent and the page prints normally!?
EDIT: all the above done under 5.24 [16-Apr-18] and Printers 1.89 [28-Feb-18]
EDIT2: I must emphasise, the yellow tint does not appear when 5.23 is running on the Pi3. I’ve been producing this calendar the same way for ten years and this particular problem only arose under 5.24.

I’m using the PDF3 driver (my copy dated 11 Nov 2015) supplied along with the PostScript 3 printer driver (v.1.20) from Martin Wuerthner and John Tytgat, which sends a file to PrintPDF; but as I said, using the Postscript 3 driver to generate a PS file makes no difference.

It won’t make any difference, as they are both the same driver. The PDF3 printer definition just has a different iconbar icon, so that it is clear what it does when linked to PrintPDF.

Have you read the PS3 manual, as I suggested? Now that I’ve got a RISC OS machine nearby, I can confirm that the bit that you need is Chapter 3, and the section on PrintPDF.

What Optimization setting are you using? The problem that you describe occurs with some of the presets, and I’d suggest manually setting up a Custom optimization – perhaps following the suggestions in the PS3 manual.

I shall certainly look at the optimisations as you suggest, but nothing you’ve said explains why, with identical files, drivers and settings, the system prints correctly under 5.23 and incorrectly under 5.24.

George – have you checked what versions of !Printers (and sub-modules) are being used on your 5.23 setup. Or are you literally just changing the ROM with the same disc image?

On 5.24 I’m running !Printers 1.89 (28-Feb-18); I’ll need to insert the 5.23 card to check what versions it uses, but I’m 99% sure that they are earlier – the 5.24 install was ‘clean’. FWIW the 5.23 version I was running is high vector, like 5.24. I had retroinstalled the bcm048 module on my version of 5.23. I should also point out that I’ve been producing annual versions of the calendar since 2009 without this issue, using the same programs and methods, initially on an Iyonix running whatever flavour of RO 5 was extant (5.17? 5.20? I forget), and thereafter on most iterations of 5 since (RC14, RC15 etc).
EDIT: 5.23 is using !Printers 1.85 (07-May-16).

EDIT: 5.23 is using !Printers 1.85 (07-May-16).

Only 4 versions of !Printers and 2 years of OS changes to search through to be sure that is is or is not an OS / !Printers change then. :)

Perhaps running !Printers 1.85 on the RO5.24 (with all the rest of the !HardDisc install at the 5.24 release level) would eliminate a suspect?
Then possibly a step through various versions of the OS ROM to pin things down to a rough date, or similar process with the versions of !Printers 1.85 – 1.89

I printed the document on RISC OS 5.24 (16-Apr-2018) using !Printers 1.83 (19-Feb-2014) on my Titanium and get no pale shadow. This is the latest update for the Titanium including the ‘InSituBootUpdate’ but not copying over the Apps, Printers etc. directories. The command

*TaskWindow "ps2pdf13 printout.ps printout.pdf"

printed the document on RISC OS 5.24 (16-Apr-2018) using !Printers 1.83 (19-Feb-2014) on my Titanium and get no pale shadow.

So there’s a distinct possibility it isn’t the 5.24 OS. I suppose testing with 5.24 and Printers 1.85 is next. Then skip through the !Printers versions (only !Printers) to see if/when it fails.

So there’s a distinct possibility it isn’t the 5.24 OS.

As I’ve now said in two posts, when I’ve seen this effect it has been linked to the optimization settings passed to (or assumed by) Ghostscript. The ps2pdf13 command is unlikely to be using the same settings as PrintPDF, PDFMaker, or whatever, so there’s a difference right there.

IIRC, PrintPDF defaults to one of the problematic preset optimizations, so a question might be whether its settings have been lost from Choices in a !Boot upgrade since the last time this calendar was printed?

As I’ve now said in two posts, when I’ve seen this effect it has been linked to the optimization settings passed to (or assumed by) Ghostscript.

When trying to diagnose a fault with a user adamant that it is down to something they “know” then a few tests that prove it isn’t go a long way.

to quote George:

I shall certainly look at the optimisations as you suggest, but nothing you’ve said explains why, with identical files, drivers and settings, the system prints correctly under 5.23 and incorrectly under 5.24.

As far as George is concerned the difference is the OS (tests now suggest not), but with the guidance for OS upgrades to include a complete HardDisc install, or by the looks of things for George a new install on a different drive there’s a high likelihood that the config information in Choices is different too.

Perhaps a rename of the existing file on the faulty setup and a copy in of the same file from the working install would be the thing to do?
If that fixes things then perhaps the author of PrintPDF could be persuaded to update it so that it defaults to settings that don’t give this effect.

UPDATE: I’ve now gone into PrintPDF’s optimisation settings, and have successfully printed drawfile pages without the tint from my 5.24 Pi using the Custom (no downsampling) and Custom (downsampling selected) options: previously PrintPDF had been set to Printer, so it looks like that was the issue*. I will test the Default option to see if this works ok and report.
[*I haven’t checked PrintPDF’s settings under 5.23, I suspect they were Printer also as the app was copied across to 5.24 from the 5.23 $.Printers directory: more on this once I’ve looked]

[*I haven’t checked PrintPDF’s settings under 5.23, I suspect they were Printer also as the app was copied across to 5.24 from the 5.23 $.Printers directory: more on this once I’ve looked]

Ah, you’re assuming that copying the application folder copies the chosen configuration, which in many cases in RISC OS it does not because the chosen config is saved in Choices – so within !Boot.Choices.PrintPDF you will a file called “Choices” that contains you PrintPDF settings.

The rest of us assumed (rashly) you’d copied settings across.
Steve Fryatt 1 rest 0

On defaults we can reverse that I suppose.

Ah, you’re assuming that copying the application folder copies the chosen configuration

If I lost the 5.23 settings in copying across, as you imply (and I believe your explanation), it seems odd that PrintPDF should default to Optimisation=Printer rather than Optimisation=Default. But anyway. I’ve been doing some systematic testing: Optimisation=Custom produces top quality but unwieldy pdfs roughly twice the size of the original application file (so my calendar’s 78MB results in a 150MB file, which rather defeats the object of the ‘p’ in pdf). Selecting the downsampling option in Custom results in visible bitmapping, which is not acceptable for print purposes. The Prepress setting is the best option tested so far (reasonable filesize, no yellow tint, top image quality). All the above tested on 5.24.
EDIT: and checked in Adobe Acrobat on Win PC.

If I lost the 5.23 settings in copying across, as you imply (and I believe your explanation),

I think it’s easy to forget that program choices are, by design and OS guidelines, normally held in Choices. This sort of thing highlights why it’s a bad idea to hide the user Choices away in the system !Boot rather than a directory like $.Users.Steve.PrintPDF

Which brings us round to the old topic of splitting and re-engineering the !Boot such that system and user aspects are quite distinct which brings quite a few benefits – not least that total replacement of !Boot doesn’t touch user preferences.

It seems odd that PrintPDF should default to Optimisation=Printer rather than Optimisation=Default.

However to quote Steve Fryatt

PrintPDF defaults to one of the problematic preset optimizations

So that could be altered to default to a non-problematic preset

I’ve been doing some systematic testing: Optimisation=Custom produces top quality but unwieldy pdfs roughly twice the size of the original application file (so my calendar’s 78MB results in a 150MB file, which rather defeats the object of the ‘p’ in pdf). Selecting the downsampling option in Custom results in visible bitmapping, which is not acceptable for print purposes. The Prepress setting is the best option tested so far (reasonable filesize, no yellow tint, top image quality).

That can’t be correct…

All of the preset options are simply shortcuts, within Ghostscript, to a specific set of “custom” options. These cover both the options exposed in PrintPDF’s custom optimization dialogue, and others. I’d guess that some of the others are triggering the background tints.

The size of the file will depend on the type of image compression used, the target resolution for images, and any downsampling threshold. That’s basically it: compared to the image data, the rest of a PDF is usually insignificant. If the file sizes change significantly, it’s because you’ve processed the images differently. This can be set in the custom options.

Very quickly, because I’m afraid that I have other more pressing things to be doing, the resolutions used by the presets are (at least on the current Ghostscript in Ubuntu 16.04, but the numbers sound familiar, so I’d guess the RISC OS port is similar) as follows:

As I’ve previously said, I’d always use the Custom option in PrintPDF. However, when the output matters, I’d also set the images up in the source document so that I get exactly the required DPI for each one. It’s much safer to pre-size the images so that you get the resolution that you want by design.

The trick is to remember that RISC OS works at 90dpi. If you need 180dpi, your images need to be scaled at 50% in Ovation Pro. For 300dpi, you need 30% scale, and so on. If you’re doing a calendar with the same layout on each page, you’ll probably have the same size frame for each month. You can therefore work out (perhaps using Chris Johnson’s UnitConv) exactly how many pixels your images must have in each direction, and pre-scale or crop them using a suitable piece of software before dropping them into Ovation.

I should probably add that I’ve just done exactly this (albeit in ArtWorks) and the results – at 300dpi – have just returned very glossily from the printers in the form of some full-colour wall calendars. :-)

So that could be altered to default to a non-problematic preset

It could indeed. I’ve just looked at the code, and will see what I can do. Those who saw me on Saturday will know that I might be a little distracted for a few weeks, however. :-(

That can’t be correct…

When you’ve got time Steve I’d welcome your advice, as I find PrintPDF’s Choices behaviour idiosyncratic to say the least. The !Boot.Choices.PrintPDF.Choices file seems to retain settings even when these are changed in the icon’s Choices menu dialogue: reverting to ‘Default’ and saving same after selecting and saving ‘Custom-optimisation’ doesn’t clear the file’s custom settings. Then there is the further issue that a ‘Choices’ dialogue is presented during the printing process: selecting ‘Default’ in this when ‘Custom’ has been previously selected and saved in the icon’s Choices menu dialogue results in a postscript error and no file saved. As I say, when you have a moment, perhaps you could set me straight if I have misunderstood the procedure here.
EDIT: I tried rebooting to see if de-selected Custom-optimisation settings are retained in the Choices file even after a reboot – they are. AFAICS the only foolproof way to revert to Default from Custom settings is to delete the Choices file and re-save the selected options in the icon’s menu dialogue.

The !Boot.Choices.PrintPDF.Choices file seems to retain settings even when these are changed in the icon’s Choices menu dialogue: reverting to ‘Default’ and saving same after selecting and saving ‘Custom-optimisation’ doesn’t clear the file’s custom settings.

Of course it doesn’t: the settings are still there, because if you go back to custom, you would expect to keep the settings that you had entered last time. In fact, all of the settings are always there: they are only saved into the Choices file if they differ from PrintPDF’s hard-coded default value, however.

What actually controls the setting used is the Optimization value: if this is -1 the custom values are in use, but with any other value, a preset is selected.

Then there is the further issue that a ‘Choices’ dialogue is presented during the printing process: selecting ‘Default’ in this when ‘Custom’ has been previously selected and saved in the icon’s Choices menu dialogue results in a postscript error and no file saved.

It does? That sounds like a bug, but I don’t recall ever seeing a report about it?

EDIT: I tried rebooting to see if de-selected Custom-optimisation settings are retained in the Choices file even after a reboot – they are. AFAICS the only foolproof way to revert to Default from Custom settings is to delete the Choices file and re-save the selected options in the icon’s menu dialogue.

Why on earth would you want to do this, though? I don’t think “reverting to default” means what you think it means: if you select default, the custom settings remain stored for future reference, but are not used.