
SWI Documentation:
 PDriver_DeclareFont
 PDriver_DeclareDriver
 PDriver_RemoveDriver
 PDriver_SelectDriver
 PDriver_EnumerateDrivers
 PDriver_MiscOp
 PDriver_MiscOpForDriver
 PDriver_SetDriver

New structure of Printer drivers, ie. pdumpers, pdriver, pdriverXX
Notes on writing your own printer drivers
Driver numbers *upto date list*

PDumpers:
 What are they
 How do they work
 Writing them
 Limitations
 
Suggested practices, suggested interface.

--------------------------------------------

PDriverPS: need to think of a defined method for ISVs to add their own
procs.  Don't want them polluting PDdict, but we could reserve one entry
in PDDict (say ISVdict) for them to define and use.  Then need code to
ensure that it is on the dict stack whenever required:

PDDict begin ISVdict begin              % but with a check that ISVdict exists...

and need to ensure that "def" definitions go to the right place!!  One way would
be to ensure that stuff in PDDict never assumes the PDDict is on the top of the dict
stack.

Also need: a way for ISVs to augment the prologue on the fly

PDDict begin
   /ISVDict 1 dict def
end

PDDict begin ISVDict begin

end  /ISVDict 100 dict begin  ... definitions in ISVdict ...

end end

--------------------------------------------

PDriverPS: Remapping to fonts with funny encodings
==================================================

SAH: 3FEB93

At present any font that is mapped to a native printer font will get
re-encoded.  If the font does have an Encoding associated with it (either by
the based-on method or by having an Encoding file in it) then we currently
just default to Old Latin 1.  This causes problems when the font is
non-alphabetic (eg Dingbats).  We should perhaps assume that the font should
not be re-encoded in this case, and hope the glyph positions match up
adequately; alternatively, make use of the encoding information specified in
FontPrint.  The latter approach is much better because we know that Old
Latin 1 and Adobe Standard differ quite a lot.

Augment the information specified in the Encoding menu of FontPrint to include
an "As Is" option, which does forces MakePSFont to not re-encode:-

  Adobe.Standard -> use Old Latin 1
  Adobe.Special -> use Sidney encoding
  Adobe.Dingbats -> use Selwyn encoding.
  As Is -> do not re-encode; assume the printer encoding is same as ours.
           This is not perfect, but will probably be a lot more helpful
           than using Old Latin 1 if the font is a symbolic one!

Could be implemented by replacing the contents of the Adobe directory (not
used at present) by files containing OUR versions of the Adobe encodings;
for example, Adobe.Standard would contain Old Latin 1, Adobe.Special would
contain Sidney encoding.  The scheme is extensible; the FontPrint menu
is generated with reference to this directory.  It would be necessary
to carefully document what is going on so that people do not assume that
these files *are* the Adobe ones. MakePSFont would then need to be modified
to use these specified encoding file if it can't pick the "right" one
by the normal methods.

The "do not re-encode" option would need special support in FontPrint and
MakePSFont; should be quite easy to do.

--------------------------------------------

PDriverPS: Determining when to generate EPS
===========================================

SAH: 17FEB93

Traditionally all PDriver_SelectIllustration jobs are output as EPS under
the assumption that they need to be includable in other PS jobs. 
Unfortunately programs like Draw *always* use PDriver_SelectIllustration,
even though the user typically wants to send the result to the printer
straight away.

The problem is that illustration jobs don't have device setup code, because
this violates EPS structuring rules, so these jobs do not work properly when
printed standalone!  (As a workaround the current version of PageBox on the
SrcFiler (3.41) has the test commented out, so that *all* jobs get device
setup code, even if they are illustrations).

The situation is not satisfactory.  The assumption appears to have been that
all 1-page jobs can be done as EPS, but this is clearly wrong; in fact the
decision as to whether EPS should be produced should be made by the USER.
Ideally I'd like to add an option button to the PostScript printer
configuration window, saying "Produce EPS".  Only if this is set AND the job
is an illustration one, then the EPS header should be produced.  This avoids
making any changes to other apps, which can still call
PDriver_SelectIllustration for single-page jobs, and PDriver_SelectJob
otherwise.

(As a bodge-up, we could just alter the code so that
PDriver_SelectIllustration gets treated the same as PDriver_SelectJob unless
output is to a file.  But this would not help people who are just spooling
to a floppy to take to a remote printer. Doing this bodge would only add to
the confusion, so let's not do it.)

BCockburn 17-Feb-93

  As a follow-on to the comments above about an EPS button in the printer
configuration window perhaps with this interface the difference between
PDriver_SelectIllustration and PDriver_SelectJob could be removed!  If EPS
is not selected the job is output with job setup information and as many
pages as required, if EPS is selected then no job setup information is
included.  If more than one page starts to emerge and the job is going to
disc then create Printout.Page001, and Printout.Page002 etc. as separate
files each truly EPS conformant!
