Bug#4058: etc/papersize doesn't allow spaces

[joost@rulcmc.leidenuniv.nl (joost witteveen)]

> 
>  > 
>  > Oh, BTW, this has nothing to do with libpaper (I don't know why you
>  > think it does, gs doesn't depend on libpaper, and has been reading
>  > /etc/papersize before the existance of libpaper.)
>  > 
>  > I do wonder if libpaper does a better job,
> 
> Yes it does ;-) That's its big advantage: centralize such bugs in one
> place so that we're sure all packages get fixed at once (who said I wanted
> to share features too? ;-))
> 
>  > and I do wonder if gs really should read "A4 ". Some people were really
>  > glad I added a wrapper to allow gs to read /etc/papersize. Some are
>  > angry it didn't read "A4 ". Well, you never please them all!
> 
> Can you try my gsfrontend.c in libpaper 0.3? It would be nice if you
> used it for these reasons:
> 
>   - people will benefit from new paper sizes immediately;

That's not true, the gs wrapper I have reads _all_ papersizes
gs understands. (it gets them at compile time from ps_init.ps or something)

> 
>   - I think if something else than me provides a working package using
>     libpaper, other package maintainers will start adopting it;
> 
>   - I won't have to overwrite your gs with my wrapper each time you
>     make a new package ;-).
> 
> If you use my wrapper (please, please...), I suggest installing the real
> gs as 'ghostscript' (a meaningfull name, no?) and the wrapper as 'gs'
> of course. Apparently people were confused by your gs-papersize being
> the gs that does not handle papersize despite its name.

So, that's not the case any more (the real gs is gs.real, the wrapper
is gs).

What is causing me not to upgrade gs at the moment is this SVGA stuff:
someone (svga maintainer) wanted a patch in that would make a
setuid root gs "safe", but I'm still having problems with this.

-- 
joost witteveen
            joost@rulcmc.leidenuniv.nl
          joostje@debian.org
--
Use Debian/GNU Linux!