Draw -> SVG

Interesting – I shall have to take a look at that, and how it encodes it inside the Draw files! That might need further work on !XP1Dr2SVG…

Hopefully Draw is saving the font encoding in the font table. Nothing stopping you using UTF-8 character representation in one string and good old Latin-1 in another – it should be the font encoding that distinguishes them. Got to keep you busy somehow… ;-)

8~) The reason some of these things don’t happen as quickly as I’d like is that we’ve got Good Weather here intermittently, and when we have, I’m out in the garden working there instead…a shed to get built before autumn, and stuff to get done in the shed when it’s done – bookshelves to make (new house…) and all sorts…

Hopefully Draw is saving the font encoding in the font table.

I’ve now investigated this…sadly, no it isn’t. Draw does work just fine with Alphabet set to UTF-8, but if you change alphabet back to Latin1 everything you did in UTF-8 goes haywire (in a very comprehensible way, if you understand how UTF-8 works). I can make !XP1Dr2SVG work appropriately for whatever alphabet the machine is running at the time you run !XP1Dr2SVG – but it’ll be up to the user to ensure that it’s the same as the alphabet in use when the Draw file was made.

This only affects files that contain characters other than the 95 basic ASCII ones, of course.

Oh well, I was sure I’d seen Draw font table entries of the form \E_encoding_\F_fontname_. Must have been something else (maybe DrawPlus or Vector?) that created them. There is a comment in Fireworkz about ‘old Draw (file) interpreters’ (Impression?) not liking encoding prefixes when I started adding them for the Save As Drawfile option.

Netsurf creates such Draw files ‘Trinity.Medium/ELatin1’, most other apps don’t understand them, despite them being in the Draw spec.

despite them being in the Draw spec.

Have I got an old copy of the Draw spec then? It’s very likely – are there newer PRMs somewhere? Mine’s 1992…FontTable objects are a thing, but it says nothing about encodings.

I’ve got a fairly recent !Draw (new harddisc image downloaded this year, not sure what version number, not at the Pi just now) and it is certainly only saving “Homerton.Medium” – no record of the encoding, whether Latin1 or UTF-8 was actually used during creation of the file, and whatever characters are actually present.

Just out of interest, when I’m back at the Pi, I’ll try putting encoding specs as per Chris’s example into a Draw file and see what Draw thinks about them…

Have a look at SWI Font_FindFont in those PRMs. In RISC OS 3, the font identifier was extended – part of which is still the name but can have additional information attached. I think that Draw (the app) and Drawfile (the module) just pass the font ‘name’ from the Draw file font entry to SWI Font_FindFont so could trivially render files with encodings (I have seen these, and Fireworkz produced them for a while until complained about). Note that it is a backslash! I suppose it would help if different bits of the PRMs used the same terminology.

Sadly, that doesn’t help me until Draw itself puts that information in – I’m just processing files produced by !Draw. Although I suppose if some other software is producing drawfiles that do have the information, it would be good if I could process those appropriately too – although if it’s software I don’t have that’s going to be slightly tricky (but not impossible, ideally with feedback from someone who does have such software).

!XP1Dr2SVG now not only handles top-bit-set characters in Drawfiles containing Latin1 (or Default) text, it also handles all characters in Drawfiles containing UTF-8 text. BUT it assumes that IF the computer’s alphabet is set to UTF-8, then the Drawfiles it’s processing won’t contain any top-bit-set Latin1 (or Default) characters, and vice-versa. The results otherwise may contain wrong characters, or even be undisplayable on the target software.

This is pretty inescapable since !Draw doesn’t store character set information in Drawfiles*. If anyone has Drawfiles from other software that does contain the info, if they could let me have samples I’ll consider upgrading !XP1Dr2SVG to use it. It won’t help people using !Draw, of course – they need to be consistent about which character set they’re using, or if necessary change *alphabet to match the Drawfile before running !XP1r2SVG.

The SVG files generated are now a bit more compact too, because all text in the SVG is now UTF-8, rather than using HTML entities for non-ASCII characters. Not a big saving unless you’re using a lot of non-ASCII…

I’m not thinking of extending !XP1r2SVG to handle character sets other than Latin1 (Default) or UTF-8 – could do if the demand was there, but I think I’d want to be paid for that since it’s of no particular use or interest to me. Currently other character sets are handled as though they were Latin1, producing incorrect glyphs for top-bit-set characters.

• * Er. Well…it could assume UTF-8 until it encounters something that couldn’t possibly be UTF-8, but I don’t think I can be bothered. In theory it could also interpret some top-bit-set Latin1 as UTF-8, but that’s incredibly unlikely unless someone set out to trick it deliberately.

Little bug report: if the path or name of the Draw file contains a space, then XP1Dr2SVG will crash with “Number too big (@line 2570, no: 20)”. It’s easily worked around by moving/renaming the file, but I just wanted to point it out.

