Draw -> SVG

I could give the self-extraction file its filetype if I was uploading it to my website from RISCOS, but I don’t have any direct way of doing that. I transfer it from the Pi to the Mac to upload to my website. Same problem exactly with the Archive file generated by InfoZip.

What are you trying to do?

If you’re concerned about filetypes inside the Zip archive, then zip them up using InfoZip on RISC OS and it will include the necessary metadata inside the archive. That’s all there is to it.

If you’re concerned about identifying the archive as being a Zip file, then that’s irrelevant to any RISC OS filetype. Production webservers will almost certainly know nothing of RISC OS filetypes, and will deal in MIME types¹. The MIME type will be assigned on the server, using some means of inspecting the file: either looking at it’s .zip extension on the filename, or sniffing the contents. Either way, there’s no reliance on preserving the type from when the file was created on the RISC OS machine.

ETA: So just make sure that the filename ends in .zip as Stuart says, and it should be fine. You should be doing this anyway.

¹ RISC OS then converts these back into RISC OS filetypes when files are downloaded by using MimeMap.

If you’re concerned about filetypes inside the Zip archive

No, that’s obviously fine, either in the self-extracting files I’ve been using all these years, or in the archive files generated by InfoZip.

Production webservers will almost certainly know nothing of RISC OS filetypes, and will deal in MIME types…there’s no reliance on preserving the type from when the file was created on the RISC OS machine.

Well, yes, that’s been my problem.

So just make sure that the filename ends in .zip. You should be doing this anyway.

Not for those self-extraction files, which have to be type ffc in RISCOS world. But thanks, yes, that’s straightforward enough for the InfoZip files.

Well, yes, that’s been my problem.

Not just the server. You could patch in a Mime type if you have the privs, or sweet talk admin. But it would be useless without a corresponding entry in the mime mapping of everybody who visits.

Far better to just use zip, everything knows what that is.

which have to be type ffc in RISCOS world.

Whoever thought that was a good idea?

FFC is a utility. Which is loaded into the RMA (so it can exist without messing with the currently active application).

But… to use a utility for a self extracting archive? You see the problem, right?

By the way, if you have something to deal with archives programmatically, you can do similar with the read/write version of SparkFS.

Create an archive (there’s a command to do that), then copy files into it (it’s an image filing system, so regular copy will work). Not that you cannot rename.

Manual and extra info here: https://www.davidpilling.com/wiki/index.php/SparkFS

Not for those self-extraction files, which have to be type ffc in RISCOS world.

That’s another reason why self-extracting archives as downloads from the internet are a bad idea…

We’re going in circles here. I know very well what you can do with the read/write version of SparkFS, I used to do that when I worked at Physiology – over 30 years ago. But I personally don’t have a copy of the read/write version, and the self-extraction files produced by !CreateSEC work, so why should I have bothered? But now I’ve been introduced to InfoZip I can make proper archive files again, so I’ll do that.

Thanks for the help (pointing me at InfoZip and how to ensure the resulting files are typed correctly on arrival back in RISCOS). No thanks for the patronizing tones…and that’s not aimed at everybody, not everybody does it…I’ve got a fairly thick skin, but I can easily imagine plenty of people getting driven away…

the self-extraction files produced by !CreateSEC work, so why should I have bothered?

Because self-extracting archives are an utter pain in the fundament for your potential users.

There’s the obvious fact that most web servers will know that a file ending with .zip should be given an application/zip MIME type, but won’t have a clue what to do with an SEA and so will leave the user with an extra step of setting the RISC OS type correctly before executing it.

In addition, though, they’re just user-hostile. I download, and make a note of the announcements of, most free software releases¹ that I’m aware of², and yours are a nuisance to deal with because of the SEAs. I can’t open them on Linux to read the documentation, which I frequently do with things in Zip files, and there’s that extra stage of filetyping which needs to be done before they can be used or squirrelled away in storage for a rainy day. And if I don’t do that filetyping stage on RISC OS first, so that MimeType can generate a valid MIME type for them, then the squirreled files end up with the wrong MIME type attached to them in my software archive. In contrast, a Zip file “just works”, whether on the RISC OS or Linux side.

