Hi Rich,
Whats wrong with a back ground job started at boot with low priority
as the intermediate.
It could : look for a configuration file and read that in & then know
to ;
clear the pipe anytime something is put into it by PFF
device &
save the contents of the pipe to a designated location
on disk
- ram rom win flp if so configured
call the appropriate filter eg Quill files configured
to be
treated as ASCII as no printer driver loaded for this
version of
Quill
Text 87 files treated as ESCP2 and a proportional font
used for
printing
QD files have FF added by the filter
and so on upto the user
Or call the GUI before exec ing a filter if thats the
configuration
set up.
GUI could be used to change configuration at run time and
inform the
background task by printing the new config file to the
PFF device with
a header that tells it to read the new configuration
rather than call a filter
etc
Duncan Neithercut
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Rich
Mellor
Sent: 28 November 2004 12:57
To: [EMAIL PROTECTED]
Subject: Re: [ql-users] Proforma Filter
I think that Wolfgang has put together an excellent proposal here
which is
obviously very well thought out in the light of previous discussions.
Having given this problem some considerable thought myself, I do think
that Wolfgang's solution has some definite positive aspects, not least
of
which is the ability for us to program a GUI (Printer Control Program)
in
something easier than machine code PLUS no-one has to learn how to
program
in THINGs.
The idea of a small background job initiated when the PFF device is
loaded
sounds ideal, provided that it can be configured with the location of
the
Printer Control Program which it needs to launch. I would also rather
go
for having this Printer Control Program start with a priority of zero,
which can then be set to 1 (or higher) by the PFF device when it is
asked
to open a channel. The job's priority can be reset to 0 once it has
created the necessary link between the PFF device and the Filter
Program.
However, I do perceive a problem here. I still favour the ability of
the
user being able to use either a PIPE or a file as the temporary
storage
for the output from the PFF device. This could of course be
configurable
in the same configuration block that contains the location of the
Printer
Control Program.
However, we return to the main stumbling block. The Printer Control
Program needs to maintain a set of channels open to temporary storage
areas - how does the Printer Control Program pass the ID of the
channel
back to the PFF Device so that the PFF device knows where to output
its
data??
The GUI
=======
The idea of this being launched as and when needed from disk sounds
ideal. However, the reasons why it was proposed that some of this
function be included within the Printer Control Program (running as a
THING) are as follows:
1) If stored on floppy disk, we have to remember that the user may not
have the correct disk in the drive. OK we can overcome this by
prompting
the user to insert this in the disk if required - however, what if
they
are using XChange program in one disk drive, their documents in
another
disk drive and then need a third disk containing the GUI and filter
programs.....
2) The various filter programs written for use with the system could
register themselves with the THING, so that the user can be offered a
list
of the various output options available (it also means we do not have
to
re-write the GUI each time a new filter is written). The solution to
this
would be (presumably) for each filter to be stored in a specific
directory
- the GUI program could then look at the list of filters in that
directory
and check some sort of header (either within the filter or in a
separate
file for each filter), to see what solutions are available. A header
would be preferable to using the actual name of the Filter.
3) How do we report back to the PFF device that printing has failed??
PFF options
===========
Just a small comment here - the PFF device was not designed to allow
the
user (or program) to specify the type of output to produce. It is
mainly
to specify the type of output produced by the program -
PFFe would be Epson ESC/P2 codes
PFFn would be Native Proforma Output
PFFp would be Postscript Output
PFFg would be QL Graphics Dump Output
Obviously these all require different filters - PFFn would be a simple
filter to send the output directly to Proforma and PFFp would be one
to
send it directly to Ghostscript.
The idea is not to allow a long device name, but rather one that is at
most 5 characters, the same as allowed for SER devices. A letter is
better than using the number to identify the type of output because it
makes it a lot easier to patch old programs - rather than having to
convert various SER1e settings to PFF3 etc
It was always envisaged that the user would then be offered the choice
of
output options based on the known filters which could handle this
intermediate protocol - perhaps you have misunderstood this Wolfgang
(or
just forgotten in the sea of emails).
COMMUNICATION
=============
Perhaps we still need a THING - possibly just a small one which can be
used to contain various data to allow each element of the program to
communicate with each other?
Finally I am pleased that this has gnerated so much interest - I
realise
it may be beyond many of the subscribers to this list, and possibly
provided too many emails for them to digest - please bear with us - at
least the list is showing a lot of activity for now rather than simply
moaning and arguing
--
Rich Mellor
RWAP Services
26 Oak Road, Shelfield, Walsall, West Midlands WS4 1RQ
http://www.rwapservices.co.uk/
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
_______________________________________________
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
