Bug#961909: ghostscript: PDFA_def.ps references srgb.icc with relative path
Hi, Quoting Jonas Smedegaard (2020-06-09 14:20:34) > Quoting Johannes 'josch' Schauer (2020-05-31 11:48:01) > > using /usr/share/ghostscript/9.27/lib/PDFA_def.ps I can convert a PDF > > into PDF/A-1b like so: > > > > $ env --chdir=/usr/share/color/icc/ghostscript/ gs -dBATCH -dNOPAUSE \ > > > -dSAFEGR -dPDFA=1 -sProcessColorModel=DeviceRGB > > -dPDFACompatibilityPolicy=1 > > > -sDEVICE=pdfwrite -sOutputFile=/tmp/out.pdf \ > > > /usr/share/ghostscript/9.27/lib/PDFA_def.ps \ > > > in.pdf > > > > Using "env --chdir" as well as using an absolute path for OutputFile is > > necessary because PDFA_def.ps references srgb.icc with a relative path > > in /usr/share/color/icc/ghostscript/ -- this means that unless the > > command is executed in /usr/share/color/icc/ghostscript/, PDFA_def.ps is > > useless and must be edited to contain the right absolute path to > > srgb.icc. > > > > I propose to either: > > > > - move PDFA_def.ps to /usr/share/doc/*/examples because it's a file > >that cannot be used immediately but has to be edited first > > > > - patch PDFA_def.ps to include the full path to > >/usr/share/color/icc/ghostscript/srgb.icc so that it can be used from > >any directory > > Good catch! > > Indeed libgs9 ships with a few files arguably usable only as examples: > > /usr/share/ghostscript/9.27/lib/PDFA_def.ps > /usr/share/ghostscript/9.27/lib/PDFX_def.ps > > The files document both inline and in VectorDevices.htm that they should > be edited before use. > > I am hesitant to moving or patching those files, though, because (as you > demonstrate above) it _is_ possible with some path juggling to use those > files as-is, and both upstream and consuming code might rely on the > files. Even if never used for anything as examples, I see no harm in > leaving the files where they are just to be on the safe side. > > More sensible to me would be to symlink the files to > .../doc/libgs9/examples to advertise them as usable as such. > > How do you think about my alternative approach? that sounds good, thanks! cheers, josch signature.asc Description: signature
Bug#961909: ghostscript: PDFA_def.ps references srgb.icc with relative path
Hi Josch, Quoting Johannes 'josch' Schauer (2020-05-31 11:48:01) > using /usr/share/ghostscript/9.27/lib/PDFA_def.ps I can convert a PDF > into PDF/A-1b like so: > > $ env --chdir=/usr/share/color/icc/ghostscript/ gs -dBATCH -dNOPAUSE \ > > -dSAFEGR -dPDFA=1 -sProcessColorModel=DeviceRGB > -dPDFACompatibilityPolicy=1 > > -sDEVICE=pdfwrite -sOutputFile=/tmp/out.pdf \ > > /usr/share/ghostscript/9.27/lib/PDFA_def.ps \ > > in.pdf > > Using "env --chdir" as well as using an absolute path for OutputFile is > necessary because PDFA_def.ps references srgb.icc with a relative path > in /usr/share/color/icc/ghostscript/ -- this means that unless the > command is executed in /usr/share/color/icc/ghostscript/, PDFA_def.ps is > useless and must be edited to contain the right absolute path to > srgb.icc. > > I propose to either: > > - move PDFA_def.ps to /usr/share/doc/*/examples because it's a file >that cannot be used immediately but has to be edited first > > - patch PDFA_def.ps to include the full path to >/usr/share/color/icc/ghostscript/srgb.icc so that it can be used from >any directory Good catch! Indeed libgs9 ships with a few files arguably usable only as examples: /usr/share/ghostscript/9.27/lib/PDFA_def.ps /usr/share/ghostscript/9.27/lib/PDFX_def.ps The files document both inline and in VectorDevices.htm that they should be edited before use. I am hesitant to moving or patching those files, though, because (as you demonstrate above) it _is_ possible with some path juggling to use those files as-is, and both upstream and consuming code might rely on the files. Even if never used for anything as examples, I see no harm in leaving the files where they are just to be on the safe side. More sensible to me would be to symlink the files to .../doc/libgs9/examples to advertise them as usable as such. How do you think about my alternative approach? Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bug#909564: [Pkg-utopia-maintainers] Bug#909564: avahi: Support local-only services via the loopback interface
On Tue 25 Sep 2018 at 13:56:01 +0200, Michael Biebl wrote: > Am 25.09.18 um 12:06 schrieb Till Kamppeter: > > Thanks, but please get the patch from here: > > > > https://github.com/OpenPrinting/ippusbxd > > > > or > > > > https://github.com/lathiat/avahi/issues/125 > > > > Your links were my first post of ippusbxd right after my GSoC student > > has done this project, long before I decided to move the OpenPrinting > > projects to GitHub. > > > > My links above are the official upstream place of ippusbxd and the > > feature request to Avahi upstream. > > We'll consider cherry-picking the patch once it has been reviewed and > applied upstream. I think that this has now been done. Would applying it in buster be a possibility? Regards, Brian.
