Processed: Re: Bug#995392: ghostscript: ps2pdf trashes some characters

[Debian Bug Tracking System]

Processing control commands:

> tags -1 upstream
Bug #995392 [ghostscript] ghostscript: ps2pdf trashes some characters
Added tag(s) upstream.
> forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704478
Bug #995392 [ghostscript] ghostscript: ps2pdf trashes some characters
Set Bug forwarded-to-address to 
'https://bugs.ghostscript.com/show_bug.cgi?id=704478'.

-- 
995392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995392
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

Control: tags -1 upstream
Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704478

On 2021-09-30 18:49:02 +0200, Jonas Smedegaard wrote:
> Quoting Vincent Lefevre (2021-09-30 18:28:51)
> > On 2021-09-30 17:18:46 +0200, Jonas Smedegaard wrote:
> > > This seems an upstream bug, and it would be helpful if you report it 
> > > upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/
> > 
> > OK. I'll do it tonight (I could also try to find the cause).

I've identified the commit that introduced the issue (though I'm not
sure whether the bug could be already present on other kinds of text)
and reported the bug upstream with the details (see above URL).

> Also, you could test against the newer pre-release in experimental.

Not tried, but the issue is still present in master.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#995392: ghostscript: ps2pdf trashes some characters

[JustAnotherArchivist]

Control: notfound -1 9.53.3~dfsg-8

Apologies, I somehow missed the part about pdftotext and the glyph's 
normal appearance in your original message. I can reproduce that with 
both files produced by 9.54.0~dfsg-5 but *not* the one produced by 
9.53.3~dfsg-8 (attached for reference), using the same pdftotext version 
(poppler-utils 20.09.0-3.1) for all files.




chartest-gs-jaa-9.53.3.pdf
Description: Adobe PDF document

Processed: Re: ghostscript: ps2pdf trashes some characters

[Debian Bug Tracking System]

Processing control commands:

> notfound -1 9.53.3~dfsg-8
Bug #995392 [ghostscript] ghostscript: ps2pdf trashes some characters
Ignoring request to alter found versions of bug #995392 to the same values 
previously set

-- 
995392: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995392
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#995392: ghostscript: ps2pdf trashes some characters

[JustAnotherArchivist]

Hi Vincent,

For what it's worth, I do not see the corruption you're describing with 
`gv chartest-gs.pdf` nor when converting it myself from your input file 
using versions 9.53.3~dfsg-8 or 9.54.0~dfsg-5.


I noticed that your file used a different internal conversion command 
compared to when I try it with ps2pdf 9.54.0~dfsg-5:


Yours: %%Invocation: path/gs -dPrinted=false -P- -dSAFER 
-dCompatibilityLevel=1.5 -q -P- -dNOPAUSE -dBATCH -sDEVICE=pdfwrite 
-sstdout=? -sOutputFile=? -P- -dSAFER -dCompatibilityLevel=1.5 ?
Mine: %%Invocation: path/gs -P- -dSAFER -dCompatibilityLevel=1.4 -q -P- 
-dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sstdout=? -sOutputFile=? -P- 
-dSAFER -dCompatibilityLevel=1.4 ?


Invoking it like your command manually did not make a difference for me 
though, with the output file being identical except for the expected 
differences in the version string, timestamps, and UUIDs.


I have attached my `ps2pdf chartest.pdf chartest-gs-jaa.pdf` output file 
(created with 9.54.0~dfsg-5).


Cheers,
JustAnotherArchivist



chartest-gs-jaa.pdf
Description: Adobe PDF document

Bug#995392: ghostscript: ps2pdf trashes some characters

[Jonas Smedegaard]

Quoting Vincent Lefevre (2021-09-30 18:28:51)
> On 2021-09-30 17:18:46 +0200, Jonas Smedegaard wrote:
> > This seems an upstream bug, and it would be helpful if you report it 
> > upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/
> 
> OK. I'll do it tonight (I could also try to find the cause).

Great. Thanks!

Also, you could test against the newer pre-release in experimental.


 - 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

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