Cheers, Chris! I’ll take a look at that. Not something that’s ever bitten me: I never use spaces in paths or filenames! I didn’t know they were even legal…

Very likely affects many of my little apps, when I think about how I parse these things.

I didn’t know they were even legal…

Coming from Mac OS, where spaces have been in common use forever, I often forget that they sometimes break things :)

Yeah, I mostly use Macs nowadays. I tend to use underscores instead of spaces there, because I share files with folks who are using other systems.

It will likely be a non-breaking space (160/&A0) as normal spaces are not valid in filenames.
Writable icons in save dialogue boxes do the transformation when user types a space and the validation string indicates to reject it. See https://www.riscosopen.org/forum/forums/11/topics/17516#posts-135312

I shall look at that possibility, Stuart. I didn’t think my parsing would trip up over a non-breaking space, but I’ve not looked at it for ages and I might be misremembering. Not at the Pi at present – at that Mac…

Now looked at. Stuart is right – my program would accept a breaking space happily if the WIMP actually passed it one, it’s top bit set characters it doesn’t accept. Will fix – sadly all my programs are the same, and as I don’t use a library (yet…?) that means changing them all.

(Why don’t I use a library, you might ask? I’ve never got round to working out how that fits with the way RISCOS handles applications…do you have to duplicate the library in every app, or put it somewhere RISCOS sees it when it starts, or what? I know, I know, I ought to have got my head round that yonks ago…)

do you have to duplicate the library in every app, or put it somewhere RISCOS sees it when it starts

Either. The issue isn’t really about distribution, but about avoiding duplication in your own code. Either way, you want to have a single copy of the library on your system, which you keep up to date and have included in your applications. Unless you’re going to go down the route of “building” applications², then I think you have two options.

First, you can just include the library file inside each application folder, and use

LIBRARY "<MyApp$Dir>.CliveLib"

to load it in when the main program starts. So long as you always remember to keep these up to date and in step (how you do that is up to you¹), then it’s a fairly unobtrusive approach from the end-user’s point of view.

Alternatively, you could register a resource application with ROOL (let’s say !CliveLib) and stick it in !Boot.Resources. You then distribute this as a !Boot merge update with all of your applications, and use

LIBRARY "<CliveLib$Dir>.CliveLib"

in each application to load it up. The advantage to this is that you don’t have to worry about lots of different copies of CliveLib, as your development can just use the one central copy as well. The downside is that users have to remember to install a shared resource in !Boot before using one of your apps. There’s also a risk that you inadvertently make a “breaking” change to the library, and bork any applications that a user might already have installed unless they know to update them.

¹ Worst case, you can use a tool like SideDiff to tell you what is different between different versions of the library. If it were me, I think that I’d be inclined to hold a single central version that I knew was “up to date”, copy it into an application before working on it, then copy it back afterwards so that the central copy held any fixes or changes.

² So what do I do?

I have a central set of libraries installed on my development system, in a folder that’s pointed to by the BASIC$Path system variable. I then use something like

LIBRARY "BASIC:Resources"

to load them in to each !RunImage file. However, for release I run a tool that “inlines” all of the libraries at the end of the main !RunImage file, so that what the end user gets is a snapshot of all of the libraries as they were at the time of release and all within the same BASIC file.

Because I also edit plain text versions of my software (for source control reasons), the tool that I use for this is Tokenize (and so that’s not really exactly what I do, either) – I’m not suggesting that you use it, but mentioning it for completeness as an example of how I manage the problem.

Edit PS. Before I went down the Tokenize and source control route, I used option 1 (a copy of my “WimpLib” inside each application that I released, and a manual process for keeping these all in step). When I went down the Tokenize route, I spent a few happy hours merging these back into a single version with all of the different bug fixes included… Before that, I had used Cy Booker’s BasCompress to do the inlining, but that didn’t make it off the RiscPC and into the 32-bit world.

Thanks, Steve! Will take that up…

I have a central set of libraries installed on my development system, in a folder that’s pointed to by the BASIC$Path system variable.

ISTR that was pretty much the first thing I did after implementing path variables in FileSwitch, to demonstrate their usefulness!

Fix done to !XP1Dr2SVG – it now accepts top bit set characters in paths and filenames. Fix not yet done to all my other little apps – I’ve not yet implemented libraries… 8~)

I didn’t mean to open a can of worms :)

Thanks for the fix!

Oh, it a can of worms that’s overdue for opening! Thanks Chris! Work on implementing libraries is in progress…a bigger job than it would be just to do this fix on all my apps, but it’ll improve things elsewhere, and make future site-wide fixes easier!

An interesting one if you need to do Draw → SVG on a non-RISC OS platform: https://stardot.org.uk/forums/viewtopic.php?p=405888

Ah! I have examples of Draw files using tags and using an Arial RISC OS font with eighths fractions added. I wonder how this would cope with them. Once I have a stardot account, I’ll ask.