Impression-X

Download !Style from !Store for free and you will find that it contains both a tutorial and a newsletter.

OK…
Is it possible to print an Impression document from the command line, an obey file, or a BASIC program? Alternatively, is this possible on Windows with the Ovation Pro Reader?

The reason for my question: I’ve been contacted by someone who inherited their father’s RISC OS computer, and they would like me to convert all of his Impression documents to PDF. The problem is, there are several thousands of documents so manual conversion is not feasible. I want to build a script or program that traverses all directories and prints all Impression documents to PDF.

Is it possible to print an Impression document from the command line, an obey file, or a BASIC program?

Not really…

It is possible to invoke a print from a command line (the PrintType file action), however the actual printing process works in the desktop. If using Steve’s PrintPDF, it will print to a temporary file as PostScript, which PrintPDF will pick up. PrintPDF will then ask you what filename you’d like to give the file (as well as other options, if you want).

I can’t imagine this running outside of the desktop (like, from an Obey file) and without user interaction…

Alternatively, is this possible on Windows with the Ovation Pro Reader?

The times I’ve created PDFs from Ovation files on Windows, it was basically the same sort of deal. This stuff is set up to be helpful for doing “print this as a PDF”, but it’s not so well designed for “print a thousand things to PDF”.

On Windows you can use AutoIt
https://www.autoitscript.com/site/

Arjan asked

Is it possible…

Impression does set an Alias$@PrintType that allows !Printers to print Impression documents that are “dragged” to its icon (in other words, sent as a DataLoad). So really your question becomes “is there a way of printing thousands of things to file without !Printers continuously overwriting the same output file?”.

Although it’s easy to drag hundreds of files to !Printers and let it print them, the tricky bit is changing the output filename between each print. And ideally you would want the resulting output file to have the same leafname that the input document had. Note that none of this is specific to printing to PDF – it applies to any type of printer that can print to file… which is all of them.

Now you might hope that there was a nice protocol¹ that !Printers (and/or PDriver) uses to inform the system that printing is happening… but there isn’t. So what your program will have to do is:

For each file to convert:

• Set Printer$Path to the destination filename
• Send the source file to !Printers via DataLoad
• Wait for the “Printer:” file to appear
• Wait for the “Printer:” file to be closed and/or monitor PDriver_CurrentJob
• Repeat for the next file

¹ The nearest that exists is the PrintSave message, which should result in a PrintError message if the printer is still “busy”, but I’m unconvinced by that as I suspect !Printers may queue files anyway. There is a difference between the printer being busy and PDriver having a current job.

I’m not sure what happens if multiple files are dropped on to a PrintPDF printer. If it doesn’t offer a way of automatically naming the files and continuing may be it could be modified? !PrintPDF is still currently being maintained.

I’m not sure if this is helpful, but it is something that’s in my head and I figure I should write it down…

One of the features of our LPR driver (network printer drivers) is that it queues multiple jobs and background spools them to the printer. I suspect other print spooler programs may do that too, I don’t quite know.

Anyway, if you were to set the LPR address as a non-existant address, it’ll queue them up in the Scrap folder, but not send anything. This will give you a set of uniquely named Postscript files which can be batch-converted with Ghostscript (ps2pdf). Alternatively, you could probably even set up an LPR server to do that on a Linux box or something.

As I say, I don’t know if it is helpful (it isn’t a complete solution), but it does provide a way of creating a set of unique named printjobs from a set of source files.

I think the benefit of having a print output leafname matching the input leafname should be obvious when converting “several thousand” files, and really one would want the output near or next to the input. ie $.Long.File.Name.Document → $.Long.File.Name.DocumentPDF

I’m not sure what happens if multiple files are dropped on to a PrintPDF printer.

Interesting things, it seems.

Fundamentally it works¹, but unless PrintPDF spots the pause between files, each postscript file from the printing system just overwrites the previous one before PrintPDF can queue it up for processing. PrintPDF is doing the checking on NULL polls using Wimp_PollIdle; I’m not sure if there’s a better way.

For the files that it does catch and queue, it then offers a save dialogue for each in turn.

If it doesn’t offer a way of automatically naming the files and continuing may be it could be modified?

I think the benefit of having a print output leafname matching the input leafname should be obvious when converting “several thousand” files, and really one would want the output near or next to the input. ie $.Long.File.Name.Document → $.Long.File.Name.DocumentPDF

