Subject: Re: Patch for making psutils use /etc/papersize

From: Dale Scheetz <[email-masked]>
Date: Sun, 2 Jun 1996 13:06:47 -0400 (EDT)

First, let me thank you for your efforts in this reguard. However, if you
are planning a new release of psutils we need to talk further. I have not
yet decided whether this is indeed a bug. 

On Sun, 2 Jun 1996, Yves Arrouye wrote:

> 
> 
> Hello,
> 
> Please find enclosed a patch to make psutils work with /etc/papersize. I
> used something I already use for a2ps, but please not the following points:
> 
>   - the libpaper library, which is rather crude, will be released next
>     week only (as soon as I get the right to upload on the Debian archive);

Please don't do this. If you wish to maintain a package there are several
orphaned ones that could use your attention.

>     I can email it to you if you want;
> 
>   - the changes are documented in the debian.Changelog;
> 
>   - contrarily to whoever posted a bug report for psutils not using /etc/
>     papersize, I don't think it should always use it (which is what it does
>     here). In my opinion, the tools should use /etc/papersize when they
>     output something new (for example when one resize, the destination paper
>     should be the one in /etc/papersize), not in the other cases: if I
>     say 'psnup -2 somefile.ps' and somefile.ps has a %%BoundingBox: or
>     a %%DocumentPaperSize: comment, the paper size should be got from
>     there; in addition, if a specific page has a %%PaperSize:,
>     %%BeginPaperSize: (or %%BeginFeature: *PageSize, %%BeginFeature:
>     *PageRegion or an equivalent %%IncludeFeature: comment), then the size
>     for this specific page (and following if appropriate) may be changed
>     there;
> 
> Anyway, maybe this diff may prove useful to provide some basic support
> for /etc/papersize.
> 
> I'd like to see these changes forwarded to Angus J. C. Duggan. Would you
> do that (after eventually discussing the changes with me), or may I do
> it myself?

I would much rather changes of this kind come from upstream. You are more
than welcome to submit your changes to Angus.

If you can find an address for Angus please let me know what it is. I have
been unable to locate such.

I would be happy to support your efforts to incorporate /etc/papersize in
the psutils package, I just think it should come from upstream. Also,
there are easier ways of dealing with this issue, that don't enclude
adding another dependency/conflict difficulty to yet another package.
Since all the utilities provide paper size parameters on the command line,
the user is encouraged to write simple shell scripts for each of the
classes of psutils jobs that user needs to perform. These scripts may use
/etc/papersize or some other method for controling these parameters. It is
my understanding that this is the way these utilities were intended to be
used.

I have posted this back to debian-devel to see what the rest of the folks
think. I would appreciate some feedback on this.

Thanks,

Dwarf

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

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  [email-masked]

------------ If you don't see what you want, just ask --------------

---

From: Lukas Nellen <[email-masked]>
Date: Mon, 03 Jun 1996 11:55:38 -0500

>>>>> "DS" == Dale Scheetz <[email-masked]> writes:

>> week only (as soon as I get the right to upload on the Debian archive);
	.
	.
	.
DS> I would be happy to support your efforts to incorporate /etc/papersize in
DS> the psutils package, I just think it should come from upstream. Also,
DS> there are easier ways of dealing with this issue, that don't enclude
DS> adding another dependency/conflict difficulty to yet another package.
DS> Since all the utilities provide paper size parameters on the command line,
DS> the user is encouraged to write simple shell scripts for each of the
DS> classes of psutils jobs that user needs to perform. These scripts may use
DS> /etc/papersize or some other method for controling these parameters. It is
DS> my understanding that this is the way these utilities were intended to be
DS> used.

My impression is that /etc/papersize (so far) is only used by packages
during the installation to set up their own configuration files. It is
not a configuration file by itself. This is important in so far as
many packages have more options to set than just the paper size. But
often, all but the paper size can be set to generally acceptable
defaults. So, IMHO, it wouldn't be nice if one package decides to use
/etc/papersize as it's configuration file. 

Also, I don't think a libpaper library will help a lot here. Think of
a2ps. It has many more compile time options than just the size of the
paper. I think that each package should provide its own set of
configuration files for such purposes. Also, I don't think it will be
that easy to get all of the half-dozen or so packages which use a
default paper size to use libpaper.

And the upstream authors should be encouraged to use runtime
configration instead of compile time configuration as much as
possible. In the pre-Linux days of free software, the system
administrator of a site was expected to compile everything
themselves. In that case, fixing site defaults using compile time
options was acceptable. But as soon as software gets distributed as
binaries, configuration files become important. With the extra
advantage that per-user default .packagerc files are easy to
implement. 

			Cheers,
				Lukas
-------------------------------------------------------------------------------
   Dr. Lukas Nellen                 | Email: [email-masked]
   Depto. de Fisica Teorica, IFUNAM |
   Apdo. Postal 20-364              | Tel.:  +52 5 622 5014 ext. 218
   01000 Mexico D.F., MEXICO        | Fax:   +52 5 622 5015