UTF-8?

UTF-8?

Yup. It does seem to have wandered off topic a bit! :)

That’s the £35 printer driver?

Yes. To quote:
The PostScript 3 printer driver is a joint project by John Tytgat and Martin Würthner. It offers significantly improved PostScript output quality from RISC OS applications, most notably for text and bitmap images. This includes both printing to a physical PostScript printer and using the PostScript driver for PDF generation, e.g., from OvationPro, Impression or EasiWriter.

Since I don’t actually want PDF – it’s just one possible route to transfer vector graphics from Draw (my preferred vector drawing package) into OpenOffice (my preferred publishing package, probably now LibreOffice) – that’s a bit OTT. I’ll write my drawfile→LO conversion app if I ever need colour, but I don’t actually foresee such a need anyway. I only happened to notice the problems with colour because I considered making a PDF of the reference card for my !ReDraw app, but a drawfile is fine for that really, since any user would obviously be using Draw.

some jpegs (embedded in draw files) would still appear in colour but otherwise it seemed to work OK.

AIUI Postscript 2 & 3 transfers JPEGs within pages as JPEGS the receiving device then decides whether to print in colour or not. I remember the first time we printed to a Colour laser a document with jpegs, the driver was set to monochrome but the photos were printed in Colour! I think we may have been able to set the printers defaults to monochrome.
Martin Wurthner/John Tytgat’s PostScript 3 driver may be able to set Monochrome printing of JPEGs

Very helpful, thanks. I’ll probably have to set the jpegs to greyscale before importing them – the PDF master is sent to a printer that assumes any pages that contain colour should be printed in colour (at extra cost).

I’d ticked “colour” in PrintPDF, but not in the PostScript printer driver.

I wasn’t aware that PrintPDF had an option to control the use of colour or black and white?

I found PrintPDF unhelpful when processing lots of draw files in a batch.

PrintPDF has a queue to allow a batch of files to be collected together and turned into a single PDF. I’ve considered adding an option to make it divert all incoming PDF print jobs into the queue without the need to use the dialogue box for each one, but since no-one’s actually requested such a thing I’ve assumed that there’s no demand…

AIUI Postscript 2 & 3 transfers JPEGs within pages as JPEGS the receiving device then decides whether to print in colour or not. I remember the first time we printed to a Colour laser a document with jpegs, the driver was set to monochrome but the photos were printed in Colour!

Is that not more to do with the fact that publishing-oriented software tends to bypass the drivers for images and write them direct to the PS output file due to the well-documented problems with Acorn’s PS2 implementation?

UTF-8?

Not that I mind wandering off topic that much, but I’m extremely interested in UTF-8 development on RISC OS.

I wasn’t aware that PrintPDF had an option to control the use of colour or black and white?

Presumably you are now? PrintPDF→Choices→Optimization→Custom→Custom and there it is – along with resolution & compression control.

I’m extremely interested in UTF-8 development on RISC OS.

Me too. Am slowly getting to grips with what there is. The OS itself is agnostic about it, it seems; some apps understand it and others don’t; and only one keyboard handler (as far as I’ve seen so far) actually generates it, and that in a ham-fisted, PC-like way. Writing keyboard handlers, which used to be easy with !IKHG (but it could only do 8-bit key codes), is now obscure (to me, so far) – I could write a complete keyboard driver, but that’s a bit of a steamhammer solution if the handler can be a separate piece of code (or even a table consulted by the driver).

I wasn’t aware that PrintPDF had an option to control the use of colour or black and white?

Presumably you are now? PrintPDF→Choices→Optimization→Custom→Custom and there it is — along with resolution & compression control.

You might want to check who wrote PrintPDF… :-)

None of those options control the use (or otherwise) of colour in a document: the only way to do that is via Printers. What they do do is allow you to selectively apply compression and/or downsampling to colour, greyscale and monochrome images as they pass through Ghostscript.