¹ I used to need to know for writing the Archive PD Column. These days, it’s useful to have a list of new stuff to write about for when there’s a page or so of The WROCC which needs filled.

² It’s surprising how much stuff gets released or updated with no announcement anywhere. If people don’t know that new versions of things exist, then they can’t download them!

That’s another reason

It’s the reason so far as I’m concerned…but in the absence, now cured, of an alternative, it works…

so will leave the user with an extra step of setting the RISC OS type correctly before executing it

Oh dear. What a terrible hassle. But the problem is now solved, thanks to Stuart.

As for the documentation, it’s there in HTML before you even get to the download.

There’s the obvious fact that most web servers will know that a file ending with .zip should be given an application/zip MIME type,

Indeed. Lovely. Once one has software capable of making the .zip file. Thanks Stuart, for the link to InfoZip. And how to get the filetype right.

As I wrote, NO THANKS for all the patronizing RUBBISH from someone else.

All done now, E&OE. All my little apps are now .zip files, not self-extracting ones. Any problems, do let me know.

http://clive.semmens.org.uk/RISCOS/RISCOS.html

What a terrible hassle.

It is if it requires the RISC OS machine to be powered up in order to do it, compared to remaining entirely on the “other” side for the process of reading the release notes! My internet usage is almost 100% Linux or Android these days, because it’s so much easier; Zip archives containing text, PDF or HTML documentation (which is most modern RISC OS stuff in my experience) can be understood just fine on that platform.

As I wrote, NO THANKS for all the patronizing RUBBISH from someone else.

