Draw file format

The Draw file specification (PRM 4-457) says that the font table within a Draw file contains a ‘textual font name’ whereas the OS routine, from RISC OS 3 onwards, to select a font for use (‘Font_FindFont’) uses a ‘font identifier’ (PRM 3-419) which can specify the font encoding as well as the font name (it can also specify a transformation matrix and territory). The Draw file definition was extended (PRM 5a-657) to include JPEG objects for RISC OS 3.60.

Netsurf exports Draw files that include both the font name and the encoding in the font descriptor (e.g. ‘Trinity\Latin1’). Thus it creates a Draw file that could not have been created in the !Draw application, where only the plain textual font names are available from the menu. However the Draw module renders it correctly.

Is this good fortune an accident or is the Draw file definition in the PRM incomplete?

Netsurf exports Draw files that include both the font name and the encoding in the font descriptor

When !Draw saves the file with draw_file_file_savedirect() it calls write_fontlist() which writes out the array of names kept in draw_fontcat.name[]. Elsewhere we see draw_fontcat.name[] is passed without any intermediate processing to font_find() which is the RISC_OSLib facade to Font_FindFont. In PRM3-428 Font_FindFont takes R1 to be a font name unless it contains back slashes in which case it’s a font identifier (which it says were not supported in RISC OS 2).

We must also check the DrawFile module, which isn’t used by !Draw the application, easily tested with *Render. A quick look at its sources in render_text() suggests it too gets the name from the string in the font table object and passes it unchanged to Font_FindFont.

Is this good fortune an accident or is the Draw file definition in the PRM incomplete?

Neither of the file’s history has changed this behaviour since Acorn started using CVS around RISC OS 3.60 time, so I think it’s just poor wording in the PRM – the Draw file font table object empirically accepts either a font name or font identifier post RISC OS 2.

Seems then that ArtWorks and Impression (which don’t accept an imported Draw file which has encoding specified) are stuck in RISC OS 2 then?

Yes, we have noticed this with ArtWorks. That’s one of the reasons RiscOSM offers a choice to generate Draw files of maps using Latin-1 instead of UTF-8.

DrawPrint also has an option to convert Unicode to Latin 1 on loading a Draw file. You have to set this choice before loading the file. It will tell you how many characters had to be dropped. You can then export the file again from DrawPrint (usually chopped up into pages) and the UTF8 encoding will disappear from the font definitions. This functionality was provided as some printer drivers don’t like the UTF8 font encoding.
The reason will be that ArtWorks and Impression are actually interpreting or rendering the Draw file themselves, whereas most applications just use the DrawFile module to render. Impression certainly predates the existence of the DrawFile_Render call, so will be rendering the objects in the file manually.

I wonder whether this would be easy for Martin and Richard to fix?

I wonder whether this would be easy for Martin and Richard to fix?

I think this depends upon how much the software interacts with the data. When I “added” UTF-8 support to Ovation (albeit currently an all-or-nothing choice), I didn’t have to do anything more than specify /EUTF8 in the encoding, and teach Ovation how to skip over UTF-8 characters with cursor key movement. As Ovation already uses embedded “invisible” codes for styles and such, this was pretty easy. Ovation passes most of the stuff on to the Font Manager, so justification, wrapping, display, etc etc all work with no further modifications.

There is, however, a caveat. I cannot make any PDFs from these documents. Why? The standard PostScript¹ driver is pooh and outputs incomprehensible rubbish when it encounters anything that looks like UTF-8. There’s a tiny bit of specialist handling for stuff like the fi/fl ligatures that have always been there; but for UTF-8 support, you might as well be asking the printer to try to parse line noise…

So, it may be better for the interim period for RiscOSM to continue to offer Latin-1 as an option. ;-)

¹ I believe the MW PS driver can do Unicode, as well as not making the horrible mess that comes of trying to print sprites…