RM Wrote: Hmm I see Joachim's point (is it me, or does everyone else not receive these posts from the QL-Users server in the right order???)
Rich, it is not you, most mailers by default display mails in the order of time the mail was sent. Someones clock is not very synchronized.
Also, for your quoting, I suggest you configure your mail program for text only mails to this list, and possibly switch to a mailer which can handle text properly (like Mozilla Thunderbird).
Back to the actual topic though...
I think that there are a couple of ways of taking this forward. It is easier to presume that every program will print using an Epson compatible printer driver. We would then get the following scenario:
I don't think that would be a good scenario. For one thing it makes things more difficult in some cases and very limiting in other cases (like supporting many fonts and support for graphics).
So I suggest we fix this by supporting more than one intermediate language.
So, assume three possible intermediate languages, one being Epson printer codes (or a subset thereof), one being Postscript and one being a new native, all features included special language. Other printer emulations could also be added etc.
What has also not yet been discussed is possible support for multiple printers. You may have a laser printer attached to the par port and a colour inkjet to the serial port or other configurations. When designing a system, this should also be catered for (even if it is not yet supported in a first version).
The PFF device could be powerful enough to understand which printer and which intermediate language is used.
For example PFF is the default printer and default intermediate language PFF1 is the first configured printer, default intermediate language PFF_PF the the default printer, PROforma native intermediate language PFF2_PS is the second printer, using Postscript
The configuration of the different printers could be handled (known) to the FILTER thing.
The FILTER thing annotates the intermediate language as part of the info about print jobs (together with the pipe name etc).
The FILTER thing known which intermedite languages are known to the system (probably by having the FILTER programs register themselves when they start).
1. Program prints to PAR (or PFF) device using a standard Epson printer driver
So this is changed to using any of the supported intermediate languages.
2. The PFF device accepts this data and checks it can output to the FILTER THING
Correct.
3. The FILTER THING stores the output somewhere in memory and manages everything,
Correct.
telling the PFF device whether it can print,
No. The PFF device can always forward the data. Otherwise there would be unneeded slowdown. The FILTER thing does the caching. Whether this is done in memory (using a pipe possibly), or on disk (using a temporary file) is implementation detail. In fact, best would be to allow both and have this configurable. The more memory is available to the FILTER program (and PROforma) the better, however disk caching is a nono if there is no HDD (best not done a a Romdisq).
> and also tells the filter
program whether there is something to print
Correct.
4. The filter program runs as a low priority job, checking the FILTER THING to see if there is something to print.
Correct. However, I would not run this as a low priority job, this would make the printing itself slow (the calculations take time). The scanning is easy and hardly burdens the system, as long as the FILTER job is sleeping (NOT busy waiting), the system load will be negligeable when there is nothing to print.
This filter program should be able to convert standard Epson output to either Postscript or Proforma.
No. There can be more than one filter program running at the same time. One filter program could convert from PROforma native format, allowing all PROforma fonts and graphics to be used. Another filter program could convert from a subset of Epson printer code. Yet another filter program could simply use Ghostscript (instead of PROforma) to render Postscript files, or support a subset of Postscript and render using PROforma (would be very feasable for the sulanguage defined in .ai files).
Possibly, Proforma should also be altered to be able to accept Postscript files for printing / conversion....
No no. This is a very big job. If you want wull support of Postscript, then use Ghostscript. It is massive (big), but there is no other way. Postscript is a very powerful and complex graphical programming language. It allows you to define procedures, functions, do loops, has variables etc. I don not think that is a viable option for the QL. It is a possibility for emulator users where GHosctscript is running on the native side, otherwise, I think only Q40/Q60 users with lots of memory could use this.
For something poserful and QL compatible, either
- use the .ai commands (these are only real postscript because of a large preamble in the file which defines the shorthand graphical commands) (oh yes, this is the .ai that can be imported in LINEdesign I talk about, no idea how this has evolved in recent years).
- or define a textual representation for the PROforma commands which would result in a native PROforma driver would all bells and whistles PROforma has to offer.
Joachim _______________________________________________ QL-Users Mailing List http://www.quanta.org.uk/mailing.htm