On 2021-09-30 17:18:46 +0200, Jonas Smedegaard wrote:
> This seems an upstream bug, and it would be helpful if you report it 
> upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/

OK. I'll do it tonight (I could also try to find the cause).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#995392: ghostscript: ps2pdf trashes some characters

[Jonas Smedegaard]

Hi Vincent,

Quoting Vincent Lefevre (2021-09-30 16:53:01)
> The ps2pdf trashes some characters, making text non-searchable and 
> partly unreadable via pdftotext (even though the glyph appears to be 
> OK). There was no such issue in the recent past.

Thanks for reporting this!

This seems an upstream bug, and it would be helpful if you report it 
upstream as well.  Their bugtracker is at https://bugs.ghostscript.com/


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

Bug#995392: ghostscript: ps2pdf trashes some characters

[Vincent Lefevre]

Package: ghostscript
Version: 9.54.0~dfsg-5
Severity: grave
Justification: causes non-serious data loss

The ps2pdf trashes some characters, making text non-searchable and
partly unreadable via pdftotext (even though the glyph appears to
be OK). There was no such issue in the recent past.

LaTeX source to generate the PDF testcase:

\documentclass[12pt]{article}
\usepackage[T1]{fontenc}
\begin{document}
\thispagestyle{empty}
Test: float.
\end{document}

to be compiled with pdflatex.

I've attached 2 files:
  * chartest.pdf (testcase generated by pdflatex).
  * chartest-gs.pdf, which is the buggy result obtained with
"ps2pdf chartest.pdf chartest-gs.pdf".

chartest.pdf contains the text "Test: float." as expected.
But chartest-gs.pdf contains the text "Test: ŕoat.", which
is incorrect: "fl" has been replaced by "ŕ".

Removing "\usepackage[T1]{fontenc}" or the period after "float" makes
this issue disappear.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.14.0-1-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ghostscript depends on:
ii  libc6   2.32-4
ii  libgs9  9.54.0~dfsg-5

ghostscript recommends no packages.

Versions of packages ghostscript suggests:
ii  ghostscript-x  9.54.0~dfsg-5

-- no debconf information

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


chartest.pdf
Description: Adobe PDF document


chartest-gs.pdf
Description: Adobe PDF document

Bug#995322: closed by Brian Potkin (Re: Bug#995322: ipp-usb: prevents hp-toolbox and libsane-hpaio from working)

[Brian Potkin]

On Thu 30 Sep 2021 at 08:57:13 +0200, Giacomo Mulas wrote:

> On Wed, 29 Sep 2021, Debian Bug Tracking System wrote:
>
> > #995322: ipp-usb: prevents hp-toolbox and libsane-hpaio from working
> >
> > It has been closed by Brian Potkin .
> >
> > Much of your time would have been saved by reading the Release
> > Notes. Please submit another report if you feel the documentation
> > is inadequate.
>
> Indeed it is. As I said, ipp-usb got automatically installed upon upgrading
> to bullseye, together with tons of other packages. The only piece of
> information I was shown was the NEWS.Debian file of ipp-usb (together with
> dozens of other messages). The only thing it says is "Existing or newly
> created queues on a USB connection for IPP-over-USB
> capable devices using vendor drivers will not work while the ipp-usb
> service is activated and managing the connection."
> This is only about printing, no clue about other functions of the same
> device.

ipp-usb is a recommended package for cups-daemon and libsane1. That
the NEWS file does not mention scanning is a fair point. Does the
addotion of a third paragrapgh allay your concern?

If so, I woud suggest subnitting a report against ipp-usb. The change
is not extensive and could make it into a bullseye point release.

---

ipp-usb uses the IPP-over-USB protocol to allow the setting up of a
driverless print queue for most USB connected modern multi-function
and a few modern USB-only devices. The default is to auto-setup the
queue with cups-browsed.

Existing or newly created queues on a USB connection for IPP-over-USB
capable devices using vendor drivers will not work while the ipp-usb
service is activated and managing the connection.

The same protocol also allows discovery of modern scanner devices via
libsane1. Oncve again, vendor drivers will not work while the ipp-usb
service is activated and managing the connection.

