On Thu, 25 Nov 2004 20:43:29 +0100, Wolfgang Lenerz <[EMAIL PROTECTED]> wrote:

On 25 Nov 2004 at 18:46, Rich Mellor wrote:

If Proforma cannot output to these printers - is there much point in
persuing this further as people will still be struggling to find printers
which are compatible with the QL...
 I disagree (again...).

I'd never buy a GDI printer, and there are many others that wouldn't (just
think of Linux). There are so many pronters out there that have some kind of
emulation( Laserjet, PCL etc...)

The trouble is locating them - if these printers are so readily available at low prices, then what exactly are we developing this for as the QL can already output PCL 3 (just not the later versions).


There is no list anywhere that I can find of modern printers which support ESC/P2 or direct text output. Don't forget that most Linux / Unix users now use some form of printing program for output - no idea whether that sends plain text and epson control codes to the printers or graphics..??


.
> Well , if one told me what these were, I'd probably have done it
> already...

Have a look at the standard Quill output for starters - Dilwyn will have a
copy of the complete Epson ESC/P programming manual somewhere for
download, but it is large. Text87 output is a lot more troublesome as it
uses a large number of text formatting commands.

No, let's keep things simple: what codes are used for bold on/off, underline,
high, low?

Easiest thing is to print a test page from Quill as it includes some codes at the start which also need to be ignored


ESC @ - reset printer
ESC C n - set page length in lines
CHR$(13) - Carriage Return
CHR$(10) - Line Feed
CHR$(12) - Form Feed
ESC R n - Select international character set - used to translate £ symbol (n=0 is USA, n=3 is UK)
ESC E - Bold on
ESC F - Bold off
ESC 4 - Italics on
ESC 5 - Italics off
ESC - n - Underline on / off (n=1,49 ON or 0,48 OFF)
ESC S 0 and ESC S 48 - Superscript on
ESC S 1 and ESC S 49 - Subscript on
ESC T - turn off subscript / superscript


Those are probably the main ones from memory - the translates are the problem areas.



Yes it will... :-) However as you rightly say, the PFF device cannot open
a directory device if the user wants to use a hard disk for temporary
storage rather than space in memory...

If he wants that, let him print to a file.

If only all programs could output to a file - certainly accounts programs do not allow you to do this - as this is part of the security - prevents you from altering the reports by hand.




Not really a modern version of a printer spooler if they have to (a) Print
from their program (b) remember to call up the printer spooler program to
actually see any output.. !! It is all too easy to see no output from the
printer and straight away think - oops have I run out of paper / ink....
Or just completely forget to print out the files (eg. if you go away from
the QL while it is doing a series of reports).
a) above seems pretty logical to me... If they forget that, there'll be no print.


Yes lol !! Chances are however, they will forget to launch the second print spooler program.


> 1 - Design the PFF device so that it can only have one file open to it
> at any time. Trrrrrrrrrrivial,since we're designing that device anyway.


Isn't that just adding to the annoyance factor - "Cannot print now cos
something else is spooling..."

"Can't print now 'cause something I'm already printing something else" sounds
quite logical to me.

Yes but why should the QL be limited like this - it is much easier if you can add a job to a print queue and close the current program you are using.



> 2 - What happens TODAY when two apps try to print to par/ser
> at the same time? In what way is the user better/worse off, even if we
> don't implement n° 1 above ?

Because it prevents the user getting annoyed by having to wait until one
print task is finished -
...which is what they have to do today...
they may not even know when it has finished and
just have to keep on trying until the PFF device lets them (if printer in
a different room, or filter is sending output to a postscript or HTML file
rather than a physical printer).


Isn't that really totally hypothetical?

What if this punter wants to print 1000 files at the same time to 1000
different printers hanging off a super USB interface, some of which use Epson
emulation, some others Postscript, yet others GDI and whatnot? Do we care if
he can't do that?

Not that hypothetical - if the user is using a complicated filter (eg. convert to postscript), then they could be waiting a while, without actually knowing what is going on in the background as there is no reassuring noise of the printer running.


<<cut>>

What happens when someone wants to send a graphics dump?  Just add a
graphics filter.

"Just" add a graphics filter. I'll let this stand as is.

I have no idea how easy it is to pass a PIC file to Proforma - Joachim??



>> This FILTER THING is the most complex part of the program, but essential
>> to ensure that the user can have a wide range of printing options
>> available.
>
> A simple set of different filter progs called, if you want, from one
> printer spooler selctor would be enough for that.


Yes it would - but the problem is how the PFF device and the filters
communicate with the printer spooler. My understanding is that a THING is
much better for this purpose.
The best way I've found right now is to use pipes. The PFF device just puts everything into a pipe. Then we have a standard format that anything,
filters, spoolers etc... can easily get at.

Yes this would be easier IF the user has enough memory to hold the document in a pipe.... Remember we want to aim this at the lowest common denominator.



>> A flow chart appears below of the way the system will work: >> Proforma Filter Flow-Chart >> > (...) > >> FILTER THING opens a channel to the >> temporary storage (pipe or file) >> and passes the channel ID back to the >> PFF device > > I'd be MOST interested in knowing how you'll handle that (see my other > message to Joachim).

See other response - suggest the FILTER THING opens a channel in readiness
if this will be a problem.

How many files are you going to keep open, since your hypothetical punter will want to print so many things at once?

Presumably as soon as the FILTER THING has passed the channel id back to the PFF driver, it can open the next one. Therefore there should only ever be one unused channel in existence at any given time.


Maybe I am wrong here.....



--
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

Reply via email to