Sorry if highlighting my experience as a user of your software was unwelcome. :-(

All my little apps are now .zip files, not self-extracting ones.

Thanks! I’ll take a look.

Any problems, do let me know.

Are you sure? Your responses up-thread suggest that doing so might be unwelcome?

compared to remaining entirely on the “other” side for the process of reading the release notes!

I’ll just quietly throw in that I do more or less the same thing on my (Android) phone.
It’s pretty much my portal to the online world these days, not any desktop machine.

Sorry if highlighting my experience as a user of your software was unwelcome. :-(

Tone & heavyhandedness, not the fact of mentioning your experiences. As I say, I’ve got a thick skin – but not everyone has! I had the distinct impression you’d not followed the thread up to that point, so didn’t realize the situation. To see the download link, you must have been looking at the HTML file the links are in; all the documentation is there in the HTML file you got the link from.

I’ll just quietly throw in that I do more or less the same thing on my (Android) phone.

Likewise – there’s nothing but RISCOS software in the download that wasn’t in the html file you got the link to the download from.

Someone probably tried to get the Dings font – it’s now a .zip file, which (sorry) it wasn’t in the first iteration of this process!

If you’re installing RISC-OS for the first time you need a self extracting zip program in the first place, otherwise you can not really install anything else. Once the self extracting zip application is extracted and installed you’re good to complete your setup, install more applications from zip files. At that point the user might download Clive’s excellent software to complete their setup.

I have a vague recollection of self extracting programs on other platforms been able to be opened by winrar, windows cab files too if that’s relevant? Are RISC-OS self extracting files special and can’t be opened with winrar, zip, 7zip et al? Can’t sparkplug or something else create self extracting zip files that can be opened on other OSes or run and opened in Sparkplug on RISC-OS? Dunno it’s late.

If you’re installing RISC-OS for the first time you need a self extracting zip program in the first place, otherwise you can not really install anything else.

SparkFS has been included in the base disc image for many years, so everyone ‘should’ have it. The image itself is available in both Zip and self-extracting versions.

download Clive’s excellent software to complete their setup.

Falls about laughing – that’s very kind, but (a) a bit over-complimentary, and (b) while for some purposes I find (or at one time found) some of it useful and think some others sometimes might, it’s only a few odd utilities, they don’t “complete” anything. They’re a very minor addition to a massive pile of far more important stuff that’s already in the distribution or out there elsewhere.

I have a vague recollection of self extracting programs on other platforms been able to be opened by winrar

That trick – and I think programs other than winrar could do it – involved looking for the “Windows executable” marker (“MZ”) at the start of the file, searching for a “start of archive” marker (e.g. “PK” for a .zip file) further into the file and trying to unpack from that point.

Can’t sparkplug or something else create self extracting zip files that can be opened on other OSes or run and opened in Sparkplug on RISC-OS?

The problem as far as RISC OS is concerned is that “MZ” at the start of the file would almost certainly prevent it from working as a RISC OS executable.

As for opening self-extracting files, SparkFS can be persuaded to unpack a file where the start-of-archive marker isn’t at the beginning of the file, but it needs to be told the exact offset (it won’t search for a marker an indeterminate distance into the file).

Are RISC-OS self extracting files special and can’t be opened with winrar, zip, 7zip et al?

AFAIK, there is no RISC OS self-extracting-archives-creation-tool that uses a “standard” ZIP format inside. It is usually Squash or LZW-reinvented-one-more-time or things like that.

Most of the older creation tools of course emitted 26bit-only code (in one instance, it was even RISC OS 2-only code), which makes another big disadvantage of self-extracting archives evident. It would be different if RISC OS provided support on system level, but that never happened.

there is no RISC OS self-extracting-archives-creation-tool that uses a “standard” ZIP format inside.

What Steffen said, basically.

As said above, x86 self extracting zip files work because it’s just a short EXE with a normal zip file pasted into the end, so if the usual header isn’t found then one just needs to whizz through to find the start of the archive. Said archives may work on other machines for the same reason, depends if one scans for the zip header.

Under RISC OS, in order to keep file sizes down it’s typical that it’ll be a simple executable that makes use of the Squash module. So a custom way of handling LZW compressed data, because without looking at the source you can’t even determine how the data is laid out, and this could vary from one unpacker to the next.

I just downloaded the self-expanding SparkFS and looked at it in a hex editor on my phone, and the first string I saw was Expected non-zero squash decompress buffer size.

It would be different if RISC OS provided support on system level, but that never happened.

They came oh-so-close with Squash files, but never saw it through. So Squash ended up being a way to compress and decompress single files, rather than any sort of archive format. For that (which squash can do), everybody rolls their own code.

And as you noted, some are 26 bit only, some are RISC OS 2 only, and…. <sigh>

AFAIK, there is no RISC OS self-extracting-archives-creation-tool that uses a “standard” ZIP format inside.

unzip available via PackMan contains the unzipsfx executable. This just needs prepending to a zip file to create a self-extracting zipfile.

unzip available via PackMan contains the unzipsfx executable. This just needs prepending to a zip file to create a self-extracting zipfile.

I remember trying that out a few years (decades?) ago, and it didn’t work for my (back then) most important use case: self-extraction on a naked RISC OS 3.1 system. Have to check again.

It has been drawn to my attention that !XP1Dr2SVG doesn’t handle some (possibly all) top-bit-set characters in text. This is an easily solved problem and the updated app should appear on my website shortly – will report when it does.

There are other issues with text in DrawFiles exporting to SVG, as mentioned in the introductory blurb and the help file – but they’re fairly obscure, and fairly unavoidable due to fundamental differences between the way Draw and SVG work. They can be avoided, totally, by converting your text to paths in Draw before conversion, but that does make for BIG files! If you stick to Trinity (becomes Times), Homerton (becomes Arial) or Corpus (becomes Courier), with or without rotation OR changed aspect ratio BUT NOT BOTH, changes will be very slight.

!XP1Dr2SVG now updated to handle top-bit-set characters – hopefully correctly! DO let me know if any problems…

Incidentally, I’ve possibly not got the latest version of !Draw – does it still only handle the “default” character set, unable to use the additional characters in the much bigger fonts?

does it still only handle the “default” character set, unable to use the additional characters in the much bigger fonts?

Try *Alphabet UTF8 and select a font in Draw that has Unicode encodings. Menus are a mess, but it works.