Some discussion about UPD-like topics is occuring on lpr-discuss.
---------------------- Forwarded by Carl Kugler/Boulder/IBM on 03/05/2001
09:16 AM ---------------------------
Robert L Krawitz <rlk@alum.mit.edu>@lists.sourceforge.net on 03/02/2001
06:36:38 PM
Sent by: lpr-discuss-admin@lists.sourceforge.net
To: thubbell@compumetric.com
cc: mpruett@valinux.com, lpr-discuss@lists.sourceforge.net
Subject: Re: [Lpr-discuss] Re: PPD file for Epson Stylus Color 600 and GPr
Date: Fri, 02 Mar 2001 11:57:55 -0600
From: Thomas Hubbell <thubbell@compumetric.com>
Mark Pruett wrote:
>
> It looks like gpr is segfaulting when it attempts to return from
> the fill_option_menus() routine. This usually indicates that
> some statement within fill_option_menus() has trashed the
> stack (and the function's return address). I'm trying to discover
> exactly where this is happening now.
I figured out what the problem is. I've actually seen this before, to
tell you the truth. The problem is that gpr has a static array for the
number of menu items in the Paper size menu. It's set at 45, but the ppd
has 52 or so entries for page size.
I doubt that the printer actually supports this many paper sizes
"officially", but the gs/stp driver may have other capabilities.
Epson printers are quite happy to take any size you give it, as long
as it's within bounds. We went and scrounged just about everything we
could find, and wound up with over 100 defined sizes.
So, a quick fix to increase the array size will solve this problem. But,
I wonder when we'll encounter another printer that supports 75 media
sizes!
Any of the large format printers probably do.
Now, the foomatic PPDs may work perfectly well, but they may not
necessarily be what you (or HP) want. It seems to me that these
PPDs all contain UIOptions that conform directly to what the gs
driver supports. Therefore, they will contain a variety of
"esoteric" entries that some users may not know how to handle
(Floyd-Steinberg dithering, for example). HP may prefer to create a
PPD that has entries that are much closer to the windows drivers
(i.e., "Best", "Normal", and "Draft" versus "1,200 x 1,200 dpi",
"600 x 600 dpi", "300 x 300 dpi"). The PPD structure would allow
you to combine several of the driver options into one setpagedevice
command, creating something equivalent to a "Normal" mode, for
instance. In this case, vendor-supplied PPDs would probably be
desirable, as they (or one of their contractors) could best
determine what constitutes these various modes.
Again, like I said earlier -- be careful. A vendor supplied PPD with
a vendor supplied driver is fine, but generally you want the PPD to
match up with what whoever wrote the driver intended. That said, stp
has a huge variety of options, and that's only going to get more so
over time, but a lot of these options will be really obscure and only
intended for people who really want to experiment
-- Robert Krawitz <rlk@alum.mit.edu> 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 lpf@uunet.uu.net Project lead for Gimp Print/stp -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
_______________________________________________ Lpr-discuss mailing list Lpr-discuss@lists.sourceforge.net http://lists.sourceforge.net/lists/listinfo/lpr-discuss
This archive was generated by hypermail 2b29 : Mon Mar 05 2001 - 11:20:21 EST