Wolfgang Lenerz writes: > I've thought a bit about this question of printer drivers et all.
Fabulous work, Wolfgang! <> > The FILTER > =========== <> 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. 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 ;) <> > The JOB > ======== <> > we could make a change in the job header of a suspended job which would then > become unsuspended. This is not an entire legal way of doing things, but the > least illegal I can find. I personnally would prefer to change that job's Couldnt we just change the license a teeny weeny bit to make it legal ;) > priority from 0 to 1 (or whatever) which will also cause the job to awaken, > but this is exactly the same principle. We can probably test both - having > implemented one, the other is trivial. I didnt invesigate this possibility, but if it works, it would probably be better. > Now the question becomes: what does this job do? Here I have quite a > different philosophy from Joachim and Rich. Apparently for them, this job > does important work. For me it doesn't, it is an "intermediary job" and all > it should do is - start another job. Agreed, and there should be some way of re-initialising it in case it gets removed. Eg in S*Basic the command PRTSRV would start it up provided it doesnt already exist. > The reason for this is that I envision that this job should be set up by the > PFF device driver when that is installed (and thus the job to be awoken which > will be part of it) All of this will all be programmed in machine code. > > Doing some big print processing job in m/c is not my idea of fun, when we > have a perfectly functioning Basic that is more or less ideal for this. It may not be as bad as it sounds. Printer languages are usually relatively simple and quite regular. Most of the work would simply involve a translation table (I think). <> Im not able to test very well until I have a working Proforma installation. Is there a Proforma-only installation somewhere I could try? This would be necessary for this project, as on a GC, for example, thered not be very much room or grunt to run ProWesS too. Great work everyone, but although enthusiasm is very necessary, lets not run away with it before were sure of what is wanted and how it will work. Im not convinced that weve even satisfactorily concluded the basic "market research"! ie, Why do we need it? (I know that at present I dont, I can print from all my "serious" QLs as it is), what are the minimum specs? If the reason we need this is because of the Winprinter issue, then there is also a connector issue, as Winprinters - of necessity - will soon all have to be USB. For emulator users there are other possibilities, etc, etc. I dont want to rain on anyone's picnic - Im enjoying this too! - but in a collaborative project it is vital (and a much better oportunity than when working alone due to the many different areas of expertise readily available) to get as much right as possible from the start or there may never be another one.. ;) Per _______________________________________________ QL-Users Mailing List http://www.q-v-d.demon.co.uk/smsqe.htm
