Re: libpaper 1.0 on master
joost witteveen wrote:
>
> >
> > >Shouldn't the "paper size" be an attribute of a print queue, and not an
> > >attribute of a machine?
>
> Well, it could be argued that Yvess libppaper could look at
> the current $PRINTER setting, and select the correct papersize
> depending on the /etc/papersize.printer file or something. But
> at the moment not very many programmes use libpaper or /etc/papersize,
> so it's better to have them at least get to recognise a global
> /etc/papersize than nothing.
Yup, sometimes something is better than nothing. Then again, sometimes
"something part way" makes it harder to get to "all the way" too.
If you make it queue-specific, it might be best to add it into
/etc/printcap (as opposed to /etc/papersize.queuename). There is
precedent for this (with at least one printer I've set up), and it's
discussed in at least one popular book about system administration (by
Evi Nemeth, under the name "printcap extensions"). BTW, this book lies
thru it's teeth about Solaris 2.x,
Parsing /etc/printcap is a simple matter - 20 lines of /bin/sh, or
pgetent in the lpd source.
An external library, such as libpaper.*, is precisely the right place to
put such a thing. AS long as it has a good'n'general interface, the
long-term nice-scenario get here eventually.
> > Paper size effect more that just printers. Previewers and tex tools
> > come to mind, there may be others...
> >
> > All I know is right now I've got to tweak quite a few things on a
> > standard debian 1.1 system so that dvips, xdvi, genscript, and a few
> > other programs work well and have the same idea of a default paper
> > size.
>
> Well, after you've done the tweaking, maybe it's worth the little
> extra efford of mailing the patches to the maintainer/bug-system
> and wait to see them included in the next release?
> If you don't want to do that, could you send your patches to me,
> so that try to handle it?
Reply to: