[Gimp-print-devel] Re: MediaType

[Robert L K. <rl...@al...>]

   Date: Tue, 26 Sep 2000 08:49:04 -0400
   From: Michael Sweet <mi...@ea...>
   CC: gt...@pi...
   Content-Type: text/plain; charset=us-ascii

   Robert L Krawitz wrote:
   > 
   > For some reason, the MediaType setting isn't making it through to
   > the driver.  The default plain paper uses a density of .5 compared
   > to the density required by photo quality inkjet paper.

   Congratulations!  You've run into a Ghostscript bug!

   Actually, a feature...

I don't know if I'd go that far.  If it were a real feature it would
spit out an error if it saw something that didn't match, IMHO.

   What is happening is that some attributes (MediaType, etc.) are
   overloaded and must exist in the InputAttributes or OutputAttributes
   dictionaries.  Look in gs_setpd.ps for details.

   You register the allowed media type strings in the get_params()
   method in your Ghostscript driver.  The process is a bit involved,
   but isn't too difficult (just create a dictionary object and add
   a key named "MediaType" with an array of acceptable values)

   Another way around this is to use a different name (stpMediaType,
   or similar) instead of MediaType for the stp driver.

   CUPS works around this by disabling the lookup stuff in the
   Ghostscript code, which I'm betting is not an option for the
   stp driver.  (Generating a list of valid values from the PPD
   file isn't trivial, unfortunately)

Are you certain CUPS is working around it?  I'm seeing the same
problem (I think) with the native CUPS driver.

Anyway, there are three potential solutions I can think of here:

1) Do this whole dictionary thing.  Unfortunately, I'm getting busier
   right now, and I'm also none too keen on the fact that it doesn't
   report an error.  Also, the choice of available media types could
   be fairly complex (there could be a fair bit of logic behind it).
   Until I know what the other arguments are, I can't register a
   useful list of media types.

2) Rename all of the attributes to stpWhatEver.  I'm reluctant to stop
   at MediaType on general principles, but I could be convinced
   otherwise.  This also has compatibility issues.

3) Accept stpMediaSize (and whatever) as aliases for MediaSize; if it
   finds stpMediaSize, don't bother looking for MediaSize.

I'm somewhat leaning toward #3 right now, but I'm curious what other
people think about this.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton