Printing

is to define duplicate graphics modes

If you’ll remember a while back, I had a similar moan that it’s not possible to choose the print resolution or output quality on the fly (like in Windows, Android, everything that isn’t iOS…).

The solution is to literally define multiple copies of the printer with the desired options set up on each and then change printer to alter the print options.

Actually, now I remind myself of the implementation, I think it is possible to do all this kind of stuff with “Feeds”, which the dp and lj drivers support.

Is any of this documented anywhere?

Anyway, if you add a feeds: to a PDef you can name a directory in Printers:dp.Feeds which then contain a number of files that define feeds. Same applies to bins: and Printers:dp.Bins.

I assume that would allow one to select all manner of job-wide settings to be sent to the device.

I’m trawling through the code to (re)discover the details. Is there a proper document anywhere?

Vague memories of hackery 30 years ago.

The files within Feeds and Bins subdirectories consist of just two lines, optionally prefixed by name:_ and data:_ (where _ is a space).

The name gets displayed in the menu, and one can be selected. The data gets included in the output… or at least I think that’s the intention. All it actually seems to do is crash my installation, but my !Printers is ancient and potentially rotted.

Is there a proper document anywhere?

<spits tea across the room>

All it actually seems to do is crash my installation, but my !Printers is ancient and potentially rotted.

Nah, Printers is just flakey as hell. Was it PDumperDP choking?

Mine got itself in a state where the dumper would cause Printers to crash as soon as I tried to use it, until I deleted all the config files and reinstalled the printers all over again.

I guess I probably should have kept the broken files to diff them, but by that point I was more interested in getting the document printed than debugging the manager.

Is any of this documented anywhere?

Is there a proper document anywhere?

I wish…

In fairness, printing has come on a very long way since the PRMs were written. Back then we had character printers (e.g. FX80) that you could send a stream of characters to, and they would be printed in black. That was it. There was also Postscript, which didn’t affect most of us because it was all much too expensive. The ordinary layman (cheapskates such as me, if you like) could buy printers that all had proprietary protocols to drive them, but at least you could get graphics and colour. Then there were the GDI printers – very proprietary, and only useful for Windows users. More recently it looks as if some sort of sanity is working its way into printing, with IPP and Airprint, the former being completely open to cheapskates like me.

So the PRM sections, which are probably little changed from the days of RISC OS 2 and the FX80, are way out of date.

I did get a nice surprise in that most of the information for writing dumpers was there.

I’ve also been using Gutenprint for years now, so I don’t know what a non-Gutenprint printing system looks like.

Well that explains that. Feeds & Bins are supported in LJ but have rotted in DP, so although all the support code is there it never gets called (as of 2004).

In LJ the strings from Feeds and Bins are concatenated and pushed into PDumperLJ$Extra (as they are for all the PDumperXX modules). But DP neither concatenates the strings nor puts them anywhere, though they can exist as the above screenshot demonstrates.

PDriverDP does not have any kind of Extra SysVar to inject further goodies either.

The Printer Manager is a classic case of something that is written in BASIC but is too big. I’ve looked at the code many times for little odd bits, but I’ve never really managed to see how those bits work. Tonight’s example is feeds, auto, manual and roll. Those words don’t seem to occur anywhere in the entire !Printers directory, but the “Paper feed” menu has entries “Auto”, “Manual” and “Roll”. So where do they come from? And I’ve discovered that, if I put a line into a PrDefn file beginning with “feed”, Printer Manager crashes out with “Module not found”. So what makes it sensitive to “feed”, and what module is it failing to find?

The whole thing ought to be rewritten in C, but there I go again…

C does not magically fix anything. It’s not the language that is responsible, it’s the total lack of documentation (and, it appears, the uncrunched source).

The default paper feed menu comes from the Messages file. The code only knows about the first two though, and would in the absence of disc files use two tokens from the Messages file to provide the two strings… but they’re not defined anyway.

This has been caused by cut-n-pasteitis, as there is great similarity between the DP and LJ support code.

I should explain, the !Printers[+] program is Basic (irrelevant), but loads as Libraries (irrelevant) a “support” file for the particular type of printer that is selected, eg “Printers:DP.Resources.Support” (irrelevant).

Those Support programs are mostly derived from each other (IYSWIM), and in the DP case contains code that has either rotted or was never connected up. It would seem to be a fairly simple matter to enable the Bins and Feeds if PDriverDP was massaged slightly to allow a command injection at the start of the job (via a SysVar, as per).

Note that the one relevant issue of the front end’s BASICness is the inherent limit of 255 bytes on some strings. That this language limitation caused such problems to the implementor suggests some lack of familiarity or foresight. But experience is much easier these days, as is 20:20 hindsight.