8~) Steve: I did wonder, by what you’d said / the way you said it! The radio button confused me…but the logic is indeed clear when I think about it.

However, since you’re presumably well up in this area – any idea why fill colours in a Drawfile go all wonky in the PDF, whereas the line colours are fine? Although I suspect that’s more likely Printers than PrintPDF?

Chris: I’d have though an up to date system should be able to suppress colour. I can’t believe it’s not a common situation.

any idea why fill colours in a Drawfile go all wonky in the PDF, whereas the line colours are fine?

If you import a draw file into ArtWorks, then the line colours [other than the 16 standard draw colours] are (not necessarily exactly as specified in the options – another bug) given named spot colours in CMYK colour space but with K=0 (a bug) whereas fill colours are treated differently (not sure why). Line colours can then be edited globally (so that you can go to RGB then back to CMYK to get the K setting correct to avoid ink saturation). The PDF file then exactly reproduces the ArtWorks file in terms of colours.

Does this help?

I don’t have Artworks, and ideally wouldn’t want an extra stage in the processing if I did.

I was only using the 16 standard Draw colours, and was very puzzled why the fill and line colours were treated differently. But if there’s no straightforward way of getting the existing software to do the translation properly, I’ll write my own and be done with it – if I ever decide I want to use colour in vector drawings. Thus far all my serious colour work is with bit images, for which I’m using the PC; all my vector drawing work at present is monochrome anyway. I do use colour in !Draw, but only for subsequent processing in my !XP1ReDraw app, which converts colours & greys into line patterns or hatchings. It was only running the reference card for !XP1ReDraw through the process to make PDFs that alerted me to the colour issue!

UTF-8

Ahem.

Some may be interested to know that (before I got bored/disillusioned/sane) I was working on getting UTF-8 working outside the desktop. I mostly succeeded. The hard work isn’t so much the code as the font.

Although I’ve done no RO development this year, I still sometimes work on the UTF-8 BFont. It’s currently up to 4440 characters, which is somewhat more than was necessary as a proof of concept. I must have taken it seriously.

The funnest bit of the coding (and probably very few will understand why) was getting cursor-key copying working. Oh yes, I rock.

Anyway, lots of characters in the editor: Clicky

Lots of characters outside the desktop: Clicky (blue and red is debug info for cached/missing respectively)

@nemo: what does white mean? … both the images (when displayed in Firefox) show absolutely nothing here!

Nor my iPad. Drop the pics on imgur?

I think if there’s UTF-8 outside of the desktop, we’d probably be able to one-up most other operating systems…. ;-)

what does white mean? … both the images (when displayed in Firefox) show absolutely nothing here!

Well in the case of the first link it probably means that we don’t have access to nemos google drive referenced in the linked page or the specific file / directory.

Some may be interested to know that (before I got bored/disillusioned/sane) I was working on getting UTF-8 working outside the desktop. I mostly succeeded. The hard work isn’t so much the code as the font.

Don’t let your work go to waste. We’d all like to see it – and, dare I say it, some of us would even find it useful!

Oh for crying out loud Google Drive, what now? No one can see any files at all, but what I see is this:

How is that even possible?

Anyway, seems to be fixed now. Unfortunately it’s not possible to link Drive contents directly (unlike Twitter pics above… people can see that right?).

I think if there’s UTF-8 outside of the desktop, we’d probably be able to one-up most other operating systems…

It’s funny you should say that, but recently I had to investigate Windows’ Console Unicode behaviour with the command-line version of a major multiplatform application.

In short, under some circumstances text was being transcoded three times from Unicode through two different 8bit codepages and finally back to UCS16, resulting in a repertoire of about 100 characters! (the common subset)

It turns out that there is no portable way of outputting Unicode from a command-line program under Windows. None. Can’t be done. You have to use Windows API calls. I was able to state quite sincerely that (my version of) RISC OS did a better job. Linux of course has no problem at all.