Details are at

https://wiki.debian.org/CUPSDriverlessPrinting

---

BTW, Xsane should have given you two backends to access. hpaio will
not work bit escl should. I guess that was not the case. That is a bug
in escl and why the wiko points to sane-airscan as an alternative.

> Only _after_ discovering that ipp-usb was preventing xsane to
> connect to the scanner I looked at
> https://wiki.debian.org/CUPSDriverlessPrinting
> and found this warning in there:
> "Note that IPP-over-USB reserves the USB interface connection with the
> printer/scanner exclusively for itself and communication with a
> printer/scanner device by software that does not operate using the
> IPP-over-USB protocol becomes impossible while ipp-usb is running.  This is
> a consequence of the design of USB communication.  It is not a bug in
> ipp-usb.  (omissis) Communicating with a USB connected scanner via classic
> SANE backends such as libsane-hpaio, sane-pixma or sane-epson2 also becomes
> impossible with the ipp-usb daemon active and running."
>
> Had I seen _this_ warning in the release notes, _then_ this would have got
> some alarm ringing and I would not have wasted hours tracking this.
>
> So, please: do include the above warning, in full, in the release notes of
> ipp-usb.

I think that duplicating in the Release Notes what is on the wiki is not
the way to go, but you could submit a bug against the release-notes
pseudo-package.

> Also, it would be helpful to add at least a "Suggests" to install also the
> package sane-airscan along with it, since this will restore most
> multifunction devices to properly work again as scanners when ipp-usb is
> running.

That would be for the libsane1 maintainer to consider. Note that he has
already declined to make sane-airscan a Recommends:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971658

Cheers,

Brian.

Bug#995322: closed by Brian Potkin (Re: Bug#995322: ipp-usb: prevents hp-toolbox and libsane-hpaio from working)

[Giacomo Mulas]

On Wed, 29 Sep 2021, Debian Bug Tracking System wrote:


#995322: ipp-usb: prevents hp-toolbox and libsane-hpaio from working

It has been closed by Brian Potkin .

Much of your time would have been saved by reading the Release
Notes. Please submit another report if you feel the documentation
is inadequate.


Indeed it is. As I said, ipp-usb got automatically installed upon upgrading
to bullseye, together with tons of other packages. The only piece of
information I was shown was the NEWS.Debian file of ipp-usb (together with
dozens of other messages). The only thing it says is 
"Existing or newly created queues on a USB connection for IPP-over-USB

capable devices using vendor drivers will not work while the ipp-usb
service is activated and managing the connection."
This is only about printing, no clue about other functions of the same
device. Only _after_ discovering that ipp-usb was preventing xsane to
connect to the scanner I looked at 
https://wiki.debian.org/CUPSDriverlessPrinting

and found this warning in there:

"Note that IPP-over-USB reserves the USB interface connection with the
printer/scanner exclusively for itself and communication with a
printer/scanner device by software that does not operate using the
IPP-over-USB protocol becomes impossible while ipp-usb is running.  This is
a consequence of the design of USB communication.  It is not a bug in
ipp-usb.  (omissis) Communicating with a USB connected scanner via classic
SANE backends such as libsane-hpaio, sane-pixma or sane-epson2 also becomes
impossible with the ipp-usb daemon active and running."

Had I seen _this_ warning in the release notes, _then_ this would have got
some alarm ringing and I would not have wasted hours tracking this.

So, please: do include the above warning, in full, in the release notes of
ipp-usb.

Also, it would be helpful to add at least a "Suggests" to install 
also the package sane-airscan along with it, since this will restore most

multifunction devices to properly work again as scanners when ipp-usb is
running.

Thanks, and sorry for the inconvenience.

Bye
Giacomo

--
_

Giacomo Mulas 
_

INAF - Osservatorio Astronomico di Cagliari
via della scienza 5 - 09047 Selargius (CA)

tel.   +39 070 71180255
mob. : +39 329  6603810
_

"When the storms are raging around you, stay right where you are"
 (Freddy Mercury)
_