Note that the one relevant issue of the front end’s BASICness is the inherent limit of 255 bytes on some strings. That this language limitation caused such problems to the implementor suggests some lack of familiarity or foresight. But experience is much easier these days, as is 20:20 hindsight.

Indeed. I well recall dealing with network shared printers where such things as spaces in the local name made network sharing difficult/impossible. I recall having to ensure that the share name was 10 characters or less (interesting parallel with old RO filenames) and 8 characters or less if you were trying to use the printer in K95.

That, Windows, situation seems to have improved over the years.

network shared printers where such things as spaces in the local name

Wasn’t the worst of these where someone had accidentally managed to create a leading space for the share name?

I earlier said

PDriverDP does not have any kind of Extra SysVar to inject further goodies either.

Having thought about it some more, this is the wrong approach anyway.

PDriverDP uses the PDumper specified in the particular graphics mode (yup, it’s not fixed for the whole printer model!). Therefore the DP support code could push Feeds and Bins into the correct SysVar by checking which PDumper is defined for the graphics mode in use, and setting the appropriate PDumper##$Extra SysVar.

So that’s the only missing bit from the support program. I have a busy weekend but I’ll try messing with my 2004-era !Printers+, because it’s unlikely to be significantly different apart from the Host Printer support I built in years ago:

Success.

Can’t do anything more with this today but I now have Bin & Feed selection in DP Config window successfully injecting content into the output stream.

So that’s an easy fix and would allow Duplex/Simplex to be selected separately from graphics mode. However there’s no UI for creating these files, and they really ought to be part of the PDef rather than hard-wired into !Printers (which they effectively are even when inside the Boot…Printers2 dir, as these are PDL strings and hence model-specific).

Obviously one could have a large number of subdirs in the Feeds and Bins dirs, so one could have CX, CX2, DM, E2 etc with files within defining generic feeds, and the PDef can specify the subdirs to use. It’s oddly disjointed though.

Also note that the strings are inserted first. This is at the discretion of the PDumper in question, but this means that anything that begins with a printer reset sequence would be entirely incompatible with Feeds and Bins.

It’s all rather unideal.

[Also unideal is that I’ve been unable to print anything through this version of !Printers without something crashing afterwards, often the JPEG rendering but sometimes a total lockup – which points to the fragility of 35 years of accumulated stuff ]

Wasn’t the worst of these where someone had accidentally managed to create a leading space for the share name?

click, select rename, ctrl-A, ctrl-X, type new name that actually works.
Return to system when junior tech has “installed the drivers like they should be”, repeat fix, smack junior round ear in mind, deliver stinging verbal that’s probably worse than the physical.¹
Repeat over years until changing remit.

¹ Similar to Nemo, but less subtle? But then my situation was stuff where anyone more intelligent than a cabbage ought to know better, and they didn’t.

But then my situation was stuff where anyone more intelligent than a cabbage ought to know better, and they didn’t.

Oh, you had to deal with management.

I feel your pain.

C does not magically fix anything.

Of course. I have found the uncrunched source, but it’s still rather terse and inadequately commented – as if the authors were running out of space. C solves the problem of space, so there’s no excuse for lack of comments.

it’s the total lack of documentation (and, it appears, the uncrunched source).

Agreed wholeheartedly.

And thank you for the explanation of the support code.

The fact that strings in there weren’t found by my search, prompted me to look in TextSeek’s Choices, where the “Don’t search inside applications” box was ticked. I hadn’t realised that this existed. It is no longer ticked.

My IPP-finder app (I’ve applied for allocation of FindIPP, but my beta testers will recognise it as mDNS) finds and interrogates IPP-capable printers on the LAN. The information coming back is extensive. I parse out all the information that I know to be necessary, and create a Printer Definition File for each printer found. It would be easy to add parsing for other attributes, if we can make use of them.

My experiments indicate that more keywords can be added to PrDefn files. Keywords that Printer Manager doesn’t understand seem to be ignored. So it would be easy to get richer PrDefn files for modern printers. All possible paper sources are publicised, though I can’t be sure that the paper size that each tray is currently set to can be known for all printers. I believe that duplexing is applicable to all paper sources, if the capability exists in the printer – please correct me if anyone knows differently. So Printer Manager can access all the information it needs.

Then comes the requirement to update Printer Manager to allow choosing the paper source and duplexing, and anything else useful. That looks like what I usually refer to as “handle-cranking”, i.e. if nemo or someone site there and does it, it will happen and work.

Then there’s the question of how to get the user’s choices in PM to the dumper, because the paper source and duplexing information is part of the stream that PDumperIPP and PDumperURF generate. There has to be a better way than setting sysvars, surely, although sysvars would work.

I believe that duplexing is applicable to all paper sources, if the capability exists in the printer – please correct me if anyone knows differently.

On my HP here duplexing isn’t available for card above a certain weight, I think regardless of the source though.

