Menu
▾
▴
gimp-print-devel
|
From: Robert K. <rl...@al...> - 2008-03-20 23:58:06
|
Does it really make sense to keep the separation between 5.0 and 5.1? I get the feeling that it's causing a lot of confusion out there, because people naturally think that 5.1 releases are newer/better than 5.0, when that's not necessarily the case (e. g. 5.1.3 is not newer than 5.0.2). This confusion seems to affect distributors in addition to users. This made sense going from 4.2 to 5.0, because that was a radical change and 4.3 really was unstable for an extended period of time, but it's not clear to me that that makes much sense any more. At this point, 5.1 is basically 5.0 plus an improved Postscript driver minus support for a number of HP inkjets. 5.1 releases are otherwise betas or release candidates for 5.0 point releases. If we do this, then the next release after 5.1.7 will be 5.2.0 (in place of 5.0.3), and we'll just move forward from there unless something really destabilizing comes along, which I can't really see happening (certainly nothing like 5.0). The next even moderately big feature set is support for color management, but I can't see that being nearly as disruptive as what we did in 5.0. That would be the feature driver for 5.3 (or maybe we skip 5.3 and go to 5.4, just for consistency). The only real concern I have is the issue of the HP inkjet printers -- I don't particularly like just dropping wholesale a lot of printers, but that's what we agreed to do in exchange for HP improving the Postscript driver. Only thing there is that we wound up having to drop and rewrite all of the PPD support that they wrote, and without reviewing the code, it's not clear to me that any of the code written by HP is even present any more. -- Robert Krawitz <rl...@al...> 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 Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Robert K. <rl...@al...> - 2008-03-26 00:09:38
|
Is there anyone who's opposed to moving forward with a 5.2 release and scrapping the development/stable release scheme? Please let me know by the end of the week; I'd like to move forward with it quickly. -- Robert Krawitz <rl...@al...> 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 Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Roger L. <rl...@wh...> - 2008-03-27 11:56:41
|
On Tue, Mar 25, 2008 at 08:09:35PM -0400, Robert Krawitz wrote: > Is there anyone who's opposed to moving forward with a 5.2 release and > scrapping the development/stable release scheme? Please let me know > by the end of the week; I'd like to move forward with it quickly. While I'm not opposed to it, I think a development and stable split is sometimes needed. For example, you can't ever make any backward-incompatible API/ABI changes. This has no bearing on releasing 5.2, though, it's just a general observation. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail. |
|
From: Michael R S. <ms...@ap...> - 2008-03-27 13:03:40
|
Roger Leigh wrote:
> On Tue, Mar 25, 2008 at 08:09:35PM -0400, Robert Krawitz wrote:
>> Is there anyone who's opposed to moving forward with a 5.2 release and
>> scrapping the development/stable release scheme? Please let me know
>> by the end of the week; I'd like to move forward with it quickly.
>
> While I'm not opposed to it, I think a development and stable split is
> sometimes needed. For example, you can't ever make any
> backward-incompatible API/ABI changes. This has no bearing on releasing
> 5.2, though, it's just a general observation.
Sure you can, just do beta releases for a new minor release that
contains the API changes. CUPS does this already, although we have
a "no incompatible changes in a minor release" rule so changing the
ABI incompatibly requires a major release bump.
I think the key is just to document/define the new release process,
something simple like:
Gutenprint x.y.n releases contain only bug fixes and new drivers
Gutenprint x.y+1 releases can contain new APIs/features that are
backwards-compatible with Gutenprint x.y, in addition to bug
fixes and new drivers
Gutenprint x+1 releases can contain incompatible changes with
Gutenprint x, in addition to compatible changes, bug fixes, and
new drivers
The tricky part is just that PPD files may depend on having a certain
minimum version, but we can enforce that in the CUPS filters pretty
easily and display a nice error if they don't match.
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer
|
|
From: Robert K. <rl...@al...> - 2008-03-28 00:13:54
|
Date: Thu, 27 Mar 2008 06:03:42 -0700 From: Michael R Sweet <ms...@ap...> Roger Leigh wrote: > On Tue, Mar 25, 2008 at 08:09:35PM -0400, Robert Krawitz wrote: >> Is there anyone who's opposed to moving forward with a 5.2 release and >> scrapping the development/stable release scheme? Please let me know >> by the end of the week; I'd like to move forward with it quickly. > > While I'm not opposed to it, I think a development and stable split is > sometimes needed. For example, you can't ever make any > backward-incompatible API/ABI changes. This has no bearing on releasing > 5.2, though, it's just a general observation. Sure you can, just do beta releases for a new minor release that contains the API changes. CUPS does this already, although we have a "no incompatible changes in a minor release" rule so changing the ABI incompatibly requires a major release bump. It's just a matter of how strict you want to be. My preference is that point (micro) releases shouldn't contain backwards-incompatible changes. I'm thinking I'd rather avoid a split in the future unless we're looking at changes so drastic that will take a long time to complete such that we'd have to go a very long time without a release. That was true between 4.2 and 5.0, but it isn't now and I don't expect it to be any time soon. I think the key is just to document/define the new release process, something simple like: Gutenprint x.y.n releases contain only bug fixes and new drivers Gutenprint x.y+1 releases can contain new APIs/features that are backwards-compatible with Gutenprint x.y, in addition to bug fixes and new drivers Gutenprint x+1 releases can contain incompatible changes with Gutenprint x, in addition to compatible changes, bug fixes, and new drivers The tricky part is just that PPD files may depend on having a certain minimum version, but we can enforce that in the CUPS filters pretty easily and display a nice error if they don't match. We already do this -- the PPD files are actually locked to the precise version of Gutenprint, to the "extra" release (e. g. 5.1.99.1 and 5.1.99.2 -- either way -- would trigger a violation). There's no promise that the printer options will be precisely the same from release to release, so the PPD files need to match the driver precisely. -- Robert Krawitz <rl...@al...> 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 Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Michael R S. <ms...@ap...> - 2008-03-28 01:15:23
|
Robert Krawitz wrote: > Date: Thu, 27 Mar 2008 06:03:42 -0700 > From: Michael R Sweet <ms...@ap...> > > Roger Leigh wrote: > > On Tue, Mar 25, 2008 at 08:09:35PM -0400, Robert Krawitz wrote: > >> Is there anyone who's opposed to moving forward with a 5.2 release and > >> scrapping the development/stable release scheme? Please let me know > >> by the end of the week; I'd like to move forward with it quickly. > > > > While I'm not opposed to it, I think a development and stable split is > > sometimes needed. For example, you can't ever make any > > backward-incompatible API/ABI changes. This has no bearing on releasing > > 5.2, though, it's just a general observation. > > Sure you can, just do beta releases for a new minor release that > contains the API changes. CUPS does this already, although we have > a "no incompatible changes in a minor release" rule so changing the > ABI incompatibly requires a major release bump. > > It's just a matter of how strict you want to be. My preference is > that point (micro) releases shouldn't contain backwards-incompatible > changes. > > I'm thinking I'd rather avoid a split in the future unless we're > looking at changes so drastic that will take a long time to complete > such that we'd have to go a very long time without a release. That > was true between 4.2 and 5.0, but it isn't now and I don't expect it > to be any time soon. > > I think the key is just to document/define the new release process, > something simple like: > > Gutenprint x.y.n releases contain only bug fixes and new drivers > > Gutenprint x.y+1 releases can contain new APIs/features that are > backwards-compatible with Gutenprint x.y, in addition to bug > fixes and new drivers > > Gutenprint x+1 releases can contain incompatible changes with > Gutenprint x, in addition to compatible changes, bug fixes, and > new drivers > > The tricky part is just that PPD files may depend on having a certain > minimum version, but we can enforce that in the CUPS filters pretty > easily and display a nice error if they don't match. > > We already do this -- the PPD files are actually locked to the precise > version of Gutenprint, to the "extra" release (e. g. 5.1.99.1 and > 5.1.99.2 -- either way -- would trigger a violation). There's no > promise that the printer options will be precisely the same from > release to release, so the PPD files need to match the driver > precisely. I think it would be really, really (really! :) useful to keep the PPD files compatible in micro/patch releases, such that a vendor could ship 5.2.x and provide updates without worrying about the PPD files changing within that minor release series. Obviously new drivers will need new PPDs, but existing drivers shouldn't need updated PPDs when you don't add a feature. In short, I'm advocating that we focus on bug fixes and new drivers in micro/patch release numbers (5.2.x), and work very hard to *not* change the PPDs. If we have to change the PPDs, bump the minor release number (e.g. 5.2.x to 5.3) and track the minor release numbers (5.2, 5.3, etc.) with the PPD's FileVersion keyword. Then we can update queues when a new PPD is available, but not otherwise. -- ______________________________________________________________________ Michael R Sweet Senior Printing System Engineer |
|
From: Robert K. <rl...@al...> - 2008-03-28 11:44:30
|
Date: Thu, 27 Mar 2008 18:15:24 -0700
From: Michael R Sweet <ms...@ap...>
Robert Krawitz wrote:
> Date: Thu, 27 Mar 2008 06:03:42 -0700
> From: Michael R Sweet <ms...@ap...>
>
> The tricky part is just that PPD files may depend on having a certain
> minimum version, but we can enforce that in the CUPS filters pretty
> easily and display a nice error if they don't match.
>
> We already do this -- the PPD files are actually locked to the precise
> version of Gutenprint, to the "extra" release (e. g. 5.1.99.1 and
> 5.1.99.2 -- either way -- would trigger a violation). There's no
> promise that the printer options will be precisely the same from
> release to release, so the PPD files need to match the driver
> precisely.
I think it would be really, really (really! :) useful to keep the
PPD files compatible in micro/patch releases, such that a vendor
could ship 5.2.x and provide updates without worrying about the PPD
files changing within that minor release series. Obviously new
drivers will need new PPDs, but existing drivers shouldn't need
updated PPDs when you don't add a feature.
Well, we already provide a PPD file generator ("driver") and a script
to update PPD files. So a distributor who wants to ship an update
just has to have the postinstall script run cups-genppdupdate.5.2 to
update the PPD files.
If the distribution uses foomatic it's not quite as straightforward,
but maybe the foomatic folks should look into doing something like
that.
In short, I'm advocating that we focus on bug fixes and new drivers
in micro/patch release numbers (5.2.x), and work very hard to *not*
change the PPDs. If we have to change the PPDs, bump the minor
release number (e.g. 5.2.x to 5.3) and track the minor release
numbers (5.2, 5.3, etc.) with the PPD's FileVersion keyword. Then
we can update queues when a new PPD is available, but not
otherwise.
That means that if we add a new dither algorithm or support for a new
paper tray for a particular new printer that we need to bump the minor
release number. That seems a bit too much churn to me.
--
Robert Krawitz <rl...@al...>
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 Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
|
|
From: Michael R S. <ms...@ap...> - 2008-03-28 17:42:22
|
Robert Krawitz wrote:
> ...
> I think it would be really, really (really! :) useful to keep the
> PPD files compatible in micro/patch releases, such that a vendor
> could ship 5.2.x and provide updates without worrying about the PPD
> files changing within that minor release series. Obviously new
> drivers will need new PPDs, but existing drivers shouldn't need
> updated PPDs when you don't add a feature.
>
> Well, we already provide a PPD file generator ("driver") and a script
> to update PPD files. So a distributor who wants to ship an update
> just has to have the postinstall script run cups-genppdupdate.5.2 to
> update the PPD files.
Yes, that's exactly what I'd like to avoid in the general case.
99.9% of all updates do not change the PPDs for existing drivers, so
why should we churn every Gutenprint queue for a simple bug fix?
> ...
> That means that if we add a new dither algorithm or support for a new
> paper tray for a particular new printer that we need to bump the minor
> release number. That seems a bit too much churn to me.
How often do we add dither algorithms or paper trays to existing
printer drivers? If memory serves, you've added only 1 dither
algorithm in the last year and maybe had 1 driver get updated to
support a new tray (for CD printing on Canon printers?)
In the same time, you've added support for a lot of new printers,
and *those* changes did not require new PPDs for things to work.
My point is this - in the general case there will be *less* churn,
and when new features are added there will be the same amount of
churn as we have now.
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer
|
|
From: Robert K. <rl...@al...> - 2008-03-28 23:15:11
|
Date: Fri, 28 Mar 2008 10:42:23 -0700
From: Michael R Sweet <ms...@ap...>
Robert Krawitz wrote:
> ...
> I think it would be really, really (really! :) useful to keep the
> PPD files compatible in micro/patch releases, such that a vendor
> could ship 5.2.x and provide updates without worrying about the PPD
> files changing within that minor release series. Obviously new
> drivers will need new PPDs, but existing drivers shouldn't need
> updated PPDs when you don't add a feature.
>
> Well, we already provide a PPD file generator ("driver") and a script
> to update PPD files. So a distributor who wants to ship an update
> just has to have the postinstall script run cups-genppdupdate.5.2 to
> update the PPD files.
Yes, that's exactly what I'd like to avoid in the general case.
99.9% of all updates do not change the PPDs for existing drivers, so
why should we churn every Gutenprint queue for a simple bug fix?
What's the problem with doing this? The postinstall script can do it
on the fly. It doesn't require rebuilding the queue. In any event,
every upgrade that could possibly be from an earlier minor version
would have to be prepared to do the update anyway.
> ...
> That means that if we add a new dither algorithm or support for a new
> paper tray for a particular new printer that we need to bump the minor
> release number. That seems a bit too much churn to me.
How often do we add dither algorithms or paper trays to existing
printer drivers? If memory serves, you've added only 1 dither
algorithm in the last year and maybe had 1 driver get updated to
support a new tray (for CD printing on Canon printers?)
Well, actually most releases have at least some changes that affect
at least some PPD files (and I'm not including explicit PPD file bug
fixes). We support so many printers (over 800, with something over
150 distinct printer models at last count) that it's very easy for
*something* to have to change. Even adding a new paper type, for
example, causes a PPD file to change.
Looking at the 5.1 release sequence:
In 5.1.7, the following changes needed PPD changes:
* Some of the PictureMates were incorrect (some of them are 4-color
printers, not 6-color).
* Add 2880x2880 and 5760x2880 on C120
* Fix envelope printing on a lot of printers
* Fix paper positioning on many laser printers (needed new input
slots for adjustable guides)
* Add settings for some new RIP parameters
5.1.5:
* Add Ordered New
5.1.4:
* Change paper size for CD - Custom
* Don't use 5760x2880 for automatic quality settings
5.1.3:
* Fix margins for Canon printers
5.1.2:
* Retune Claria-based printers (added some resolutions)
* Extend range of sizes for custom CD printing
5.1.1:
* Rename some Canon printers
* Enable print to CD's for some Canon printers
* Fix resolutions for S300
5.1.0:
* Fix borderless printing (add shrink/crop/expand option)
* Change resolutions on some Canon printers
* Fix roll printing on R800 (maybe)
In the same time, you've added support for a lot of new printers,
and *those* changes did not require new PPDs for things to work.
My point is this - in the general case there will be *less* churn,
and when new features are added there will be the same amount of
churn as we have now.
Well, most of the 5.1 releases (87% -- everything but 5.1.6) have
required at least some PPD files to change for added, changed, or new
features -- not new printers.
--
Robert Krawitz <rl...@al...>
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 Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
|
|
From: Michael R S. <ms...@ap...> - 2008-03-29 16:23:22
|
Robert Krawitz wrote:
> Date: Fri, 28 Mar 2008 10:42:23 -0700
> From: Michael R Sweet <ms...@ap...>
>
> Robert Krawitz wrote:
> > ...
> > I think it would be really, really (really! :) useful to keep the
> > PPD files compatible in micro/patch releases, such that a vendor
> > could ship 5.2.x and provide updates without worrying about the PPD
> > files changing within that minor release series. Obviously new
> > drivers will need new PPDs, but existing drivers shouldn't need
> > updated PPDs when you don't add a feature.
> >
> > Well, we already provide a PPD file generator ("driver") and a script
> > to update PPD files. So a distributor who wants to ship an update
> > just has to have the postinstall script run cups-genppdupdate.5.2 to
> > update the PPD files.
>
> Yes, that's exactly what I'd like to avoid in the general case.
> 99.9% of all updates do not change the PPDs for existing drivers, so
> why should we churn every Gutenprint queue for a simple bug fix?
>
> What's the problem with doing this? The postinstall script can do it
> on the fly. It doesn't require rebuilding the queue. In any event,
> every upgrade that could possibly be from an earlier minor version
> would have to be prepared to do the update anyway.
Most of the time it is extra unnecessary processing...
> ...
> Well, actually most releases have at least some changes that affect
> at least some PPD files (and I'm not including explicit PPD file bug
> fixes). We support so many printers (over 800, with something over
> 150 distinct printer models at last count) that it's very easy for
> *something* to have to change. Even adding a new paper type, for
> example, causes a PPD file to change.
Yes, but adding a paper type shouldn't render existing PPDs
incompatible, and in that case we'd only want to update the PPDs for
that particular driver.
Most of the changes below shouldn't make existing PPDs stop working,
and only affect one class of drivers. It makes more sense to allow
PPDs with the same minor version to continue working, and add a
per-driver version number such that the PPD files would contain:
*FileVersion: "major.minor.driver"
This would allow the PPD upgrade logic to only update those queues
that need it, and we could keep compatibility between minor releases
*without* forced updates.
> Looking at the 5.1 release sequence:
>
> In 5.1.7, the following changes needed PPD changes:
>
> * Some of the PictureMates were incorrect (some of them are 4-color
> printers, not 6-color).
How did this need a PPD change?
> * Add 2880x2880 and 5760x2880 on C120
>
> * Fix envelope printing on a lot of printers
>
> * Fix paper positioning on many laser printers (needed new input
> slots for adjustable guides)
>
> * Add settings for some new RIP parameters
???
> 5.1.5:
>
> * Add Ordered New
>
> 5.1.4:
>
> * Change paper size for CD - Custom
>
> * Don't use 5760x2880 for automatic quality settings
Isn't that decision done in the driver?
> 5.1.3:
>
> * Fix margins for Canon printers
rastertogutenprint already handles margins separately from the PPD
file...
> 5.1.2:
>
> * Retune Claria-based printers (added some resolutions)
>
> * Extend range of sizes for custom CD printing
>
> 5.1.1:
>
> * Rename some Canon printers
This would mean a minor release change with my proposal...
> * Enable print to CD's for some Canon printers
>
> * Fix resolutions for S300
>
> 5.1.0:
>
> * Fix borderless printing (add shrink/crop/expand option)
>
> * Change resolutions on some Canon printers
>
> * Fix roll printing on R800 (maybe)
>
> In the same time, you've added support for a lot of new printers,
> and *those* changes did not require new PPDs for things to work.
>
> My point is this - in the general case there will be *less* churn,
> and when new features are added there will be the same amount of
> churn as we have now.
>
> Well, most of the 5.1 releases (87% -- everything but 5.1.6) have
> required at least some PPD files to change for added, changed, or new
> features -- not new printers.
Right, but few of the changes required a new PPD and most of them
were localized to specific drivers. Also, the focus on 5.1.x has not
been on stability, so a better comparison would be to look at the
changes in 5.0.x.
Anyways, my desire is to see a more frequent stable release cycle for
Gutenprint, which means minimizing the changes that are forced on
users (i.e. unnecessary PPD upgrades) and more structured/incremental
improvements to the core. 5.1.x has been a long-running developer
release that could easily have been 2 "stable" minor releases - 5.1.x
with the new color/driver arch changes and 5.2.x with the new dither
algorithm.
Assuming that we can make every (non-beta) release a stable one, the
PPD versioning and unnecessary updating of PPDs isn't a show-stopper
for me. But I sure would like to minimize "PPD churn" if we can.
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer
|
|
From: Robert K. <rl...@al...> - 2008-03-29 17:57:33
|
Date: Sat, 29 Mar 2008 09:23:22 -0700
From: Michael R Sweet <ms...@ap...>
Robert Krawitz wrote:
> Date: Fri, 28 Mar 2008 10:42:23 -0700
> From: Michael R Sweet <ms...@ap...>
>
> Robert Krawitz wrote:
> > ...
> > I think it would be really, really (really! :) useful to keep the
> > PPD files compatible in micro/patch releases, such that a vendor
> > could ship 5.2.x and provide updates without worrying about the PPD
> > files changing within that minor release series. Obviously new
> > drivers will need new PPDs, but existing drivers shouldn't need
> > updated PPDs when you don't add a feature.
> >
> > Well, we already provide a PPD file generator ("driver") and a script
> > to update PPD files. So a distributor who wants to ship an update
> > just has to have the postinstall script run cups-genppdupdate.5.2 to
> > update the PPD files.
>
> Yes, that's exactly what I'd like to avoid in the general case.
> 99.9% of all updates do not change the PPDs for existing drivers, so
> why should we churn every Gutenprint queue for a simple bug fix?
>
> What's the problem with doing this? The postinstall script can do it
> on the fly. It doesn't require rebuilding the queue. In any event,
> every upgrade that could possibly be from an earlier minor version
> would have to be prepared to do the update anyway.
Most of the time it is extra unnecessary processing...
It takes something less than 1 second per queue (and I have thoughts
about how to reduce that) and can be done completely automatically.
The script we use preserves options wherever possible.
My thought about improving the performance of cups-genppdupdate is to
allow the "cat" command to take multiple URI's on the command line,
and it spits out each of these files in sequence with a zero-length
write (effectively embedded EOF) between each one. I don't know how
critical that would actually be in practice; we haven't received any
complaints about it.
> ...
> Well, actually most releases have at least some changes that affect
> at least some PPD files (and I'm not including explicit PPD file bug
> fixes). We support so many printers (over 800, with something over
> 150 distinct printer models at last count) that it's very easy for
> *something* to have to change. Even adding a new paper type, for
> example, causes a PPD file to change.
Yes, but adding a paper type shouldn't render existing PPDs
incompatible, and in that case we'd only want to update the PPDs
for that particular driver.
Sure, but figuring out which PPD files need updates and which don't is
likely to prove very complex. It's a lot simpler to just update each
and every PPD file, and it avoids problems with possible version skew.
Most of the changes below shouldn't make existing PPDs stop working,
and only affect one class of drivers. It makes more sense to allow
PPDs with the same minor version to continue working, and add a
per-driver version number such that the PPD files would contain:
*FileVersion: "major.minor.driver"
This would allow the PPD upgrade logic to only update those queues
that need it, and we could keep compatibility between minor releases
*without* forced updates.
The update is completely transparent to the user (at least if the user
is using the native CUPS driver -- for Foomatic it's a lot harder).
> Looking at the 5.1 release sequence:
>
> In 5.1.7, the following changes needed PPD changes:
>
> * Some of the PictureMates were incorrect (some of them are 4-color
> printers, not 6-color).
How did this need a PPD change?
Because the 6-color printers offer 3-color, 4-color and 6-color ink
options, while 4-color printers only offer 3-color and 4-color
options. So the 6-color option had to be removed.
> * Add 2880x2880 and 5760x2880 on C120
>
> * Fix envelope printing on a lot of printers
>
> * Fix paper positioning on many laser printers (needed new input
> slots for adjustable guides)
>
> * Add settings for some new RIP parameters
???
The new photo ink transition options.
> 5.1.5:
>
> * Add Ordered New
>
> 5.1.4:
>
> * Change paper size for CD - Custom
>
> * Don't use 5760x2880 for automatic quality settings
Isn't that decision done in the driver?
Yes, but it still has to tell CUPS what resolution each quality
setting corresponds to.
> 5.1.3:
>
> * Fix margins for Canon printers
rastertogutenprint already handles margins separately from the PPD
file...
Yes, but the PPD file has to contain the correct margins.
> 5.1.2:
>
> * Retune Claria-based printers (added some resolutions)
>
> * Extend range of sizes for custom CD printing
>
> 5.1.1:
>
> * Rename some Canon printers
This would mean a minor release change with my proposal...
Which I don't want to have to do for something like that. "Minor
releases" for most software packages are actually quite substantial
(think Linux 2.4->2.6, GIMP 2.2->2.4, CUPS 1.1->1.2). This is not in
the same category as changes like those. A lot of distributions are
willing to do point release updates as patches, but not minor release
updates. I want distributions to do patch updates for things like
that.
> * Enable print to CD's for some Canon printers
>
> * Fix resolutions for S300
>
> 5.1.0:
>
> * Fix borderless printing (add shrink/crop/expand option)
>
> * Change resolutions on some Canon printers
>
> * Fix roll printing on R800 (maybe)
>
> In the same time, you've added support for a lot of new printers,
> and *those* changes did not require new PPDs for things to work.
>
> My point is this - in the general case there will be *less* churn,
> and when new features are added there will be the same amount of
> churn as we have now.
>
> Well, most of the 5.1 releases (87% -- everything but 5.1.6) have
> required at least some PPD files to change for added, changed, or new
> features -- not new printers.
Right, but few of the changes required a new PPD and most of them
were localized to specific drivers. Also, the focus on 5.1.x has
not been on stability, so a better comparison would be to look at
the changes in 5.0.x.
All of the changes I listed do, I believe, require at least some
change to the particular PPD file for the printer or printers
involved.
In practice, 5.1 hasn't been unstable -- a key reason I'm proposing to
go to 5.2 and drop the development release is precisely because 5.0
and 5.1 have been tracking each other very closely. The only things
different between the two releases are that 5.1 doesn't support GIMP
1.2 and 5.0 doesn't have the improved Postscript driver (and that we
dropped the HP inkjets from 5.1, which we're going to undo). I've
tried to be more conscientious about testing 5.0 releases
(e. g. running Valgrind over more stuff), but in practice I try to
valgrind each release, and we added some new testing stuff in 5.1.7,
so in some ways that release was better tested than 5.0.2.
>From the standpoint of CUPS users, there's no meaningful difference
between the two, but it was causing a good bit of confusion.
Anyways, my desire is to see a more frequent stable release cycle
for Gutenprint, which means minimizing the changes that are forced
on users (i.e. unnecessary PPD upgrades) and more
structured/incremental improvements to the core. 5.1.x has been a
long-running developer release that could easily have been 2
"stable" minor releases - 5.1.x with the new color/driver arch
changes and 5.2.x with the new dither algorithm.
The new dither algorithm is a point feature, and the new RIP options
are also point features (it's not a new architecture at all). I'm
hoping to add EvenBetter Screening at some point, and I don't want to
spin the minor release number just for that.
In retrospect, 5.1.x hasn't really even been necessary at all, and I
regret having spun it off right away (in hindsight, it would have been
better to wait until we really wanted to do something destabilizing or
at least substantially new).
Philosophically, I believe that a minor release spin should indicate
*something* substantially new, and a new dither algorithm, or a few
printers being renamed, doesn't make that cut. An example of what I
believe does merit a minor release spin would be addition of color
management -- that's a substantial new capability. A major release
spin really indicates a substantial overhaul, and it's entirely
possible that there never will be a Gutenprint 6.x -- but that's OK.
If Gutenprint 5.2 runs for a few years, and we maintain a reasonable
cadence of point releases for new printers, bug fixes, and the
occasional new feature, that's fine.
Assuming that we can make every (non-beta) release a stable one, the
PPD versioning and unnecessary updating of PPDs isn't a show-stopper
for me. But I sure would like to minimize "PPD churn" if we can.
I'd like to understand better your concern about PPD churn. I don't
see that it's a big deal to "run cups-genppdupdate whenever you
install Gutenprint". The user doesn't have to do anything else. When
installing from a binary package, the package installer can run the
script as a postinstall, completely transparently (it skips PPD files
that aren't Gutenprint ones). Of course, that doesn't address
Foomatic users, but since Foomatic creates its own PPD files we don't
(safely) know how to upgrade them.
It's not acceptable to me that a change that requires even a single
PPD file to change (such as adding a new input slot to one particular
printer) would require a minor version spin. That said, if you can
propose a way to identify which PPD files need updating from one point
release to another I'm willing to entertain it. I'm concerned,
though, that something like that is likely to prove complicated to
implement (and error-prone for that reason) while not being much
easier for users. Telling a user "if you're upgrading from 5.2.2 to
5.2.3, you have to upgrade PPD files for these printers, while if
you're going from 5.2.1 to 5.2.3, you have to upgrade PPD files for
these other printers" doesn't seem very helpful either. But I'm open
to a proposal; maybe you see something I don't.
--
Robert Krawitz <rl...@al...>
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 Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
|
|
From: Michael R S. <ms...@ap...> - 2008-03-29 18:43:57
|
Robert Krawitz wrote:
> ..
> Assuming that we can make every (non-beta) release a stable one, the
> PPD versioning and unnecessary updating of PPDs isn't a show-stopper
> for me. But I sure would like to minimize "PPD churn" if we can.
>
> I'd like to understand better your concern about PPD churn. I don't
> see that it's a big deal to "run cups-genppdupdate whenever you
> install Gutenprint". The user doesn't have to do anything else. When
> installing from a binary package, the package installer can run the
> script as a postinstall, completely transparently (it skips PPD files
> that aren't Gutenprint ones). Of course, that doesn't address
> Foomatic users, but since Foomatic creates its own PPD files we don't
> (safely) know how to upgrade them.
My issue isn't specifically with the update of the PPD file, it is
with the unnecessary tight coupling of the PPD version to the driver.
> It's not acceptable to me that a change that requires even a single
> PPD file to change (such as adding a new input slot to one particular
> printer) would require a minor version spin.
I'm not proposing that, I'm only proposing that we bump the minor
version any time we make an incompatible change to PPD files (where
"incompatible change" means that the old PPD file will not work at all
with the updated driver), and only require that the major and minor
versions in a PPD file match Gutenprint's major and minor version.
> That said, if you can
> propose a way to identify which PPD files need updating from one point
> release to another I'm willing to entertain it.
Use:
*FileVersion: "major.minor.driver"
The "driver" version would ideally be per-printer, but even per-driver
(escp2, pcl, etc.) would be useful in identifying the minimum version
needed by the PPD file and whether the PPD was compatible with the
currently installed driver. It would still support upgrades of
Gutenprint PPDs by cups-genppdupdate and be compatible with the driver
update functionality built into Mac OS X.
> I'm concerned,
> though, that something like that is likely to prove complicated to
> implement (and error-prone for that reason) while not being much
> easier for users. Telling a user "if you're upgrading from 5.2.2 to
> 5.2.3, you have to upgrade PPD files for these printers, while if
> you're going from 5.2.1 to 5.2.3, you have to upgrade PPD files for
> these other printers" doesn't seem very helpful either. But I'm open
> to a proposal; maybe you see something I don't.
What we do on Mac OS X is compare the PCFileName and FileVersion of
the installed PPDs with the PPDs for each printer queue. If the
PCFileName is the same and FileVersion is newer, we'll update the
queue. Otherwise, we leave it alone. For software updates, we only
show the updated driver if it matches a queue that is on the system.
The current Gutenprint PPD versioning requires that we update every
queue, even if the only change is to the version number. Thus, if
Gutenprint 5.2.3 adds support for a new Canon printer, but a user
only has Epson printers, they will still see, download, and install
the Gutenprint driver update even if they don't need it.
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer
|
|
From: Robert K. <rl...@al...> - 2008-03-29 20:16:00
|
Date: Sat, 29 Mar 2008 11:43:46 -0700 From: Michael R Sweet <ms...@ap...> Robert Krawitz wrote: > .. > Assuming that we can make every (non-beta) release a stable one, the > PPD versioning and unnecessary updating of PPDs isn't a show-stopper > for me. But I sure would like to minimize "PPD churn" if we can. > > I'd like to understand better your concern about PPD churn. I don't > see that it's a big deal to "run cups-genppdupdate whenever you > install Gutenprint". The user doesn't have to do anything else. When > installing from a binary package, the package installer can run the > script as a postinstall, completely transparently (it skips PPD files > that aren't Gutenprint ones). Of course, that doesn't address > Foomatic users, but since Foomatic creates its own PPD files we don't > (safely) know how to upgrade them. My issue isn't specifically with the update of the PPD file, it is with the unnecessary tight coupling of the PPD version to the driver. And again, I don't understand what problems this admittedly tight coupling causes. > It's not acceptable to me that a change that requires even a > single PPD file to change (such as adding a new input slot to one > particular printer) would require a minor version spin. I'm not proposing that, I'm only proposing that we bump the minor version any time we make an incompatible change to PPD files (where "incompatible change" means that the old PPD file will not work at all with the updated driver), and only require that the major and minor versions in a PPD file match Gutenprint's major and minor version. Well, if we remove a resolution setting on a particular printer because it won't work, that means that the old PPD file won't work with the new driver. As we've been doing it, removing a particular option setting because it doesn't work correctly is an acceptable change between point versions (we don't commit to having all option choices remain identical between point releases). For that matter, if we add a new option, and a user didn't upgrade the PPD file, they'd get a new driver with a new capability but not be able to use it because the PPD file doesn't have a record of it. > That said, if you can > propose a way to identify which PPD files need updating from one point > release to another I'm willing to entertain it. Use: *FileVersion: "major.minor.driver" The "driver" version would ideally be per-printer, but even per-driver (escp2, pcl, etc.) would be useful in identifying the minimum version needed by the PPD file and whether the PPD was compatible with the currently installed driver. It would still support upgrades of Gutenprint PPDs by cups-genppdupdate and be compatible with the driver update functionality built into Mac OS X. If that's what it sounds like, it's going to be very hard to manage -- it means that whenever anyone changes anything they have to think about whether it would change the PPD file, and also whether the change is back compatible (at the PPD file level) or not. I think that that's an unnecessarily stringent restriction and is likely to lead to confusion -- all it takes is one developer not keeping track of exactly when a change was made that affects a PPD file, and some user isn't able to print and we have to spend a lot of time tracking down the fact that it's because she used an option setting that isn't actually available in the version of Gutenprint she installed. > I'm concerned, > though, that something like that is likely to prove complicated to > implement (and error-prone for that reason) while not being much > easier for users. Telling a user "if you're upgrading from 5.2.2 to > 5.2.3, you have to upgrade PPD files for these printers, while if > you're going from 5.2.1 to 5.2.3, you have to upgrade PPD files for > these other printers" doesn't seem very helpful either. But I'm open > to a proposal; maybe you see something I don't. What we do on Mac OS X is compare the PCFileName and FileVersion of the installed PPDs with the PPDs for each printer queue. If the PCFileName is the same and FileVersion is newer, we'll update the queue. Otherwise, we leave it alone. For software updates, we only show the updated driver if it matches a queue that is on the system. "When" do you do this? If the user installs a new version of Gutenprint, our packaging takes care to run cups-genppdupdate. If OS X bundles a version (or you release an update), it should take care to run cups-genppdupdate itself. The README recommends that packagers do precisely this. In any case, the algorithm you describe won't work with Gutenprint. The PCFileName is not stable. It's simply an arbitrary number (that happens to be the position of the printer inside printers.xml) that could change between releases if new printers are added (STPxxxxx.PPD). I don't like this whole PCFileName thing myself -- I think that 8+3 is absurd in this day and age -- and the only reason we have it in there is because it's required by the PPD file spec. We actually look at the *NickName and *StpPPDLocation, which is a custom attribute that doesn't have any of these limitations. The current Gutenprint PPD versioning requires that we update every queue, even if the only change is to the version number. Thus, if Gutenprint 5.2.3 adds support for a new Canon printer, but a user only has Epson printers, they will still see, download, and install the Gutenprint driver update even if they don't need it. What's the context here? Is this some kind of automatic system update, or when the user downloads and installs Gutenprint? I feel like I don't understand what the issue is, since upgrading PPD files is a trivial operation with Gutenprint. In any case, Gutenprint 5.2.3 might also include a fix for their Epson printer that isn't reflected in the PPD file, so they should still take the update. PPD files are still somewhat of a bolt-on with Gutenprint, and I'm well aware that there are impedance mismatches galore. But then again, you know my opinion of PPD files in general -- I believe that about two years ago I spent a slide or two railing against them. -- Robert Krawitz <rl...@al...> 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 Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Michael R S. <ms...@ap...> - 2008-03-31 18:16:22
|
Robert Krawitz wrote: > Date: Sat, 29 Mar 2008 11:43:46 -0700 > From: Michael R Sweet <ms...@ap...> > > Robert Krawitz wrote: > > .. > > Assuming that we can make every (non-beta) release a stable one, the > > PPD versioning and unnecessary updating of PPDs isn't a show-stopper > > for me. But I sure would like to minimize "PPD churn" if we can. > > > > I'd like to understand better your concern about PPD churn. I don't > > see that it's a big deal to "run cups-genppdupdate whenever you > > install Gutenprint". The user doesn't have to do anything else. When > > installing from a binary package, the package installer can run the > > script as a postinstall, completely transparently (it skips PPD files > > that aren't Gutenprint ones). Of course, that doesn't address > > Foomatic users, but since Foomatic creates its own PPD files we don't > > (safely) know how to upgrade them. > > My issue isn't specifically with the update of the PPD file, it is > with the unnecessary tight coupling of the PPD version to the > driver. > > And again, I don't understand what problems this admittedly tight > coupling causes. This is mainly a Mac OS X thing, but if we are going to provide software updates for Gutenprint, we *do not* want to show the update to the user unless they are using a driver that has been actually updated. Right now we use the PPD's PCFileName and FileVersion information to know whether the driver in software update is newer than the one on the local system. This works fine for every commercial printer driver and most open source drivers, just not Gutenprint. > ... > Well, if we remove a resolution setting on a particular printer > because it won't work, that means that the old PPD file won't work > with the new driver. Why? I understand that a particular option may no longer work, but why will the entire PPD not work? > As we've been doing it, removing a particular > option setting because it doesn't work correctly is an acceptable > change between point versions (we don't commit to having all option > choices remain identical between point releases). For that matter, if > we add a new option, and a user didn't upgrade the PPD file, they'd > get a new driver with a new capability but not be able to use it > because the PPD file doesn't have a record of it. I agree that we want to update a PPD when the PPD changes. However, forcing a change to all PPDs even when the only change is to the version number in the file leads to unnecessary updates. You don't see this problem on Linux because Linux software updates are *not* fine-grained - if you have the software installed, then it gets updated. And in fact many distros require all drivers to be installed, which means unnecessary updates to software the user doesn't need or want. I know this isn't specifically a Gutenprint problem, but I don't see how providing a little more stability and finer-grained versioning (at least at the "escp2", "pcl", "canon", etc. level) can be a burden to implement and maintain. > > That said, if you can > > propose a way to identify which PPD files need updating from one point > > release to another I'm willing to entertain it. > > Use: > > *FileVersion: "major.minor.driver" > > The "driver" version would ideally be per-printer, but even per-driver > (escp2, pcl, etc.) would be useful in identifying the minimum version > needed by the PPD file and whether the PPD was compatible with the > currently installed driver. It would still support upgrades of > Gutenprint PPDs by cups-genppdupdate and be compatible with the driver > update functionality built into Mac OS X. > > If that's what it sounds like, it's going to be very hard to manage -- > it means that whenever anyone changes anything they have to think > about whether it would change the PPD file, and also whether the > change is back compatible (at the PPD file level) or not. No, it doesn't need to be that specific. Just if "I changed the Canon driver, so I bump the Canon driver version number by 1". *You* know what drivers have been updated when you do a release, otherwise you wouldn't be able to create your release notes. I'm just asking for versioning of the drivers, not whether the PPDs have actually changed. > ... > What we do on Mac OS X is compare the PCFileName and FileVersion of > the installed PPDs with the PPDs for each printer queue. If the > PCFileName is the same and FileVersion is newer, we'll update the > queue. Otherwise, we leave it alone. For software updates, we only > show the updated driver if it matches a queue that is on the system. > > "When" do you do this? If the user installs a new version of > Gutenprint, our packaging takes care to run cups-genppdupdate. If OS > X bundles a version (or you release an update), it should take care to > run cups-genppdupdate itself. The README recommends that packagers do > precisely this. When you download a software update for printer drivers, we run the postinstall script provided with the driver package to update any queues associated with that driver package. So, if we do provide a Gutenprint update in Mac OS X, we will likely run the cups-genppdupdate script to do the update. The kicker is that we need to know what driver used for a printer, and the version of that driver, to know whether we need to present the software update to the user. I *think* we can get the correct info with the current Gutenprint PPD keywords, however the issue right now is that we'll always update Gutenprint even if their particular printer wasn't updated. > In any case, the algorithm you describe won't work with Gutenprint. > The PCFileName is not stable. It's simply an arbitrary number (that > happens to be the position of the printer inside printers.xml) that > could change between releases if new printers are added > (STPxxxxx.PPD). I don't like this whole PCFileName thing myself -- I > think that 8+3 is absurd in this day and age -- and the only reason we > have it in there is because it's required by the PPD file spec. We > actually look at the *NickName and *StpPPDLocation, which is a custom > attribute that doesn't have any of these limitations. It would be nice (for 5.2) to assign unique numbers to each of the Gutenprint drivers so that PCFileName *could* be stable across releases - it would also make updates simpler in the future since we'll have direct support for it in CUPS. > The current Gutenprint PPD versioning requires that we update every > queue, even if the only change is to the version number. Thus, if > Gutenprint 5.2.3 adds support for a new Canon printer, but a user > only has Epson printers, they will still see, download, and install > the Gutenprint driver update even if they don't need it. > > What's the context here? Is this some kind of automatic system > update, or when the user downloads and installs Gutenprint? It's an automatic system update - we know the user has a Canon printer using a Gutenprint driver, so we look for updates to the Gutenprint Canon drivers. > I feel > like I don't understand what the issue is, since upgrading PPD files > is a trivial operation with Gutenprint. In any case, Gutenprint 5.2.3 > might also include a fix for their Epson printer that isn't reflected > in the PPD file, so they should still take the update. Right, again the versioning is based on the driver, *not* the PPD file and whether it has changed. I'm not suggesting that we tie updates to PPD files or that we don't update PPDs once we've installed a new version. It is all about knowing when an update affects an existing printer and limiting when we download and install those updates accordingly. -- ______________________________________________________________________ Michael R Sweet Senior Printing System Engineer |
|
From: Robert K. <rl...@al...> - 2008-03-30 17:34:13
|
Date: Sat, 29 Mar 2008 16:15:58 -0400
From: Robert Krawitz <rl...@al...>
Date: Sat, 29 Mar 2008 11:43:46 -0700
From: Michael R Sweet <ms...@ap...>
Robert Krawitz wrote:
> That said, if you can
> propose a way to identify which PPD files need updating from one point
> release to another I'm willing to entertain it.
Use:
*FileVersion: "major.minor.driver"
The "driver" version would ideally be per-printer, but even
per-driver (escp2, pcl, etc.) would be useful in identifying the
minimum version needed by the PPD file and whether the PPD was
compatible with the currently installed driver. It would still
support upgrades of Gutenprint PPDs by cups-genppdupdate and be
compatible with the driver update functionality built into Mac
OS X.
If that's what it sounds like, it's going to be very hard to manage
-- it means that whenever anyone changes anything they have to
think about whether it would change the PPD file, and also whether
the change is back compatible (at the PPD file level) or not. I
think that that's an unnecessarily stringent restriction and is
likely to lead to confusion -- all it takes is one developer not
keeping track of exactly when a change was made that affects a PPD
file, and some user isn't able to print and we have to spend a lot
of time tracking down the fact that it's because she used an option
setting that isn't actually available in the version of Gutenprint
she installed.
I suspect that my initial comment may not have been very clear, and
perhaps I haven't been very clear from the outset what my concerns
are.
The basic issue, to my mind, is that there are a lot of things that
can result in a PPD file changing. In some cases, it will be
something that affects substantially everything -- offering a new
color option, a new dither algorithm, or the like. I don't agree that
every such case merits bumping the minor version number, which isn't
really all that "minor" in common usage. If anything, rather than
"major.minor.point", I'd say that the de facto usage is
"architecture.major.minor". Adding a new dither algorithm is not a
"major" change, at least by my philosophy (ideally we'd have a good
modular architecture that would make it easy to add such things as
addons). However, I'll concede the point for the sake of discussion.
There are other changes, though, that result in user-visible option
changes for either families of printers or for individual printers or
small sets. Examples might include adding a new input slot, paper
type, ink set (e. g. adding support for a particular quadtone ink
set), or the like. This results in one or more PPD files changing,
and I certainly don't think that this could realistically be
considered sufficient to change the second digit of a release number,
since most 5.x releases have resulted in at least a few such changes.
If we were to do that, we'd still be upgrading PPD files with every
release, but we'd wind up with serious release inflation.
People have a general concept that a change to major release number
really means a substantial revamp (think KDE3 vs. KDE4, or Mac OS 9
vs. OS X), a minor release means substantial enhancements within an
existing framework, and a point release means bug fixes and minor
enhancements. We've already established that adding a new printer (or
even a substantial set of new printers) constitutes only a relatively
small enhancement, and I don't see that adding an enhancement (even a
significant one) to such a set of printers could be considered
anything more (does it really make sense that adding an input slot is
more important than adding the printer that uses it?).
Given this, my request wasn't about how Gutenprint could identify *to
CUPS* which PPD files need changing in a given release, but rather how
the Gutenprint project itself could identify *internally* which PPD
files need updating between any given pair of releases (remember that
users might jump directly from 5.2.1 to 5.2.3, for example). We could
presumably keep golden PPD files from each release around and compare
them for non-trivial changes, but that seems like a huge amount of
work for any potential benefit to be had. But currently we don't keep
records at that level of what changes from release to release, and
that kind of record-keeping would be both burdensome and error-prone
(i. e. it relies on people to keep careful track of everything).
There are times and places for that, but it's not clear to me that
this is one of them. It's simple and foolproof to just state that
every change in version requires PPD file upgrades, and we've also
made it very simple to actually do this (use cups-genppdupdate). You
appear to be asserting that this is problematic in some way; I just
don't understand that.
Remember that Gutenprint isn't based around PPD files, but around a
much more fluid internal option system for which we generate PPD files
to generate.
|
|
From: Michael R S. <ms...@ap...> - 2008-03-31 18:36:13
|
Robert Krawitz wrote: > ... > I suspect that my initial comment may not have been very clear, and > perhaps I haven't been very clear from the outset what my concerns > are. and I suspect that I haven't been very clear, either... :( > The basic issue, to my mind, is that there are a lot of things that > can result in a PPD file changing. In some cases, it will be > something that affects substantially everything -- offering a new > color option, a new dither algorithm, or the like. I don't agree that > every such case merits bumping the minor version number, which isn't > ... That's not the core point I was trying to make, but rather to get agreement and documentation on our policies going forward. Much as happened with the CUPS 1.2 and 1.3 releases, defining and sticking to a written Gutenprint development policy should make things easier on you and provide a focus for new development. As a happy side-effect, it will be easier for users since they just need to download the latest release. I also believe that this could allow for more frequent updates with fewer changes... Driver versioning separate from release versioning is just a way to improve the user's experience on platforms that provide fine- grained software updates. You (obviously) don't have to do it, but IMHO it shouldn't be hard to do at the medium-grain level (all canon drivers are driver version X, all epson drivers are version Y, etc.) > There are other changes, though, that result in user-visible option > changes for either families of printers or for individual printers or > small sets. Examples might include adding a new input slot, paper > type, ink set (e. g. adding support for a particular quadtone ink > set), or the like. This results in one or more PPD files changing, > and I certainly don't think that this could realistically be > considered sufficient to change the second digit of a release number, > since most 5.x releases have resulted in at least a few such changes. > If we were to do that, we'd still be upgrading PPD files with every > release, but we'd wind up with serious release inflation. First, so what? What's wrong with big minor release numbers? Second, most of these changes do *not* require incompatible changes to be made, and so would not require a minor version bump, just a driver version bump and an updated PPD. > People have a general concept that a change to major release number > really means a substantial revamp (think KDE3 vs. KDE4, or Mac OS 9 > vs. OS X), a minor release means substantial enhancements within an > existing framework, and a point release means bug fixes and minor > enhancements. > ... That really depends on the project. All of those projects have documentation on what major, minor, and point releases may contain, so it is a known entity. With Gutenprint, a user could guess that "stable" point releases only contain bug fixes and new printer drivers, while "developer" point releases are a free-for-all. In reality, many users and developers do not understand the stable/developer split which directly lead to Apple shipping a developer release instead of a stable release. Note that I'm not playing the blame game here, I'm just pointing out that what *you* believe is the general understanding is not necessarily what everyone else believes, and the current situation with Gutenprint is just plain confusing. Confusing means that we can't do updates to Gutenprint in Mac OS X, which means a lot of users stuck with old versions of Gutenprint or using unsupported releases they download from the Gutenprint site. So, WRT versioning, let's define what we want to do for Gutenprint source and driver versions and what they mean, and then use those starting with 5.2. -- ______________________________________________________________________ Michael R Sweet Senior Printing System Engineer |
|
From: Robert K. <rl...@al...> - 2008-04-01 00:13:45
|
Date: Mon, 31 Mar 2008 11:36:08 -0700 From: Michael R Sweet <ms...@ap...> Robert Krawitz wrote: > ... > I suspect that my initial comment may not have been very clear, and > perhaps I haven't been very clear from the outset what my concerns > are. and I suspect that I haven't been very clear, either... :( <shrug>It happens, that's why we discuss it.</shrug> No harm done. > The basic issue, to my mind, is that there are a lot of things that > can result in a PPD file changing. In some cases, it will be > something that affects substantially everything -- offering a new > color option, a new dither algorithm, or the like. I don't agree that > every such case merits bumping the minor version number, which isn't > ... That's not the core point I was trying to make, but rather to get agreement and documentation on our policies going forward. Much as happened with the CUPS 1.2 and 1.3 releases, defining and sticking to a written Gutenprint development policy should make things easier on you and provide a focus for new development. As a happy side-effect, it will be easier for users since they just need to download the latest release. I also believe that this could allow for more frequent updates with fewer changes... At least in principle, we do have fairly clear (but not entirely rigid) guidelines -- real API breakers should be major releases, major incompatible enhancements should be minor releases, and bug fixes, new printers, and upward compatible new features are point releases. I don't think we disagree with any of this in principle, but we might not agree on the specifics or how strict to be. Driver versioning separate from release versioning is just a way to improve the user's experience on platforms that provide fine- grained software updates. You (obviously) don't have to do it, but IMHO it shouldn't be hard to do at the medium-grain level (all canon drivers are driver version X, all epson drivers are version Y, etc.) I'm concerned about the mechanics of doing this in a reasonably foolproof manner. For family drivers that are a single file, we can always use the CVS version, but that won't work for drivers like the Epson driver (about 6 separate source files). Expecting people to remember to manually increment a version number when they check in a file is error-prone. Also note that manufacturer doesn't always line up with family driver. For example, Canon printers are represented in the Canon inkjet family, the dyesub family, and the PCL family (laser printers). Maybe that doesn't matter, but be aware of it. > There are other changes, though, that result in user-visible option > changes for either families of printers or for individual printers or > small sets. Examples might include adding a new input slot, paper > type, ink set (e. g. adding support for a particular quadtone ink > set), or the like. This results in one or more PPD files changing, > and I certainly don't think that this could realistically be > considered sufficient to change the second digit of a release number, > since most 5.x releases have resulted in at least a few such changes. > If we were to do that, we'd still be upgrading PPD files with every > release, but we'd wind up with serious release inflation. First, so what? What's wrong with big minor release numbers? I don't like it. Version numbers like 5.20.1 suggest to me that the product is either going out of its way to bump the minor number (to suggest more change than there is) or is trying to avoid bumping the major number. 5.1.20 suggests a lot of patches or minor updates in an otherwise stable release sequence. I guess I just prefer that. It's a matter of taste. Also, a lot of distribution vendors are willing to release patches, but not new minor releases, within the lifetime of a product release. Also, in my experience a lot of users are uncomfortable with minor version upgrades. I want to manage that discomfort appropriately -- someone shouldn't be uncomfortable about a new dither algorithm being added, but should be uncomfortable about a significant change to the color correction. Second, most of these changes do *not* require incompatible changes to be made, and so would not require a minor version bump, just a driver version bump and an updated PPD. Again, what do you mean by "incompatible" change? > People have a general concept that a change to major release number > really means a substantial revamp (think KDE3 vs. KDE4, or Mac OS 9 > vs. OS X), a minor release means substantial enhancements within an > existing framework, and a point release means bug fixes and minor > enhancements. > ... That really depends on the project. All of those projects have documentation on what major, minor, and point releases may contain, so it is a known entity. With Gutenprint, a user could guess that "stable" point releases only contain bug fixes and new printer drivers, while "developer" point releases are a free-for-all. In reality, many users and developers do not understand the stable/developer split which directly lead to Apple shipping a developer release instead of a stable release. Note that I'm not playing the blame game here, I'm just pointing out that what *you* believe is the general understanding is not necessarily what everyone else believes, and the current situation with Gutenprint is just plain confusing. Confusing means that we can't do updates to Gutenprint in Mac OS X, which means a lot of users stuck with old versions of Gutenprint or using unsupported releases they download from the Gutenprint site. Yes, it is confusing, and that's why I want to move to 5.2. So, WRT versioning, let's define what we want to do for Gutenprint source and driver versions and what they mean, and then use those starting with 5.2. -- Robert Krawitz <rl...@al...> 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 Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Michael R S. <ms...@ap...> - 2008-04-01 17:46:48
|
Robert Krawitz wrote: > ... > I'm concerned about the mechanics of doing this in a reasonably > foolproof manner. For family drivers that are a single file, we can > always use the CVS version, but that won't work for drivers like the > Epson driver (about 6 separate source files). Expecting people to > remember to manually increment a version number when they check in a > file is error-prone. It would be once per release, and that could be automated quite easily. > Also note that manufacturer doesn't always line up with family > driver. For example, Canon printers are represented in the Canon > inkjet family, the dyesub family, and the PCL family (laser > printers). Maybe that doesn't matter, but be aware of it. Right, but we can let the PPD file reflect the version of the family driver it is associated with - the key is just tracking the family driver version number, and that *can* be automated by detecting changes to the CVS versions of the corresponding source files. > ... > First, so what? What's wrong with big minor release numbers? > > I don't like it. Version numbers like 5.20.1 suggest to me that the > product is either going out of its way to bump the minor number (to > suggest more change than there is) or is trying to avoid bumping the > major number. 5.1.20 suggests a lot of patches or minor updates in an > otherwise stable release sequence. I guess I just prefer that. It's > a matter of taste. > > Also, a lot of distribution vendors are willing to release patches, > but not new minor releases, within the lifetime of a product release. Understood, but vendors are also uncomfortable with big changes in a point release - that's why we aren't doing Gutenprint 5.1.x driver updates. IMHO, new dither algorithms, global color management changes (i.e. color tweaks that affect all drivers), and API changes warrant a minor version bump, while other smaller changes, bug fixes, and new drivers can be a patch/point release. WRT to the 5.1.x lineage, we would have already had a 5.2.x series - not a lot of version inflation, but very clear that a significant new feature was added. > Also, in my experience a lot of users are uncomfortable with minor > version upgrades. I want to manage that discomfort appropriately -- > someone shouldn't be uncomfortable about a new dither algorithm being > added, but should be uncomfortable about a significant change to the > color correction. ... but a new dither algorithm often exposes color changes, especially if that new algorithm gets selected by the "simplified" PPDs. > Second, most of these changes do *not* require incompatible > changes to be made, and so would not require a minor version > bump, just a driver version bump and an updated PPD. > > Again, what do you mean by "incompatible" change? I'm talking about globals changes to the PPD (say, a new required attribute that is used by the driver), new dither algorithms, global color management changes, and driver API changes that affect the ability to print or the output that is produced. In short, an upgrade from 5.2.0 to 5.2.1 should not significantly change the output you get from a particular driver, but 5.2.1 to 5.3.0 could. Similarly, an application written to use the Gutenprint API should continue to work (at least) for all point releases, but might require changes between minor releases. -- ______________________________________________________________________ Michael R Sweet Senior Printing System Engineer |
|
From: Robert K. <rl...@al...> - 2008-04-01 00:48:22
|
Date: Mon, 31 Mar 2008 11:16:23 -0700
From: Michael R Sweet <ms...@ap...>
MIME-Version: 1.0
CC: gim...@li..., rl...@wh...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Robert Krawitz wrote:
> Date: Sat, 29 Mar 2008 11:43:46 -0700
> From: Michael R Sweet <ms...@ap...>
>
> Robert Krawitz wrote:
> > ..
> > Assuming that we can make every (non-beta) release a stable one, the
> > PPD versioning and unnecessary updating of PPDs isn't a show-stopper
> > for me. But I sure would like to minimize "PPD churn" if we can.
> >
> > I'd like to understand better your concern about PPD churn. I don't
> > see that it's a big deal to "run cups-genppdupdate whenever you
> > install Gutenprint". The user doesn't have to do anything else. When
> > installing from a binary package, the package installer can run the
> > script as a postinstall, completely transparently (it skips PPD files
> > that aren't Gutenprint ones). Of course, that doesn't address
> > Foomatic users, but since Foomatic creates its own PPD files we don't
> > (safely) know how to upgrade them.
>
> My issue isn't specifically with the update of the PPD file, it is
> with the unnecessary tight coupling of the PPD version to the
> driver.
>
> And again, I don't understand what problems this admittedly tight
> coupling causes.
This is mainly a Mac OS X thing, but if we are going to provide
software updates for Gutenprint, we *do not* want to show the
update to the user unless they are using a driver that has been
actually updated.
Right now we use the PPD's PCFileName and FileVersion information
to know whether the driver in software update is newer than the one
on the local system. This works fine for every commercial printer
driver and most open source drivers, just not Gutenprint.
>From my standpoint, it's a scaling problem. We support almost 900
printers made by who knows how many vendors in 5 different families.
The only other driver (proprietary or free) I'm aware of that's even
close to that is HPIJS, and their task is a bit simpler because
they're only supporting one vendor's printers. Well, there's also
OMNI, but I'm not aware that they're releasing anything. 8.3 naming
when the first three positions are taken up by our tag (STP) leaves
only 5 free bytes. Figure that we have about 900 printers, with 18
languages and simplified vs. full-featured PPD files, and we have to
use those 5 bytes rather densely. What is HPIJS doing in this regard,
by the way?
Personally, I think 8.3 naming is an abomination, pure and simple.
Even Windows had long file names well over a decade ago. The Mac
never had this, and UNIX got rid of of it 30 some odd years ago. We
support entirely too many printers and variants to be able to use this
in any stable manner.
> ...
> Well, if we remove a resolution setting on a particular printer
> because it won't work, that means that the old PPD file won't work
> with the new driver.
Why? I understand that a particular option may no longer work,
but why will the entire PPD not work?
Well, say we get rid of 1440x720 highest quality, and the user selects
it -- the print operation will fail, with a somewhat cryptic error.
I know this isn't specifically a Gutenprint problem, but I don't
see how providing a little more stability and finer-grained
versioning (at least at the "escp2", "pcl", "canon", etc. level)
can be a burden to implement and maintain.
> > That said, if you can
> > propose a way to identify which PPD files need updating from one point
> > release to another I'm willing to entertain it.
>
> Use:
>
> *FileVersion: "major.minor.driver"
>
> The "driver" version would ideally be per-printer, but even per-driver
> (escp2, pcl, etc.) would be useful in identifying the minimum version
> needed by the PPD file and whether the PPD was compatible with the
> currently installed driver. It would still support upgrades of
> Gutenprint PPDs by cups-genppdupdate and be compatible with the driver
> update functionality built into Mac OS X.
>
> If that's what it sounds like, it's going to be very hard to manage --
> it means that whenever anyone changes anything they have to think
> about whether it would change the PPD file, and also whether the
> change is back compatible (at the PPD file level) or not.
No, it doesn't need to be that specific. Just if "I changed the
Canon driver, so I bump the Canon driver version number by 1".
*You* know what drivers have been updated when you do a release,
otherwise you wouldn't be able to create your release notes. I'm
just asking for versioning of the drivers, not whether the PPDs
have actually changed.
If a driver consists of a single source file, this isn't that hard to
do -- just use the RCS version, which can be done automatically. But
this won't work for family drivers like the Canon and Epson inkjet
that consist of multiple source files. Somebody has to remember to
manually uprev the version somewhere, which is easy to forget in the
heat of battle and isn't easy for the tools to check as part of the
build process. I suppose we could write a script to grovel the change
log, but that seems like a lot of work and that itself is likely to be
error-prone in its own way.
> What we do on Mac OS X is compare the PCFileName and FileVersion of
> the installed PPDs with the PPDs for each printer queue. If the
> PCFileName is the same and FileVersion is newer, we'll update the
> queue. Otherwise, we leave it alone. For software updates, we only
> show the updated driver if it matches a queue that is on the system.
>
> "When" do you do this? If the user installs a new version of
> Gutenprint, our packaging takes care to run cups-genppdupdate. If OS
> X bundles a version (or you release an update), it should take care to
> run cups-genppdupdate itself. The README recommends that packagers do
> precisely this.
When you download a software update for printer drivers, we run
the postinstall script provided with the driver package to update
any queues associated with that driver package. So, if we do
provide a Gutenprint update in Mac OS X, we will likely run the
cups-genppdupdate script to do the update.
The kicker is that we need to know what driver used for a printer,
and the version of that driver, to know whether we need to present
the software update to the user. I *think* we can get the correct
info with the current Gutenprint PPD keywords, however the issue
right now is that we'll always update Gutenprint even if their
particular printer wasn't updated.
I believe I understand the issue, but it's not clear to me how to fix
it in a foolproof way. Perhaps you might have a suggestion?
> In any case, the algorithm you describe won't work with Gutenprint.
> The PCFileName is not stable. It's simply an arbitrary number (that
> happens to be the position of the printer inside printers.xml) that
> could change between releases if new printers are added
> (STPxxxxx.PPD). I don't like this whole PCFileName thing myself -- I
> think that 8+3 is absurd in this day and age -- and the only reason we
> have it in there is because it's required by the PPD file spec. We
> actually look at the *NickName and *StpPPDLocation, which is a custom
> attribute that doesn't have any of these limitations.
It would be nice (for 5.2) to assign unique numbers to each of the
Gutenprint drivers so that PCFileName *could* be stable across
releases - it would also make updates simpler in the future since
we'll have direct support for it in CUPS.
PCFileName just flat out doesn't scale because of the 8.3 limitation.
I'm perfectly happy to break the 8.3 by using the entire printer tag
name, with a driver prefix (stp in the case of Gutenprint;
e. g. stp-escp2-picmated.ppd), but I suspect that that would cause
other problems. Another way around this would be to come up with a
different tag that doesn't have this kind of artificial limitation.
BTW, I'd argue that this use of *PCFileName isn't exactly in accord
with the spec:
Note To builders of PPD files: If a released PPD file is
changed, but the product itself has not changed, the PPD
file name (and *PCFileName) will not change. Examples of
this type of change to a PPD file include, but are not
limited to, fixing a typographical error in the PPD file,
fixing an incorrect value for *FreeVM, fixing feature
code that was not tested properly and has been found to
be incorrect, adding or changing translation strings,
changing the names of option keywords, removing a keyword
that was never supported by the device, and fixing
incorrect information in a *Font statement.
If a released PPD file is changed because the product
itself has changed, the upgraded product must be issued a
new PPD file with a new name. Any new features must be
thoroughly tested. If the "old" and "upgraded" products
are substantially the same product, marketed under
similar names, Adobe recom- mends keeping the filenames
substantially the same, but using the 8th charac- ter of
the new filename as a version number for the file. For
example, if the Acme SpiffyPrinter is upgraded with more
memory, you might change ACSPIFFY.PPD to
ACSPIFF2.PPD. Using the 8th character as a version number
is a recommendation of common practice, but is not a
requirement of this specification. If the "old" and
"upgraded" products are substantially dif- ferent, or
marketed under different names, you should give the new
PPD file a unique name that corresponds as closely as
possible to the name under which the product is marketed.
Not that what we're doing conforms either, but this suggests to me
that if anything the PCFileName is expected to change between releases
("must be issued a new PPD file with a new name").
Of course, none of this was written with anything even remotely like
Gutenprint in mind.
> I feel
> like I don't understand what the issue is, since upgrading PPD files
> is a trivial operation with Gutenprint. In any case, Gutenprint 5.2.3
> might also include a fix for their Epson printer that isn't reflected
> in the PPD file, so they should still take the update.
Right, again the versioning is based on the driver, *not* the PPD
file and whether it has changed. I'm not suggesting that we tie
updates to PPD files or that we don't update PPDs once we've installed
a new version. It is all about knowing when an update affects an
existing printer and limiting when we download and install those
updates accordingly.
Again, if you can come up with something that will work for both
single and multiple file family drivers, *and* doesn't require
somebody to remember to go change something somewhere, I'll entertain
it.
--
Robert Krawitz <rl...@al...>
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 Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
|
|
From: Michael R S. <ms...@ap...> - 2008-04-01 18:16:13
|
Robert Krawitz wrote:
> ...
> This is mainly a Mac OS X thing, but if we are going to provide
> software updates for Gutenprint, we *do not* want to show the
> update to the user unless they are using a driver that has been
> actually updated.
>
> Right now we use the PPD's PCFileName and FileVersion information
> to know whether the driver in software update is newer than the one
> on the local system. This works fine for every commercial printer
> driver and most open source drivers, just not Gutenprint.
>
> From my standpoint, it's a scaling problem. We support almost 900
> printers made by who knows how many vendors in 5 different families.
> The only other driver (proprietary or free) I'm aware of that's even
> close to that is HPIJS, and their task is a bit simpler because
> they're only supporting one vendor's printers.
ESP Print Pro had over 5300 drivers... We automated the driver
versioning through the PPD compiler.
> Well, there's also
> OMNI, but I'm not aware that they're releasing anything. 8.3 naming
> when the first three positions are taken up by our tag (STP) leaves
> only 5 free bytes. Figure that we have about 900 printers, with 18
> languages and simplified vs. full-featured PPD files, and we have to
> use those 5 bytes rather densely. What is HPIJS doing in this regard,
> by the way?
They hand-assign filenames based on the model name and number.
Assuming you stick with STPnnnn.PPD, you can have up to 5000 drivers
with the simplified/advanced split. If you use 0-9 and A-Z, then you
can have a little over 30 million split drivers. The languages are
not an issue...
> Personally, I think 8.3 naming is an abomination, pure and simple.
> Even Windows had long file names well over a decade ago. The Mac
> never had this, and UNIX got rid of of it 30 some odd years ago. We
> support entirely too many printers and variants to be able to use this
> in any stable manner.
CUPS 1.4 will be introducing a long filename attribute ("cupsFileName")
and the PPD compiler will support generating PPDs with long filenames.
That said, most PPDs will still not have the new attribute so we'll
have to use/support the PCFileName attribute as well.
> ...
> Why? I understand that a particular option may no longer work,
> but why will the entire PPD not work?
>
> Well, say we get rid of 1440x720 highest quality, and the user selects
> it -- the print operation will fail, with a somewhat cryptic error.
So let's improve the error message!
> ...
> If a driver consists of a single source file, this isn't that hard to
> do -- just use the RCS version, which can be done automatically. But
> this won't work for family drivers like the Canon and Epson inkjet
> that consist of multiple source files. Somebody has to remember to
> manually uprev the version somewhere, which is easy to forget in the
> heat of battle and isn't easy for the tools to check as part of the
> build process. I suppose we could write a script to grovel the change
> log, but that seems like a lot of work and that itself is likely to be
> error-prone in its own way.
If you have a data file containing the current driver version and the
CVS versions of each module, the tool could check and bump the version
when any of the dependent files have changed. You could just run this
script before generating a release.
> ...
> The kicker is that we need to know what driver used for a printer,
> and the version of that driver, to know whether we need to present
> the software update to the user. I *think* we can get the correct
> info with the current Gutenprint PPD keywords, however the issue
> right now is that we'll always update Gutenprint even if their
> particular printer wasn't updated.
>
> I believe I understand the issue, but it's not clear to me how to fix
> it in a foolproof way. Perhaps you might have a suggestion?
I'll see if I can come up with a tool to generate a driver version
number for 5.2.x based on the source file revisions of the drivers.
> ...
> It would be nice (for 5.2) to assign unique numbers to each of the
> Gutenprint drivers so that PCFileName *could* be stable across
> releases - it would also make updates simpler in the future since
> we'll have direct support for it in CUPS.
>
> PCFileName just flat out doesn't scale because of the 8.3 limitation.
I'll work on a hash that can be used on the printer tag name.
> ...
> BTW, I'd argue that this use of *PCFileName isn't exactly in accord
> with the spec:
> ...
> Not that what we're doing conforms either, but this suggests to me
> that if anything the PCFileName is expected to change between releases
> ("must be issued a new PPD file with a new name").
There is a convention to use the last character as a version number,
but in practice few PPDs or products are changed this way and (as you
say) the 8.3 limit is an artifact of an older day.
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer
|
|
From: Robert K. <rl...@al...> - 2008-04-01 23:36:10
|
Date: Tue, 01 Apr 2008 11:16:14 -0700
From: Michael R Sweet <ms...@ap...>
Robert Krawitz wrote:
> ...
> This is mainly a Mac OS X thing, but if we are going to provide
> software updates for Gutenprint, we *do not* want to show the
> update to the user unless they are using a driver that has been
> actually updated.
>
> Right now we use the PPD's PCFileName and FileVersion information
> to know whether the driver in software update is newer than the one
> on the local system. This works fine for every commercial printer
> driver and most open source drivers, just not Gutenprint.
>
> From my standpoint, it's a scaling problem. We support almost 900
> printers made by who knows how many vendors in 5 different families.
> The only other driver (proprietary or free) I'm aware of that's even
> close to that is HPIJS, and their task is a bit simpler because
> they're only supporting one vendor's printers.
ESP Print Pro had over 5300 drivers... We automated the driver
versioning through the PPD compiler.
OK, fair enough. Gutenprint was never designed around PPD files, so
we never went out of our way to keep names particularly short or
anything.
> Well, there's also
> OMNI, but I'm not aware that they're releasing anything. 8.3 naming
> when the first three positions are taken up by our tag (STP) leaves
> only 5 free bytes. Figure that we have about 900 printers, with 18
> languages and simplified vs. full-featured PPD files, and we have to
> use those 5 bytes rather densely. What is HPIJS doing in this regard,
> by the way?
They hand-assign filenames based on the model name and number.
Which isn't too different from what we do, although like I said we
never even tried to keep names within 5 or 8 characters.
Assuming you stick with STPnnnn.PPD, you can have up to 5000 drivers
with the simplified/advanced split. If you use 0-9 and A-Z, then you
can have a little over 30 million split drivers. The languages are
not an issue...
> Personally, I think 8.3 naming is an abomination, pure and simple.
> Even Windows had long file names well over a decade ago. The Mac
> never had this, and UNIX got rid of of it 30 some odd years ago. We
> support entirely too many printers and variants to be able to use this
> in any stable manner.
CUPS 1.4 will be introducing a long filename attribute
("cupsFileName") and the PPD compiler will support generating PPDs
with long filenames. That said, most PPDs will still not have the
new attribute so we'll have to use/support the PCFileName attribute
as well.
But will having a stable PCFileName matter at that point? I presume
you'd check cupsFileName first, and only fall back on PCFileName if it
isn't present.
> ...
> Why? I understand that a particular option may no longer work,
> but why will the entire PPD not work?
>
> Well, say we get rid of 1440x720 highest quality, and the user selects
> it -- the print operation will fail, with a somewhat cryptic error.
So let's improve the error message!
The error message isn't really that unclear; the problem is that CUPS
only makes the last line of the error message visible, and that line
merely mentions that the options didn't verify. There could be more
than one error, you realize.
> ...
> If a driver consists of a single source file, this isn't that hard to
> do -- just use the RCS version, which can be done automatically. But
> this won't work for family drivers like the Canon and Epson inkjet
> that consist of multiple source files. Somebody has to remember to
> manually uprev the version somewhere, which is easy to forget in the
> heat of battle and isn't easy for the tools to check as part of the
> build process. I suppose we could write a script to grovel the change
> log, but that seems like a lot of work and that itself is likely to be
> error-prone in its own way.
If you have a data file containing the current driver version and the
CVS versions of each module, the tool could check and bump the version
when any of the dependent files have changed. You could just run this
script before generating a release.
> The kicker is that we need to know what driver used for a printer,
> and the version of that driver, to know whether we need to present
> the software update to the user. I *think* we can get the correct
> info with the current Gutenprint PPD keywords, however the issue
> right now is that we'll always update Gutenprint even if their
> particular printer wasn't updated.
>
> I believe I understand the issue, but it's not clear to me how to fix
> it in a foolproof way. Perhaps you might have a suggestion?
I'll see if I can come up with a tool to generate a driver version
number for 5.2.x based on the source file revisions of the drivers.
OK. One option might be to simply add all of the file version numbers
together (this would work on the mainline, but not on a branch).
> It would be nice (for 5.2) to assign unique numbers to each of the
> Gutenprint drivers so that PCFileName *could* be stable across
> releases - it would also make updates simpler in the future since
> we'll have direct support for it in CUPS.
>
> PCFileName just flat out doesn't scale because of the 8.3 limitation.
I'll work on a hash that can be used on the printer tag name.
OK, although hopefully that will become obsolete soon enough.
> ...
> BTW, I'd argue that this use of *PCFileName isn't exactly in accord
> with the spec:
> ...
> Not that what we're doing conforms either, but this suggests to me
> that if anything the PCFileName is expected to change between releases
> ("must be issued a new PPD file with a new name").
There is a convention to use the last character as a version number,
but in practice few PPDs or products are changed this way and (as you
say) the 8.3 limit is an artifact of an older day.
--
Robert Krawitz <rl...@al...>
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 Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
|
|
From: Michael R S. <ms...@ap...> - 2008-04-02 00:10:01
|
Robert Krawitz wrote:
> ...
> CUPS 1.4 will be introducing a long filename attribute
> ("cupsFileName") and the PPD compiler will support generating PPDs
> with long filenames. That said, most PPDs will still not have the
> new attribute so we'll have to use/support the PCFileName attribute
> as well.
>
> But will having a stable PCFileName matter at that point? I presume
> you'd check cupsFileName first, and only fall back on PCFileName if it
> isn't present.
It won't matter for CUPS 1.4, but it will matter for older releases
that don't support the new attribute.
> > ...
> > Why? I understand that a particular option may no longer work,
> > but why will the entire PPD not work?
> >
> > Well, say we get rid of 1440x720 highest quality, and the user selects
> > it -- the print operation will fail, with a somewhat cryptic error.
>
> So let's improve the error message!
>
> The error message isn't really that unclear; the problem is that CUPS
> only makes the last line of the error message visible, and that line
> merely mentions that the options didn't verify. There could be more
> than one error, you realize.
And you can implement persistent error conditions using STATE messages
(since CUPS 1.1.x). Custom state keywords get mapped to localized
text using cupsIPPReason attributes...
http://www.cups.org/documentation.php/spec-ppd.html
> ...
> > PCFileName just flat out doesn't scale because of the 8.3 limitation.
>
> I'll work on a hash that can be used on the printer tag name.
>
> OK, although hopefully that will become obsolete soon enough.
Agreed!
--
______________________________________________________________________
Michael R Sweet Senior Printing System Engineer
|
|
From: Robert K. <rl...@al...> - 2008-04-01 23:40:48
|
Date: Tue, 01 Apr 2008 10:46:37 -0700 From: Michael R Sweet <ms...@ap...> Robert Krawitz wrote: > First, so what? What's wrong with big minor release numbers? > > I don't like it. Version numbers like 5.20.1 suggest to me that the > product is either going out of its way to bump the minor number (to > suggest more change than there is) or is trying to avoid bumping the > major number. 5.1.20 suggests a lot of patches or minor updates in an > otherwise stable release sequence. I guess I just prefer that. It's > a matter of taste. > > Also, a lot of distribution vendors are willing to release patches, > but not new minor releases, within the lifetime of a product release. Understood, but vendors are also uncomfortable with big changes in a point release - that's why we aren't doing Gutenprint 5.1.x driver updates. Yup. IMHO, new dither algorithms, global color management changes (i.e. color tweaks that affect all drivers), and API changes warrant a minor version bump, while other smaller changes, bug fixes, and new drivers can be a patch/point release. WRT to the 5.1.x lineage, we would have already had a 5.2.x series - not a lot of version inflation, but very clear that a significant new feature was added. Well, let's distinguish between new options and changed options. I agree that changing dither algorithms or color conversion frobnitzim shouldn't be done during a stable release series if possible, but adding a new algorithm (or possibly changing a non-default or experimental setting) is another matter. Adding Ordered New doesn't change anything else. > Also, in my experience a lot of users are uncomfortable with minor > version upgrades. I want to manage that discomfort appropriately -- > someone shouldn't be uncomfortable about a new dither algorithm being > added, but should be uncomfortable about a significant change to the > color correction. ... but a new dither algorithm often exposes color changes, especially if that new algorithm gets selected by the "simplified" PPDs. No, a *changed* dither algorithm can expose color changes, but not a *new* one. > Second, most of these changes do *not* require incompatible > changes to be made, and so would not require a minor version > bump, just a driver version bump and an updated PPD. > > Again, what do you mean by "incompatible" change? I'm talking about globals changes to the PPD (say, a new required attribute that is used by the driver), new dither algorithms, global color management changes, and driver API changes that affect the ability to print or the output that is produced. In short, an upgrade from 5.2.0 to 5.2.1 should not significantly change the output you get from a particular driver, but 5.2.1 to 5.3.0 could. Similarly, an application written to use the Gutenprint API should continue to work (at least) for all point releases, but might require changes between minor releases. I agree, with the caveat that adding a binary compatible API change (such as an additional setting or non-mandatory option or such) should be OK. Changing a default dither algorithm isn't something we should normally do during a minor release. Adding a new non-default dither algorithm as an option is quite another matter -- this change is completely upward compatible, and shouldn't require a minor version bump. -- Robert Krawitz <rl...@al...> 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 Gutenprint -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton |
|
From: Michael R S. <ms...@ap...> - 2008-04-02 00:14:09
|
Robert Krawitz wrote: > ... > drivers can be a patch/point release. WRT to the 5.1.x lineage, we > would have already had a 5.2.x series - not a lot of version > inflation, but very clear that a significant new feature was added. > > Well, let's distinguish between new options and changed options. I > agree that changing dither algorithms or color conversion frobnitzim > shouldn't be done during a stable release series if possible, but > adding a new algorithm (or possibly changing a non-default or > experimental setting) is another matter. Adding Ordered New doesn't > change anything else. Right, point/patch releases shouldn't change the default behavior, but we could "sneak" a new dither algorithm into such a release as long as the defaults did not change. > > Also, in my experience a lot of users are uncomfortable with minor > > version upgrades. I want to manage that discomfort appropriately -- > > someone shouldn't be uncomfortable about a new dither algorithm being > > added, but should be uncomfortable about a significant change to the > > color correction. > > ... but a new dither algorithm often exposes color changes, especially > if that new algorithm gets selected by the "simplified" PPDs. > > No, a *changed* dither algorithm can expose color changes, but not a > *new* one. Again, the distinction is that if the default behavior changes, we want to bump the minor version. Otherwise we can just bump the point/ patch release. > ... > In short, an upgrade from 5.2.0 to 5.2.1 should not significantly > change the output you get from a particular driver, but 5.2.1 to > 5.3.0 could. Similarly, an application written to use the > Gutenprint API should continue to work (at least) for all point > releases, but might require changes between minor releases. > > I agree, with the caveat that adding a binary compatible API change > (such as an additional setting or non-mandatory option or such) should > be OK. Changing a default dither algorithm isn't something we should > normally do during a minor release. Adding a new non-default dither > algorithm as an option is quite another matter -- this change is > completely upward compatible, and shouldn't require a minor version > bump. Right, assuming that the default behavior remain the same, it is safe to stick with the same minor release. Otherwise we want to bump it to signal that something significant has changed that requires attention. -- ______________________________________________________________________ Michael R Sweet Senior Printing System Engineer |
|
From: Robert K. <rl...@al...> - 2008-04-02 00:15:44
|
Date: Tue, 01 Apr 2008 17:09:03 -0700
From: Michael R Sweet <ms...@ap...>
Robert Krawitz wrote:
> ...
> CUPS 1.4 will be introducing a long filename attribute
> ("cupsFileName") and the PPD compiler will support generating PPDs
> with long filenames. That said, most PPDs will still not have the
> new attribute so we'll have to use/support the PCFileName attribute
> as well.
>
> But will having a stable PCFileName matter at that point? I presume
> you'd check cupsFileName first, and only fall back on PCFileName if it
> isn't present.
It won't matter for CUPS 1.4, but it will matter for older releases
that don't support the new attribute.
Again, how critical is it, really, to have stable PCFileNames?
> > Why? I understand that a particular option may no longer work,
> > but why will the entire PPD not work?
> >
> > Well, say we get rid of 1440x720 highest quality, and the user selects
> > it -- the print operation will fail, with a somewhat cryptic error.
>
> So let's improve the error message!
>
> The error message isn't really that unclear; the problem is that CUPS
> only makes the last line of the error message visible, and that line
> merely mentions that the options didn't verify. There could be more
> than one error, you realize.
And you can implement persistent error conditions using STATE messages
(since CUPS 1.1.x). Custom state keywords get mapped to localized
text using cupsIPPReason attributes...
http://www.cups.org/documentation.php/spec-ppd.html
That looks like it only handles fixed messages. Our error messages
are more like
`foo' is not a valid dither algorithm
How would we handle that kind of situation?
--
Robert Krawitz <rl...@al...>
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 Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
|
Thanks for helping keep SourceForge clean.
X