UTF-8?

I thought we were supposed to have UTF-8 now? If we haven’t, and aren’t getting it, that’s life and I’ll work round it as best I can, but it would be nice to know what the situation is.
I’ve been looking at the fonts & countries in RC-11 on my Pi. Trinity, Homerton, Corpus and some of the fonts in ! Boot . Resources . !Fonts look just like they always did – mappable to various 1-byte encodings. The various keyboard drivers also seem to generate various 1-byte encodings which generate appropriate characters as long as you’re using a corresponding font & encoding – exactly as it always was in Acorn days.
But then we’ve got potentially all-singing, all-dancing (well, almost all-…) fonts like FreeMono, FreeSans & FreeSerif – but afaics, no way of accessing most of the characters in them.
I’ve got several fonts almost ready to roll out – and an app to help with font design if anyone’s interested, designed to be used alongside !FontEd (some of you might remember !Fontician, that I published in Acorn User many years ago – based on that, but much improved) – but I’d like to know whether I should simply fit in with the way things have always worked, or try to fit in with the way things don’t seem to be working yet but hopefully might some day…
Is anything happening on this front? Has anything happened in this area between RC-11 & RC-12? Should I update? (I’m slightly reluctant to, since RC-11 seems pretty stable for everything I’ve done with it so far.)

I’m not certain exactly what you’re asking about, but RISC OS does support fonts with a wide Unicode coverage, and some applications support Unicode too.

You can convert a font with wide Unicode coverage to a RISC OS font with ttf2f and apps like NetSurf can use them.

I hesitate to chip in here, given that I’m unlikely to have time to work on it for the next month or so, but I have been working on a Unicode Chars for ages. This would at least allow you to see the contents of a UTF-8 encoding, and (if your desktop alphabet is set to UTF8) transmit the multi-byte character code to any application that can deal with it. It’s a long way from being finished.

AFAIK, the OS’s support for Unicode is best described as partial. The facilities for handling UTF-8 fonts are there, but very few applications, including the Window Manager itself, currently make use of them. The main exception to this is (I think) NetSurf, which has very good Unicode support. An updated Chars would be a first step towards improving the OS-wide situation, followed by Unicode versions of the Resources used by the Wimp, etc. Then apps such as Edit would need to be updated. I don’t think there’s any change in this regard between RC11 and RC12.

Someone who knows more about this may come along and correct all this, of course :)