On my HP here duplexing isn’t available for card above a certain weight, I think regardless of the source though.

That would make perfect sense – thank you. Though I bet that little aspect isn’t sent in the printer’s IPP information.

Then there’s the question of how to get the user’s choices in PM to the dumper, because the paper source and duplexing information is part of the stream that PDumperIPP and PDumperURF generate. There has to be a better way than setting sysvars

The information in the “PDriverDP and dumper configuration block” is largely or completely useless for the PDumperIPP and PDumperURF dumpers, and a pointer to the block is passed in all the calls to PDumper, so in principle that represents a way to pass lots of information, either directly or as the name of a file.

So it looks to me that there are ways to do all the new things we need:

- get all the required info from modern printers;

- create a rich Printer Definition File;

- pass all the new information to the dumpers.

Is there a way of comparing a squeezed BASIC file with the original?

Squeeze the original (and hope it allocates variables the same way) and then compare?

But note that any number of things could throw it off. A simple renumber, no syntactic difference but would be a binary difference…

A renumber should be no problem, as both SideDiff and my Compare will compare BASIC files ignoring the line numbers. Much more important is how it has been ‘squeezed’. As Rick says, if you can squeeze the original using the same routine and settings a comparison is possible, but if not there could be hundreds of changes.

Is there a way of comparing a squeezed BASIC file with the original?

As others have said, not easily.

Back in the day, I used to develop BASIC software on a RiscPC where BasCompress could be used to link and crunch the sources; I then used the resulting test builds on an Iyonix. I’ve told the story a few times of how a hard disc failure on the RiscPC lost all of the un-crunched work in progress¹, leaving me with the published sources from the versions on my website, and crunched copies of the development versions on the Iyonix.

After a decade of doing nothing, I used a visual diff tool (on another platform) to compare the two versions and then un-crunched the test builds one variable and procedure at a time using search and replace, until the remaining differences were the changes which had been made in the test builds. It wasn’t as laborious as it might have been, but I still don’t recommend it as a general idea; that said, it’s how software like Float still exists and can be developed.

¹ Check your backups carefully, people: otherwise it’s only when you need them that you find that they’re not quite what you thought they were.

My takeaway is just don’t compress BASIC programs. It’s not been needed for memory issues or performance for a very long time, and what is the point of obscurity these days?

Dave decided

I believe that duplexing is applicable to all paper sources

You’re a braver man than me. I can’t think of an example where it wouldn’t be, but I will not declare that this means there isn’t one. There’s good reasons for exceptions, especially when you have this kind of thing:

It is possible for there to be multiple paper paths and for the duplexer to be on one and not the inflexible-substrate manual feed, for example. [I’ve had very good experiences with Xerox SRA3s BTW, highly recommended, and not just because my code may be in them]

it would be easy to get richer PrDefn files for modern printers

!Printers is rather over-engineered in this respect, yeah (there is effectively a schema for such files – it’s called ‘Template’ confusingly). John Tytgat and I experimented with PPDs for PostScript printers for similar reasons (and the fact that there are now two PPD filetypes is Acorn’s fault, not mine – they shouldn’t have allocated me one when there was already one defined, or vice versa).

HostFS trying to kill me with file extensions

There has to be a better way than setting sysvars

Bear in mind that the print system has to work in the absence of !Printers. In fact it’s possible to run !Printers in a single-shot config-only mode that sets up the print system and then quits straight away. So whatever mechanism !Printers uses to inject further config into a print job has to be the same mechanism that apps would use to override it when driving the printer system itself.

And though it’s certainly possible to create different mechanisms, in what way would they be better?

Alan observed

duplexing isn’t available for card above a certain weight

Quite right. This is why I mention paper paths. Duplexing can be done ‘for free’ as part of the paper delivery path up to a maximum thickness and size. Obviously it’s not possible for roll paper, which some devices can support.

Colin asked an important question:

Is there a way of comparing a squeezed BASIC file with the original?

This is something I’ve been thinking about recently, because there’s significant difficulties DIFFing BASIC programs, not least because of auto-renumbering in editors.

What would be needed is a semantic diff that cares not for non-syntactic spaces, line numbers and non-syntactic line concatenation, and spots pertinent changes in the code. Give it the ability to map symbol names too (i.e. “aa” in file1 appears to be “longvarname” in file2) and ignore REMs and other deleteables and it would be very powerful.

Good question.

Druck advised

My takeaway is just don’t compress BASIC programs

My feeling is that symbol length will not really make much difference to SCT collisions beyond the smallest of loops. But the perennial paucity of PROC/FN lists (there’s 54 lists for variables but only one for PROCs as standard¹) means that short PROC/FN names are more important than short variable names.

¹ nemoBasic spreads PROC/FNs across the variable chains as an optimisation, but continues to check the dedicated chains in case the program does something ‘clever’