Yes, but… as far as I’m aware, anything doing the trick that PrintPDF does² can’t see the original filename. The files arrive as the output from the printing system (so printout/ps or whatever is configured in Printers), and get shuffled away into a queue by PrintPDF as soon as it realises that the printing has finished³. Applications don’t have to tell the printing system what the original filename of the file being printed out was, as far as I know, so by the time PrintPDF gets the file, the original filename is long gone.

Otherwise, PrintPDF could very easily be made to pass each file to GhostScript on the default settings… I think.

¹ Ovation Pro just prints each file in the batch in turn, using the saved settings for that file and the current paper size configured for the printer. This would mean that you would have to grade the files by paper size first. I’ve no idea what Impression does, as I don’t use it.

² Which includes PDFMaker from R-Comp.

³ The test is basically when the file exists, has non-zero size, and isn’t held open by some other application.

anything doing the trick that PrintPDF does can’t see the original filename

I was answering the original question which was

Is it possible to print an Impression document from... a BASIC program?

and spelling out the steps that this theoretical program would carry out, including setting Printer$Path to control precisely where the file is created and therefore its leafname.

And since this would be automated by a program, it would ensure it had changed Printer: before sending the next file. Trying to avoid an automation step by dragging all the files simultaneously is bound to fail because as I said earlier

you might hope that there was a nice protocol that !Printers (and/or PDriver) uses to inform the system that printing is happening… but there isn’t

And as you have demonstrated, Null Polls simply won’t do.

One would have to look for a call to PDriver_EndJob (which is neither the end of printing nor the end of output to Printer:) and then sit on FindV until Printer: was closed and immediately change Printer$Path at that point. However, there’s no method for intercepting the PDriver SWIs, so you would have to delve into the Kernel’s SWI tables.

Which is why I suggested the bulleted strategy above.

Applications don’t have to tell the printing system what the original filename of the file being printed out was, as far as I know, so by the time PrintPDF gets the file, the original filename is long gone

In Ian Hamilton’s !PrintSpool application you get the title of the document in it’s Queue but of course when it is passed to either say PDFMaker or PrintPDF the resultant dialogue box gives its own name.

You can hold prints from being passed on and you can store and change the title within PrintSpool but it is manually.

The actual file held though does not have that title though it is a PostScript one.

It does store a Data file called Titles which references things but not sure how that works.

I wonder if Ian could see his way to add a function to assist in this.

Only other issue is as pointed out you get a dialogue box generated per file referring to the page size so it would need sorting as well.

The reason for my question: I’ve been contacted by someone who inherited their father’s RISC OS computer, and they would like me to convert all of his Impression documents to PDF. The problem is, there are several thousands of documents so manual conversion is not feasible. I want to build a script or program that traverses all directories and prints all Impression documents to PDF.

While the discussion on how to handle batch conversion of such things is very interesting, I would start with questioning the requirement itself :-)

Now that !Style is freely available, just set up a “portable” RPCEmu installation with all the Impression files inside and a readily-installed PrintPDF. So whenever a specific document is really needed as PDF, convert it when it is needed. And not before.

I would start with questioning the requirement itself :-)

A very pragmatic approach… I guess our brains just hiccuped at the idea of “several thousand documents”. I mean… wow.

Now that !Style is freely available […] convert it when it is needed. And not before.

This is likely to be the most viable approach. I would imagine of those thousands of files, there are some that are important and will need conversion, and others that aren’t even worth the time opening them.
Same with me, same with everybody I’d imagine. In Google Docs, I have some important things. But I also have cruft. There’s a document telling the Colis Privé driver that it’s okay to leave the parcel in the letterbox (it was the ESP32 module from Amazon). I could delete it, but that means taking the time to find it.
[I have, on Drive, pushed all of these files into a “stuff” directory, and backups of important documents into directories; but unfortunately Docs just shows everything in a pile sorted by last access… sheesh…]

Anyway, just because there are thousands of files doesn’t mean that thousands of files are needed. Convert on demand, that’s a really good approach.

I would start with questioning the requirement itself

Well that can only be answered by the person who contacted Arjan but I would summise that in PDF format they can be read by anything and also in PDF format they can be imported in to MS Word and converted and edited on a non RISC OS machine.

No need to set up RPCEmu which is really not making them available for everyone easily.

Just a thought.

Well that can only be answered by the person who contacted Arjan but I would summise that in PDF format they can be read by anything and also in PDF format they can be imported in to MS Word and converted and edited on a non RISC OS machine.

Oh, it is clear that having it as PDF would be a great thing. But as it turned out, there is no simple solution to batch-convert all those docs to PDF.

No need to set up RPCEmu which is really not making them available for everyone easily.

If no batch conversion solution is found, the emulator solution allows the interested party to inspect all the Impression documents, and then if they have found something interesting, convert exactly that document to PDF to make it available for other systems. Depending on the count of “interesting documents”, this might be a worthwhile solution.

Just out of curiosity, what stops the heirs from viewing their fathers files on his very computer, and make the PDF-conversion themselves, if needed? Even if there’s a complete lack of familiarity with RISC OS, a simple demonstration of 10 minutes for this single task will suffice, and they can go ahead.

So really your question becomes “is there a way of printing thousands of things to file without !Printers continuously overwriting the same output file?”.

Yes. I can print a whole directory full of draw files to become a whole directory full of PDF files, each with the same leaf name as the original draw file. I use !MultiTask to do this. It simulates the successive dragging of each draw file in the directory from which a single drag is done to the postscript printer driver icon which produces the file postscript/ps in a known place. It sees this, waits for its size not to change for 2 seconds, it then renames it to (leafname)/ps and issues a taskwindow command ps3pdf before simulating the drag of the next draw file. It does this until it has processed each draw file in that directory. It would be trivial to make it do this for files of type &BC5 ‘ImpDoc’. Not sure whether it would work for application-style Impression documents (it doesn’t, creating an error from the printer driver ’Don’t know how to print applications’). Dragging an Impression document (in single file form) onto the printer driver icon does indeed just print it with no user intervention.

So if they are in single file format, the problem is solved. The next version of !MultiTask (in a week or three) will offer the ‘save’ option to drag an icon if an ImpDoc file is being viewed (as well as a Draw file) and then look for that files of that type in its directory rather than Draw files.

Oh, it is clear that having it as PDF would be a great thing. But as it turned out, there is no simple solution to batch-convert all those docs to PDF.

Refuted, see above.

Refuted, see above.

It does not sound “simple” to me yet, but surely getting there! Well done!

Many many thanks, everybody.
I have promised to convert everything to PDF so I have to do the work.
There are lots of single file documents, but also lots of application style docs.
Among the documents there are many old backup copies, I’ll make an inventory before blindly converting everything.
I have found that the free Windows program Ovation Pro Reader reads and prints Impression documents when the filename extensions are correct, e.g. Impression document with filetype &BC5 becomes document,bc5 on Windows, which I can convert to document.bc5. That way all of the documents are available to the heirs while I convert stuff to PDF.

Yes. I can print a whole directory full of draw files to become a whole directory full of PDF files, each with the same leaf name as the original draw file.

Whoa! :-) :-)

It does not sound “simple” to me

Compared to the alternative of doing it by hand…

I have promised to convert everything to PDF so I have to do the work.

Was the promise made before or after you knew how many files needed conversion?

I have promised to convert everything to PDF so I have to do the work.

Or to wait for the new version of MultiTask.

Chris wrote

It simulates the successive dragging of each draw file in the directory from which a single drag is done to the postscript printer driver icon which produces the file postscript/ps in a known place

That’s what I suggested, yes.

[it doesn’t] work for application-style Impression documents

What a shame. In which case the correct strategy would have been to:

• Broadcast a PrintTypeOdd message with filetype &BC5 and the name of the doc as type 18.
• If that bounces, StartTask Alias$@PrintType_BC5 <filename> yourself.

However, my copy of Impression fails to acknowledge the PrintTypeOdd even though it does go on to print the document, so it bounces and then prints anyway.

So you’ll simply have to ensure Impression is running, and then send it a plain old PrintTypeOdd as a type 17 and then proceed as you have been. That works here.

It’s good to know that Ovation Pro could do the job of converting the single file documents.

The solution to the multi-file documents is probably to load them into Impression Publisher in an emulator and save them out as a single file document. I don’t think there was an easier way to perform that conversion. In theory, it should be possible to combine all the files into a single document without Impression getting involved.

In theory, it should be possible to combine all the files into a single document without Impression getting involved.

Not if they’re proprietary Impression documents. All file formats have limitations, and Impression is no different. There’ll be a limit to how many different Master Pages you can have, for example. And combining all the Styles and Effects would be nightmarish.

The problem with taking an application-style Impression document and saving it as a single file document is that the single file document needs to be loaded into Impression in one go and there is a memory limit of 28Mbytes. AIUI only single chapters of an application style document are loaded into memory at one time.