Hmm. I’ve now set my desktop alphabet to UTF-8 – and indeed, my keyboard is now generating UTF-8 (using Alt-xxxx where xxxx is entered on the numeric keypad). Further investigation required!
But if I set Country Russian & hit (left)Alt-Shift to select the Russian layer, I don’t get UTF-8 codes for Russian, I get 8-bit codes that map into an 8-bit code page with Cyrillic in the top-bit-set area 8~( – likewise with Country Greece – except that that doesn’t have a layered keyboard, you can only access the Latin alphabet by holding (either) Alt key down…
The consequence of this is that if I then use a font with wide Unicode coverage (basically FreeXXXX of those in RC-11) I don’t get the Russian or Greek characters, I get assorted accented Latin characters instead – but I can get the right characters by choosing a suitable font.

Presumably what I really need here is a UTF-8 Russian keyboard driver, to generate the correct UTF-8 codes for my Cyrillic characters, and get them from one of those wide-coverage fonts. I’d like to make my own fonts wide-coverage & UTF-8 encoded rather than old-style.

I’d like to be able to write my own keyboard drivers, too – specifically to generate the appropriate UTF-8 for Hindi, but given the facility to write them I’d write Russian and Greek UTF-8 drivers too. (I used to write keyboard drivers using !IKHG, but can’t do that any more…)

Okay – I’m getting the picture. I can see that RISCOS itself does indeed have good Unicode support, and that it’s in the apps (and keyboard drivers) that the limitations lie. When I say the limitations lie in the keyboard drivers, that’s at least equally true in the PC world (and for all I know, perhaps in the Mac world too). Entering obscure Alt-nnnn sequences into a numeric keypad is no way to type foreign languages – I want to touch type Hindi, Russian and Greek, which I can on my Risc PCs – but only using customized keyboard handlers and fonts.

Perhaps I should explain where I’m coming from. Mostly I use PCs nowadays, having learnt to use them producing documentation at ARM of all places! Before moving to ARM, I ran an office publishing prestigious academic journals on Risc PCs (initially, A5000s and A540s).

I’ve still got a couple of StrongARM Risc PCs (with 66 MB RAM each, and various hard drives up to 6GB). I still find !FontEd together with my own !XP1FontEd far better for designing fonts than anything affordable (or indeed anything unaffordable that I’ve seen) on the PC, and !Draw far better for precise vector graphics. I’m in process of writing an app to convert drawfiles into something I can import in vector form into OpenOffice – currently I convert them to bit images (jpegs), which is less than ideal. I’ve extended !XP1FontEd to be able to convert RiscOS fonts into SFD (Spline Font Database) files, which I can import into FontForge on the PC and thence to TrueType or PostScript. (Acorn User published an earlier version of !XP1FontEd, then called !Fontician, but XP1 is my allocation. XP for XenoPhilia.)

I’ve now got a Raspberry Pi running RISC OS, and love it – but am frustrated that my customized keyboard handlers don’t work on it, and that it’s not obvious how to make keyboard handlers other than by a sledgehammer technique, which for one thing would be a lot of work, and for another, wouldn’t result in something fit to offer to anyone else. If I can make kosher fonts & keyboard drivers, I’ll be very happy to release them into the wild.

I think I can now see how to make kosher fonts, which will work either the way Trinity, Homerton etc. work OR the way FreeMono, FreeSans and FreeSerif work. But keyboard drivers still elude me.

!XP1FontEd is almost ready to release into the wild – a bit of tidying up and a help file and it’s there.

Hi Clive, Im confused here. Doesn’t “Artworks > Export > PDF” or print from Draw to PDF and then open that in OO/LO work well?

I don’t have Artworks , but anyway, importing PDF into OO doesn’t bring it in in editable form afaics. Actually, I don’t even have any printer drivers on my Pi. Save → PostScript Print is greyed out in Draw. Where would I get a Postscript printer driver from, to at least give that a try?

Not that I’m scared of writing my own drawfile→OODraw conversion app anyway…other folks might even find it useful too…

Yes PDF into OO/LO Drawing or text document is editable. You can also go into Inkscape to Edit.

The HardDisc download from this site includes !Printers and has various modules including PS but a PS3 driver is available from Martin – http://www.mw-software.com/software/ps3/ps3.html

Steve Fryatt has !PrintPDF which is a free add-on for !Printers and uses GhostScript to produce PDFs from any application that prints. www.stevefryatt.org.uk/software or from the Plingstore

The Draw > OO extension would be very useful and I’m not trying to dissuade you in any way :-)

HTH

TDH indeed! 8~) Thanks! Will now investigate those downloads too.

Would !KeyMap be of some help to you, if only temporary?

No, not really. I did take a look at that. At the moment, I’m doing fine using the Risc PCs, but I’d like to get everything working in a more standard fashion on the Pi eventually. The Russian and Greek work on the Pi in the old non-standard way, and I could even make the Hindi work in a new non-standard way on the Pi, using the Russian or Greek keyboard layouts and a new non-standard reorganization of the font! But as long as the Risc PCs live on, there’s not much point. I want to be able to write keyboard handlers – I have Armenian friends who’d like an Armenian keyboard handler, too – I can manage the fonts, no problem (actually, I think FreeMono, -Sans and -Serif already have it – they’ve certainly got Cyrillic, Greek and Hindi, albeit not my preferred typeface).

Hmm. Firstly, I feel pretty stupid – RC-11 contains !PrintPDF already, I’d just forgotten too much RiscOS in the fifteen years since I used it for anything other than a very restricted set of functions. Forgot to find and start !Printers (and !PrintPDF). Can now produce PDFs from !Draw, nae bother.

However – while Adobe Reader can display the drawing okay, OpenOffice refuses to open it as anything but a text file (and yes, I’ve got the filetype correct – that’s why Reader displays it). Thanks, OO, I know what PDF looks like inside – but I want the picture, not gobbledegook text. And Adobe Reader won’t save it as anything useful. Trying the Gimp now…but am feeling more and more like getting on with that Draw→OO app…

http://www.comp.lancs.ac.uk/~ss/software/pkg-draw2svg ?

However – while Adobe Reader can display the drawing okay, OpenOffice refuses to open it as anything but a text file (and yes, I’ve got the filetype correct – that’s why Reader displays it).

I’ve seen¹ PDF files that AR will display but other readers produce total rubbish on screen². I think it’s a peculiarity of the PDF file format used.
If the problem is a PDF format issue !PrintPDF might need a small bit of work.

Possible fix:
Install CutePDF, load the file in Adobe Reader, print to a new file using the CutePDF “printer” then try loading the PDF in OpenOffice.

¹ IT support work, you see all sorts of unusual “features”
² Output from AutoCAD among others.

Looking carefully at OpenOffice (and I’ve got the most recent version installed on my PC) it doesn’t appear to support PDF import at all. Export, yes, but not import. A long list of things it can import, including EPS. Also DXF, which is probably the easiest one to produce from a drawfile.

Looking carefully at OpenOffice (and I’ve got the most recent version installed on my PC) it doesn’t appear to support PDF import at all.

LibreOffice – where OO went when Oracle started being their usual selves¹
PDF import is in the feature list.

¹ Struggling for a polite description that really describes their attitude/behaviour.

Aha! Taking a look at that now…many thanks (I think…hope…will let you know!)

Looking good! 8~)

Um. Not sure whether I’m doing something wrong here. I’ve set PrintPDF→Choices→Optimization to Colour, but I’m losing the colour out of drawfiles somewhere on the way anyway – possibly at the drawfile→Postscript stage? Also, line patterns (dashed lines) in drawfiles aren’t rendered properly – they’re all the same pattern, with VERY short dashes. Whether that’s Draw→Postscript, Postscript→PDF, or an inherent disability in PS or PDF, I’ve no idea.
Otherwise, still looking pretty good – it’ll do fine for most drawings. I can see the line patterns being quite a headache in a drawfile→LO converter, too…

Another method I have found useful is to use !MultiTask (version 7.2). If you set up the Postscript 3 print driver, you will find that it creates a file ‘postscript/ps’ in the location you specify. Simply drag this file to the open !MultiTask window (so that it knows where to look for it), then drag a draw file onto the same window (so it knows where your draw files are held). If you then export the icon from the window onto the postscript printer driver icon on the icon bar (so it knows where to send each draw file), then each draw file in that directory will be sent, in turn, to the postscript 3 printer driver (which turns them into a postscript file) and they will (again, each in turn) be turned into a pdf file via Ghostscript before the next draw file is sent to the printer driver.

This creates a pdf file for each draw file, with the same name but with a ‘/pdf’ extension and file type.

The postscript 3 printer driver has an option ‘colour’ which can be ticked or unticked. This decides whether colour is included.

I find this method much quicker than creating PDFs using ArtWorks and it will happily process hundreds of draw files with no attention needed from the user.

I don’t have ArtWorks. I used to have it at work, but found Draw better for the kind of work I want to do. Draw does everything I want beautifully, and PrintPDF works straight from Draw, no problem.

Does that colour option actually work? There’s a colour option on PrintPDF too, but I’ve still lost the colour somewhere.

For the method I describe, ArtWorks is not required. I found PrintPDF unhelpful when processing lots of draw files in a batch.

I found that with the colour option (in the postscript 3 printer driver) unticked, some jpegs (embedded in draw files) would still appear in colour but otherwise it seemed to work OK.

That’s the £35 printer driver?

Now I feel a bit silly – and highly amused. I’d ticked “colour” in PrintPDF, but not in the PostScript printer driver. So now I have colour, and am feeling silly.

But the fill colours are completely bonkers – bear no relation to the colours in Draw. Hence highly amused. Black and white are fine, but shades of grey are shades of pink, dark green is orange…etc. – and line colours are okay.

Strangely, the line patterns in Draw are now correct. Very, very odd.