> The Filter is in effect a partial printer emulator. What you print from > Quill, S*Basic, or Easel, etc, via a device (Ser, Par, etc) with or without > printer drivers (printer_dat, gprt_dat) is what the Filter responds to. But > instead of converting the incoming data into ink on paper, it converts the > data stream into an intermediate format which is processed by other tasks > until it finally emerges as printed pages. > > Epson (and HP and others) have gone to a lot of trouble to work out a > language that can represent just about anything one could concievable want > to print (except smell and sound). Why re-invent the wheel? When an Epson > printer is offered straight Ascii, it prints straight text. If embedded > control codes are detected (bold, underline, graphics, etc) it responds > correspondingly. > > The filter only needs to respond to two different types of output: ESC/P2 > (for example, as this was the most commonly available and emulated printer > in the QL's heyday) and, as a concession to Linedesign users, output that > has already been formatted by Proforma and doesnt need any further > processing, ie it should go unFiltered straight through to Proforma. Great, this is exactly how I saw it going as I watched the correspondence develop.
> Therefore only one printer needs to be emulated! and only one Filter needs > to be produced! It must be able to understand ESC/P2 and convert it to the > Proforma rastering language. Whatever hardware printer you hang on the other > end is irrelevant as long as Proforma has a driver for it. The only time > this would cause a problem is if you had an application that was hardwired > to output only PCL or some other non-supported format. How many of those are > there and how important are they? > > End of Filter project ;) Whatever printer is attached, in theory Proforma should be able to rasterise with a suitable driver. With these "difficult" printers data has to be in a rasterised format even if we don't know yet what format that is. There are two choices, Pistscript or Proforma. I guess if a driver was written Proforma might be able to output Postscript? AFAIK Proforma is the only rastering system available to us, so it's use that, Postscript or nothing. Having seen reference to named pipes in all this, does that mean this project will be restricted to SMSQ/E users only? Although I think there is a named pipe driver for QDOS somewhere IIRC. Although I've been too busy with PC and car problems to try out Wolfgang's offerings, many many thanks to him for his work. And to everyone else for throwing so many contributions and ideas into the ring. It might even persuade me to get the Proforma programming docs out soon to see what I can contribute to all this. One question: are there any Proforma versions handling GD2 colours, i.e. any screen dumps for 256 colour and 16-bit colour graphics? USB printers may prove to be a hiccup as was suggested, although QPC2 users are lucky enough to be able to specify 'printer' wherever it may be. I'm luckier than many, I can connect from PC to Stylus 880 via USB and from the MinisQL to the same printer's parallel port, as long as I don't print same time from both either can print to it in the same session (gets a bit messy if I start one printing before the other's finished though, as you'd expect!). As for PCL, there are virtually no QL programs with PCL-only output. Those that support only PCL are usually specific programs handling PCL or Deskjet specific features - e.g. my own Deskjet-A5 which used PCL code facilities in HP Deskjets to print 2xA4 or USA Letter pages side by side in reduced text modes on a single sheet of paper. Basically, as long as something like that is passed through unfiltered or printed direct to SER or PAR rather than through PFF there should be no problem. I guess that'd be the beauty of the PFF device - if you print direct to SER or PAR it avoids the Proforma system. Thanks to those who contributed ideas for the SER/PAR to PFF converter. I had a play with looking at the string length bytes before the found string and it works, although it slows it down slightly of course. Next job, put a nice front end on it. Do you think it'll need a 'query each replace' option for when 'auto-replace' fails or for those who don't trust it to work correctly? Do all programs have a word length counter before the device name or do some have a byte length one? And any programs known to use a device name delimited by LF or whatever rather than the internal format with length word/byte? -- Dilwyn Jones _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
