!Printers

Hello All I would like to make improvements to !Printers front end but I have a dilemma which version to use as a base, either RISC OS 5 version of !Printers when released or ROL’s Printers+. Ideally I would like to merge the RO5 !Printers with !Printers+. As I understand it this is not possible if RO5 !Printers is released under the Castle licence. Would it be possible to release just this one thing under the same Mozilla Public License as !Printers+ or something similar.

I don’t see why not. Since they bought RISC OS from Pace, !Printers has always been Castle’s property, as far as I’m aware. I’m pretty sure that the release of the sources to Printers+ was a flagrant breach of copyright. As it has happened now, there isn’t too much that can be done.

We do plan to release the sources to the printer stack under the Castle license. I’m sure the two works can and should be merged.

Printers+ is licenced under the Mozilla Public Licence. Is that compatible with the Castle Licence? If not, maybe someone could approach the current owners of the new code in it. IIRC David Marsten passed away a few years ago, so that would probably be his wife or children.

Following the recent thread on c.s.a. misc ‘Re: Risc Os Now’ where the issue of postscript output was extensively aired, I’d like to enter a plea for revision of the Acorn Postscript printer driver to be added to the wish list. At present the Acorn PS driver is incapable of writing a file which preserves CMYK data. The only way to do so from a dtp app is to generate CMYK separations, but these are not satisfactory either as they can only deal with 256 colour sprites. The combination of RISC OS and existing dtp apps such as Ovation Pro or Impression Publisher would otherwise be highly suitable for use in the professional graphics arena.

At present the Acorn PS driver is incapable of writing a file which preserves CMYK data.

Not entirely true. Vantage shipped with a version of PDriverPS which did offer a CMYK route (see “Use CMYK hook” in V’s config). The wheeze was to use ColourTrans_ConvertCMYKToRGB – PDriverPS then remembered the CMYK input and RGB result, and treated the subsequent ColourTrans_SetColour as though it were ColourTrans_SetCMYK. Though the implementation didn’t allow up-to-256 colour sprite palettes, it would have been simple to extend.

I also supported CMYK sprites and completely rewrote mask handling (such that the mask gets auto-traced by PDriverPS into a clipping path). However, changing the API doesn’t magically cause the aforementioned programs to output CMYK! The way we have always produced composite PDFs is to output separations (with clipped masked sprites instead of the awful Acorn imagemask method) and then recombine them in Acrobat using Creo’s Seps2Comp (which is no longer available :-[ )

However, nobody in their right mind would use RISC OS software in the “professional graphics arena” without a really good excuse. Note in particular that the concept of outputting device-specific colour (CMYK) is now rather outdated in the era of ICC and WCS - especially when one considers the prevalence of output devices with exotic ink sets, far beyond good old CMYK.