Bug#1009665: ghostscript: with -dNEWPDF=false, the ToUnicode CMap sometimes has an incorrect mapping

On 2024-05-13 20:37:40 -0400, Alex Cherepanov wrote: > The problem was in pdftotext, rather than ps2pdf. > Starting from the v. 10.0.0 of Ghostscript, pdftotext > produces correct output from the attached PDF file. pdftotext is based on poppler. It doesn't use Ghostscript at all, AFAIK. In any

Bug#731140: ghostscript: on PDF files with embedded fonts, ps2pdf changes the way fonts are rendered

On 2024-02-28 23:04:41 -0600, Steven Robbins wrote: > On Mon, 2 Dec 2013 13:54:19 +0100 Vincent Lefevre wrote: > > font1.pdf is the original file (generated by pdflatex). > > font2.pdf is the file obtained with "ps2pdf font1.pdf font2.pdf". > > font.png sh

Bug#731164: ghostscript: ps2pdf makes highlighted/annotated text unreadable by poppler-based PDF viewers

On 2024-01-06 18:17:20 +0100, Vincent Lefevre wrote: > I confirm. However, Firefox 121 (from the Debian package) still > has the same issue with "out.pdf". That said, if I try again > "ps2pdf temp.pdf out.pdf" with ghostscript 10.02.1~dfsg-1 (on > my Debian/uns

Bug#731164: ghostscript: ps2pdf makes highlighted/annotated text unreadable by poppler-based PDF viewers

On 2024-01-05 22:58:58 -0600, Steven Robbins wrote: > On Mon, 2 Dec 2013 17:15:19 +0100 Vincent Lefevre wrote: > > Package: ghostscript > > Version: 9.05~dfsg-8 > > Severity: important > > > > When I use ps2pdf on a file with highlighted/annotated text (as >

Bug#998461: patch for ghostscript ToUnicode CMap bugs

On 2021-11-05 11:17:20 +0100, Vincent Lefevre wrote: > Here's a patch that fixes both 998458 and 998461 bugs. > It is formed by the following upstream commits by Ken Sharp: > b4e8434defb8e05ea05bb130b92217290efd2fba (2021-10-25) > 8f62213019bc682eeb0ed9467d8841f3770cfda6

Bug#998458: patch for ghostscript ToUnicode CMap bugs

Control: tags 998458 patch Control: tags 998461 patch Here's a patch that fixes both 998458 and 998461 bugs. It is formed by the following upstream commits by Ken Sharp: b4e8434defb8e05ea05bb130b92217290efd2fba (2021-10-25) 8f62213019bc682eeb0ed9467d8841f3770cfda6 (2021-10-29)

Bug#998461: ghostscript: pdfwrite emits incorrect ToUnicode CMap entries due to incorrect 2-byte Unicode test

Control: found -1 9.53.3~dfsg-7+deb11u1 Control: found -1 9.54.0~dfsg-5 On 2021-11-04 17:02:05 +0100, Vincent Lefevre wrote: > On 2021-11-04 16:41:04 +0100, Vincent Lefevre wrote: > [...] > > Testcase chartest5a-tl2021.pdf attached. It was generated with > > TeX Live 2021 on t

Bug#998458: ghostscript: pdfwrite emits incorrect ToUnicode CMap entries

Control: found -1 9.54.0~dfsg-5 On 2021-11-04 16:59:25 +0100, Vincent Lefevre wrote: > On 2021-11-04 16:18:17 +0100, Vincent Lefevre wrote: [...] > > This chartest1.pdf file contains the text "Test: float.". But when > > converted with ps2pdf (or gs directl

Bug#998461: ghostscript: pdfwrite emits incorrect ToUnicode CMap entries due to incorrect 2-byte Unicode test

Control: found 9.53.3~dfsg-7+deb11u1 On 2021-11-04 16:41:04 +0100, Vincent Lefevre wrote: [...] > Testcase chartest5a-tl2021.pdf attached. It was generated with > TeX Live 2021 on the following LaTeX source: > > \documentclass[12pt]{article} > \usepackage[utf8]{inputenc} &

Bug#998458: ghostscript: pdfwrite emits incorrect ToUnicode CMap entries

On 2021-11-04 16:18:17 +0100, Vincent Lefevre wrote: > Ghostscript, e.g. via the ps2pdf wrapper, emits incorrect > ToUnicode CMap entries, making text non-searchable, partly > unreadable via pdftotext, and affecting copy-paste too. > > Testcase chartest1.pdf attached. It was gen

Bug#995392: ghostscript: ps2pdf trashes some characters

On 2021-11-03 18:06:50 +0100, Jonas Smedegaard wrote: > Quoting Vincent Lefevre (2021-11-03 14:29:26) > > This Debian bug actually covers several similar Ghostscript bugs. > > Please track each bug separately. Otherwise it is not possible to > reliably track which bug affec

Bug#998461: ghostscript: pdfwrite emits incorrect ToUnicode CMap entries due to incorrect 2-byte Unicode test

Package: ghostscript Version: 9.55.0~~rc1~dfsg-1 Severity: normal Tags: upstream fixed-upstream Ghostscript, e.g. via the ps2pdf wrapper, emits incorrect ToUnicode CMap entries, making text non-searchable, partly unreadable via pdftotext, and affecting copy-paste too. A bug was fixed upstream by

Bug#998458: ghostscript: pdfwrite emits incorrect ToUnicode CMap entries

Package: ghostscript Version: 9.55.0~~rc1~dfsg-1 Severity: normal Tags: upstream fixed-upstream Forwarded: https://bugs.ghostscript.com/show_bug.cgi?id=704478 Ghostscript, e.g. via the ps2pdf wrapper, emits incorrect ToUnicode CMap entries, making text non-searchable, partly unreadable via

Bug#995392: ghostscript: ps2pdf trashes some characters

Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704681 On 2021-11-03 14:29:26 +0100, Vincent Lefevre wrote: > Control: retitle -1 ghostscript: pdfwrite incorrectly deals with embedded > ToUnicode CMap > Control: found -1 9.27~dfsg-2+deb10u4 > > This Debian bug

Bug#995392: ghostscript: ps2pdf trashes some characters

. On 2021-11-03 05:04:36 +0100, Vincent Lefevre wrote: > \documentclass{article} > \usepackage[T1]{fontenc} > \usepackage{lmodern} > \pdfglyphtounicode{Scaron}{0160} > \pdfgentounicode=1 > \begin{document} > \thispagestyle{empty} > 'ê > \end{document} This testcase shows that th

Bug#995392: ghostscript: ps2pdf trashes some characters

On 2021-11-03 03:29:43 +0100, Vincent Lefevre wrote: > On 2021-11-02 16:25:27 +0100, Vincent Lefevre wrote: > > With commit 8f62213019bc682eeb0ed9467d8841f3770cfda6 upstream, > > I can no longer reproduce any issue, even when > > /usr/share/texlive/texmf-dist/tex/generic/pdft

Bug#995392: ghostscript: ps2pdf trashes some characters

Control: tags -1 - fixed-upstream On 2021-11-02 16:25:27 +0100, Vincent Lefevre wrote: > With commit 8f62213019bc682eeb0ed9467d8841f3770cfda6 upstream, > I can no longer reproduce any issue, even when > /usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex > from T

Bug#995392: ghostscript: ps2pdf trashes some characters

On 2021-11-02 16:25:27 +0100, Vincent Lefevre wrote: > With commit 8f62213019bc682eeb0ed9467d8841f3770cfda6 upstream, > I can no longer reproduce any issue, even when > /usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex > from Tex Live 2020 is included and \pdfge

Bug#995392: ghostscript: ps2pdf trashes some characters

Control: found -1 9.55.0~~rc1~dfsg-1 Control: tags -1 fixed-upstream With commit 8f62213019bc682eeb0ed9467d8841f3770cfda6 upstream, I can no longer reproduce any issue, even when /usr/share/texlive/texmf-dist/tex/generic/pdftex/glyphtounicode.tex from Tex Live 2020 is included and

Bug#995678: ghostscript: pdfwrite no longer preserves the ToUnicode CMap of PDF files

Control: forcemerge 995392 995678 Since this bug was reassigned back to ghostscript, let's merge it with the original bug. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC

Bug#995392: ghostscript: ps2pdf trashes some characters

Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=704674 Control: tags -1 - fixed-upstream Control: retitle -1 ghostscript: pdfwrite no longer preserves the ToUnicode CMap of PDF files This is actually the real upstream bug (it appears that the first testcase I gave was affected

Bug#994395: cups: uses sides=one-sided by default

Additional information: On both Debian 10 and Debian unstable, I get $ ipptool -tv ipp://localhost/printers/print-1 get-printer-attributes.test | grep sides- sides-supported (1setOf keyword) = one-sided,two-sided-long-edge,two-sided-short-edge sides-default (keyword) =

Bug#994395: cups: uses sides=one-sided by default

On 2021-09-15 15:34:00 +0200, Vincent Lefevre wrote: > Package: cups > Version: 2.3.3op2-3+deb11u1 > Severity: important > > On my Debian machine, files are printed one sided, even though I use > Duplex=DuplexNoTumble in my .cups/lpoptions file. I suppose that this > is due t

Bug#995392: ghostscript: ps2pdf trashes some characters

On 2021-10-01 16:52:13 +0200, Jonas Smedegaard wrote: > Quoting Vincent Lefevre (2021-10-01 15:53:38) > > It seems that the issue partly comes from pdflatex: On an old file for > > which ps2pdf was correct with ghostscript 9.53.3~dfsg-4, it is now > > incorrect still with gh

Bug#995392: ghostscript: ps2pdf trashes some characters

On 2021-10-01 14:31:57 +0200, Vincent Lefevre wrote: > On 2021-10-01 14:26:02 +0200, Vincent Lefevre wrote: > > On 2021-10-01 14:17:53 +0200, Vincent Lefevre wrote: > > > In my archives, I can see that the issue occurred with > > > ghostscript 9.26a~dfsg-0+deb9

Bug#995392: ghostscript: ps2pdf trashes some characters

On 2021-10-01 14:26:02 +0200, Vincent Lefevre wrote: > On 2021-10-01 14:17:53 +0200, Vincent Lefevre wrote: > > In my archives, I can see that the issue occurred with > > ghostscript 9.26a~dfsg-0+deb9u1, but 9.27~dfsg-2+deb10u4 > > isn't affected on my second testcase. >

Bug#995392: ghostscript: ps2pdf trashes some characters

On 2021-10-01 14:17:53 +0200, Vincent Lefevre wrote: > In my archives, I can see that the issue occurred with > ghostscript 9.26a~dfsg-0+deb9u1, but 9.27~dfsg-2+deb10u4 > isn't affected on my second testcase. The following PDF file (on which I got the issue with ghostscript 9.26a~dfsg

Bug#995392: ghostscript: ps2pdf trashes some characters

In my archives, I can see that the issue occurred with ghostscript 9.26a~dfsg-0+deb9u1, but 9.27~dfsg-2+deb10u4 isn't affected on my second testcase. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA -

Bug#995392: ghostscript: ps2pdf trashes some characters

On 2021-10-01 12:05:28 +0200, Vincent Lefevre wrote: > Well, with 9.53.3~dfsg-8, I can reproduce the bug on another PDF file, > where it is the U+2019 RIGHT SINGLE QUOTATION MARK character (used as > an apostrophe) that is incorrectly replaced by Š. I'll have to make > another sim

Bug#995392: ghostscript: ps2pdf trashes some characters

Control: found -1 9.53.3~dfsg-8 On 2021-09-30 22:00:47 +, JustAnotherArchivist wrote: > 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

Bug#995392: ghostscript: ps2pdf trashes some characters

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 see

Bug#995392: ghostscript: ps2pdf trashes some characters

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:

Bug#995392: ghostscript: ps2pdf trashes some characters

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

Bug#994395: cups: uses sides=one-sided by default

Package: cups Version: 2.3.3op2-3+deb11u1 Severity: important On my Debian machine, files are printed one sided, even though I use Duplex=DuplexNoTumble in my .cups/lpoptions file. I suppose that this is due to the following issue. cventin:~> lpoptions -p print-1 ColorModel=Gray copies=1

Bug#982303: cups(1): missing client.conf(7) man page or bad section 7 instead of 5

Package: cups Version: 2.3.3op2-2 Severity: minor In the cups(1) man page: SEE ALSO cancel(1), client.conf(7), [...] But there is no manual entry for client.conf in section 7. However, cups-client provides a manual entry in section 5. So, either some client.conf(7) man page is missing,

Bug#799042: cups-client: lpoptions no longer outputs anything

Control: reopen -1 Control: found -1 2.3.0-7 On 2019-11-08 20:11:13 +, Brian Potkin wrote: > This report is a little old. and involves an unsupported Debian. Myself, > I didn't observe the issue at the time of reporting. I still do not > observe it. Closing time. I can still see this issue

Bug#910274: ghostscript: ps2pdf removes links from PDF files

On 2018-11-11 20:11:54 +0100, Vincent Lefevre wrote: > Control -1 tags - fixed-upstream > Control: found -1 9.25~dfsg-0+deb9u1 > > On 2018-10-05 13:58:44 +0200, Vincent Lefevre wrote: > > So, there is no longer any way to keep all annotations. > > Now the bug is present

Bug#910274: ghostscript: ps2pdf removes links from PDF files

Control -1 tags - fixed-upstream Control: found -1 9.25~dfsg-0+deb9u1 On 2018-10-05 13:58:44 +0200, Vincent Lefevre wrote: > So, there is no longer any way to keep all annotations. Now the bug is present in Debian stable. -- Vincent Lefèvre - Web: <https://www.vinc17.net/> 100% a

Bug#910274: ghostscript: ps2pdf removes links from PDF files

Control: retitle -1 ghostscript: ps2pdf removes links from PDF file / does not keep all annotations On 2018-10-04 15:04:19 +0200, Jonas Smedegaard wrote: > Quoting Vincent Lefevre (2018-10-04 14:44:08) [...] > > As a conversion tool, it should neither lose information, nor assume >

Bug#910274: ghostscript: ps2pdf removes links from PDF files

Control: reopen -1 Control: tags -1 - fixed-upstream control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=699874 On 2018-10-04 13:34:20 +0200, Jonas Smedegaard wrote: > Quoting Vincent Lefevre (2018-10-04 13:03:52) > > I could test that this bug is reproducible with u

Bug#910274: ghostscript: ps2pdf removes links from PDF files

Control: tags -1 upstream Control: forwarded -1 https://bugs.ghostscript.com/show_bug.cgi?id=699874 I could test that this bug is reproducible with upstream's version. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Bug#910274: ghostscript: ps2pdf removes links from PDF files

out.pdf Description: Adobe PDF document

Bug#799042: cups-client: lpoptions no longer outputs anything

Package: cups-client Version: 1.7.5-11+deb8u1 Severity: normal At my lab, a machine has been reinstalled with Debian 8, and as I was getting the following error: cassis:~> lpq lpq: Error - no default destination available. zsh: exit 1 lpq I wanted to know what was going on with lpoptions,

Bug#711327: cups-client: the -h option has no effect

Control: retitle -1 cups-client: the -h option is overridden by _cupsSetDefaults settings when the port is not given Control: found -1 2.0.3-8 On 2015-07-11 11:19:15 +0100, Brian Potkin wrote: From https://www.cups.org/documentation.php/doc-2.0/relnotes.html Fixed several issues with

Bug#781253: cups: no duplex printing (two-sided) with lp or lpr

Control: tags -1 upstream fixed-upstream fixed-in-experimental Control: found -1 9.05~dfsg-6.3+deb7u1 Control: found -1 9.06~dfsg-2 Control: fixed -1 9.15~rc1~dfsg-1 On 2015-05-12 11:10:36 +0100, Brian Potkin wrote: You appear to be correct in thinking the bug has not been attended to in

Bug#781253: cups: no duplex printing (two-sided) with lp or lpr

On 2015-05-11 23:12:35 +0100, Brian Potkin wrote: Today, while examining the way Ghostscript and pdftops operate I came (completely unexpectedly) across this: http://bugs.ghostscript.com/show_bug.cgi?id=694852 Your problem appears to be exactly described in the bug title. Indeed. My

Bug#781253: cups: no duplex printing (two-sided) with lp or lpr

On 2015-04-30 10:32:33 +0100, Brian Potkin wrote: Having to switch renderer to get a satisfactory printout is usually an indication of a problem with the printer not dealing with valid PostScript rather than the filtering system. Or could this be a bug with the default renderer (Ghostscript?)?

Bug#781253: cups: no duplex printing (two-sided) with lp or lpr

On 2015-04-30 10:32:33 +0100, Brian Potkin wrote: Having to switch renderer to get a satisfactory printout is usually an indication of a problem with the printer not dealing with valid PostScript rather than the filtering system. Is there a way to send unfiltered PostScript to the printer in

Bug#781253: cups: no duplex printing (two-sided) with lp or lpr

this is related and whether there may be a server problem too. Same problem if I convert the PDF file to PS with pdftops, then print the .ps file with lp: A3 paper, two-sided. On 2015-03-30 14:03:23 +0100, Brian Potkin wrote: On Mon 30 Mar 2015 at 11:30:26 +0200, Vincent Lefevre wrote: On 2015-03-27 19:12

Bug#781253: cups: no duplex printing (two-sided) with lp or lpr

On 2015-03-27 19:12:13 +, Brian Potkin wrote: On Fri 27 Mar 2015 at 11:27:41 +0100, Vincent Lefevre wrote: On 2015-03-27 09:46:55 +, Brian Potkin wrote: Evince is very likely using 'Duplex=DuplexNoTumble' when the file gets to the server. How does 'lp -o Duplex=DuplexNoTumble

Bug#781253: cups: no duplex printing (two-sided) with lp or lpr

On 2015-03-27 09:46:55 +, Brian Potkin wrote: Evince is very likely using 'Duplex=DuplexNoTumble' when the file gets to the server. How does 'lp -o Duplex=DuplexNoTumble file.pdf' fare? Same problem. Do we assume you do not have access to the server logs? I don't, but I can ask the

Bug#781253: cups: no duplex printing (two-sided) with lp or lpr

On 2015-03-26 16:41:53 +, Brian Potkin wrote: Please post what you get for 'lpoptions -l'. OptionTray/Option Tray: NotInstalled 1Cassette LCT *2Cassette LargeCapacityTray/Large Capacity Tray: *NotInstalled Installed InnerTray2/Internal Tray 2: *NotInstalled Installed ShiftTray/Internal Shift

Bug#763771: cups-daemon: reload failed during upgrade

On 2014-11-23 14:22:25 +0100, Didier 'OdyX' Raboud wrote: Could you retry with the latest CUPS version (1.7.5-8) which I just uploaded? It fixes a random crash, and could help with your issue. It also enabled core-dumps through the same patch. After 2 days, I didn't get any crash. I suppose

Bug#763771: cups-daemon: reload failed during upgrade

Control: retitle -1 cupsd often crashes Control: severity -1 important On 2014-11-06 22:09:49 +0100, Vincent Lefevre wrote: Well, I think why the reload failed: a reason may be that the cupsd daemon was no longer running. Again, cupsd is no longer running. Since /var/run/cups/cups.sock

Re: Bug#763771: cups-daemon: reload failed during upgrade

Control: tags -1 - moreinfo since I gave additional information. I can't debug it as core dumps are disabled. So, please fix bug 760475. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA -

Bug#763771: cups-daemon: reload failed during upgrade

On 2014-11-06 20:18:12 +0100, Didier 'OdyX' Raboud wrote: Le vendredi, 3 octobre 2014, 01.37:16 Vincent Lefevre a écrit : On 2014-10-02 18:19:02 +0200, Didier 'OdyX' Raboud wrote: Le jeudi, 2 octobre 2014 17.01:23, vous avez écrit : During an upgrade, the reload invoked by the cups

Bug#763771: cups-daemon: reload failed during upgrade

Package: cups-daemon Version: 1.7.5-3 Severity: normal During an upgrade, the reload invoked by the cups-filters postinst script failed: (Reading database ... 496473 files and directories currently installed.) Preparing to unpack .../libcupsfilters-dev_1.0.59-1_amd64.deb ... Unpacking

Bug#763771: cups-daemon: reload failed during upgrade

Control: tags -1 - moreinfo On 2014-10-02 18:19:02 +0200, Didier 'OdyX' Raboud wrote: Le jeudi, 2 octobre 2014 17.01:23, vous avez écrit : Package: cups-daemon Version: 1.7.5-3 Severity: normal During an upgrade, the reload invoked by the cups-filters postinst script failed: Do

Bug#757177: Error: /typecheck in /findfont on AvantGarde-Boo-iso

Package: ghostscript Version: 9.05~dfsg-8.1 Severity: normal On the attached file, gs gives the following error: $ gs ziv.eps GPL Ghostscript 9.05 (2012-02-08) Copyright (C) 2010 Artifex Software, Inc. All rights reserved. This software comes with NO WARRANTY: see the file PUBLIC for details.

Bug#757177: Error: /typecheck in /findfont on AvantGarde-Book-iso

Control: retitle -1 Error: /typecheck in /findfont on AvantGarde-Book-iso On 2014-08-06 03:27:17 +0200, Vincent Lefevre wrote: Can't find (or can't open) font file /usr/share/ghostscript/9.05/Resource/Font/AvantGarde-Boo-isok. Can't find (or can't open) font file AvantGarde-Boo-isok. I

Bug#723719: ghostscript: New Upstream Version 9.10 available

Control: retitle -1 ghostscript: New Upstream Version 9.14 available Any news? On 2014-04-10 10:50:36 -0700, Jonathan Nieder wrote: Ghostscript 9.07 and newer use the AGPL. I assume that would be fine for most uses but it's possible some rdeps would need to be updated to provide a download

Bug#752394: cups installation hangs in triggers

I could reproduce the problem when trying to downgrade to 1.7.3-6 because lpq freezes with the new version. Here's the backtrace of the lpstat process: (gdb) bt #0 0x7fede844de9d in __libc_recv (fd=6, buf=0x7fede9789400, n=5, flags=-1) at ../sysdeps/unix/sysv/linux/x86_64/recv.c:29 #1

Bug#752394: cups installation hangs in triggers

On 2014-06-24 08:05:43 +0200, Didier 'OdyX' Raboud wrote: Le mardi, 24 juin 2014 02.13:10, vous avez écrit : On 2014-06-23 19:02:50 +0200, Didier 'OdyX' Raboud wrote: Can you reproduce this problem or was it a one-off problem? I tried to reproduce the problem by doing a reinstall on the

Bug#752394: cups installation hangs in triggers

Package: cups Version: 1.7.3-3 Severity: grave Justification: renders package unusable During an upgrade, I got: [...] Processing triggers for cups (1.7.3-3) ... Then, nothing for 3 minutes. A ps output showed: UIDPID PPID C STIME TTY TIME CMD root 20661 20645 0 13:03

Bug#752394: cups installation hangs in triggers

On 2014-06-23 19:02:50 +0200, Didier 'OdyX' Raboud wrote: Can you reproduce this problem or was it a one-off problem? I tried to reproduce the problem by doing a reinstall on the cups related packages. I even did: apt-get install --reinstall libslang2:amd64 libboost-iostreams1.54.0:amd64

Bug#731140: ghostscript: on PDF files with embedded fonts, ps2pdf changes the way fonts are rendered

Package: ghostscript Version: 9.05~dfsg-8 Severity: normal ps2pdf should not change the embedded fonts except by optimizing them (e.g. compressing them), but a simple test shows that it changes the way fonts are rendered. I've attached 3 files. font1.pdf is the original file (generated by

Bug#731164: ghostscript: ps2pdf makes highlighted/annotated text unreadable by poppler-based PDF viewers

On 2013-12-02 17:15:19 +0100, Vincent Lefevre wrote: When I use ps2pdf on a file with highlighted/annotated text (as produced by Apple's Preview on Mac OS X 10.6.8), this text is displayed below the background with poppler-based PDF viewers (xpdf, evince, okular). Same behavior

Bug#711848: closed by Didier Raboud o...@debian.org (Bug#711848: fixed in cups 1.6.2-10)

On 2013-07-10 10:07:59 -0400, Michael Sweet wrote: Vincent, I just did extensive testing and figured out that it is sort-of a race condition between cupsServer() getting called and ippNewRequest() - when you specify -h on the command-line it forces the default IPP version to get set

Bug#711848: closed by Didier Raboud o...@debian.org (Bug#711848: fixed in cups 1.6.2-10)

On 2013-07-09 11:17:51 +0200, Vincent Lefevre wrote: On 2013-07-08 07:30:45 -0400, Michael Sweet wrote: And the same patch for CUPS 1.6.x... This patch doesn't work. I get the following error: $ lpr bfrange-test.pdf lpr: Error - add '/version=1.1' to server name. while I have

Bug#711848: closed by Didier Raboud o...@debian.org (Bug#711848: fixed in cups 1.6.2-10)

On 2013-07-09 10:46:15 -0400, Michael Sweet wrote: Strange, what happens if you do: lpr -H lip-printserver1.lip.ens-lyon.fr/version=1.1 bfrange-test.pdf This one is OK: I do not get the error, and lpr asks for the password. -- Vincent Lefèvre vinc...@vinc17.net - Web:

Bug#711848: closed by Didier Raboud o...@debian.org (Bug#711848: fixed in cups 1.6.2-10)

On 2013-06-27 11:28:51 +0200, Vincent Lefevre wrote: This problem still occurs after the upgrade to cups 1.6.2-10. In the changelog: printers' list to avoid jobs to go to unexpected printers (Closes: #711848) This patch was modifying the cupsGetDests2() function, which was already

Bug#704238: Need to document the CUPS client's new server-version option

On 2013-06-20 10:41:56 -0400, Michael Sweet wrote: On 2013-06-06, at 2:59 AM, Didier 'OdyX' Raboud o...@debian.org wrote: ... ServerName cups.example.com/version=1.1 Indeed. That's confirmed to address Vincent's issue. Although it's kinda surprising that it's impossible to detect

Bug#704238: Need to document the CUPS client's new server-version option

On 2013-06-20 10:46:00 -0400, Michael Sweet wrote: Given that this is only a problem for users depending on the ServerName directive in client.conf, it seemed much more practical (and reliable) to have the user/administrator specify any version limitations there. The initial problem is that

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

This may be related, but lpstat with a printer argument gives an error: ypig:~ lpstat lipucb-mono-1 lpstat: Bad Request even though: ypig:~ lpstat -a | grep lipucb-mono-1 lipucb-mono-1 accepting requests since 2013-06-11T11:04:54 CEST -- Vincent Lefèvre vinc...@vinc17.net - Web:

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

Package: cups-client Version: 1.6.2-8 Severity: grave Tags: security Justification: user security hole I have the following options in .cups/lpoptions: Dest lip-multi-3 ColorModel=Gray Resolution=1200dpi Default lipucb-mono-1 The lpq command gives as expected: lipucb-mono-1 is ready no entries

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

On 2013-06-10 11:50:52 +0200, Didier 'OdyX' Raboud wrote: But when I print a document with lpr file.pdf, I get nothing on this printer. Then I tried: lp file.pdf, and I get nothing either on this printer, but the following line was output in the terminal: When trying here with either lpr

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

Hi, On 2013-06-10 13:27:47 +0200, Didier 'OdyX' Raboud wrote: Can you provide the access rights of .cups/lpoptions? $ ls -l ~/.cups/lpoptions ypig:~ ls -l ~/.cups/lpoptions -rw-r--r-- 1 vlefevre vlefevre 74 2013-02-01 16:29:37 /home/vlefevre/.cups/lpoptions I've also done a strace

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

If I output some messages in the cupsGetNamedDest() function of cups/dest.c as shown below: /* * Get the printer's attributes... */ fprintf (stderr, cupsGetNamedDest: %s\n, name ? name : ); if (!_cupsGetDests(http, op, name, dest, 0, 0)) { if (op == CUPS_GET_DEFAULT || (name

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

On 2013-06-10 15:48:18 +0200, Vincent Lefevre wrote: If I output some messages in the cupsGetNamedDest() function of cups/dest.c as shown below: /* * Get the printer's attributes... */ fprintf (stderr, cupsGetNamedDest: %s\n, name ? name : ); if (!_cupsGetDests(http, op, name

Bug#711848: cups-client: lp and lpr print the document on a wrong printer

, Debian CUPS co-maintainer P.S. If you'd prefer other means of contacts regarding the CUPS bugs, feel free to point me towards them. Le lundi, 10 juin 2013 16.07:46, Vincent Lefevre a écrit : If I understand correctly, there may be actually 2 problems: 1. _cupsGetDests(http, op, name

Bug#704238: Need to document the CUPS client's new server-version option

On 2013-06-06 08:59:19 +0200, Didier 'OdyX' Raboud wrote: Vincent: I'm hereby merging both 704238 and 711192 as the latter is and occurence of the first. Also, thanks for testing the four possibilities, it confirms Daniel's documentation below. I've also tested that the following worked:

Bug#711327: cups-client: the -h option has no effect

On 2013-06-06 15:30:13 +0100, Brian Potkin wrote: 3. The -h option takes precedance over a user/system client.conf file and the CUPS_SERVER environment variable. Using an alternative server we would execute lpstat -h hostname[:port] -a -v This doesn't work either. For instance,

Bug#711327: cups-client: the -h option has no effect

On 2013-06-06 17:58:38 +0200, Didier 'OdyX' Raboud wrote: What do the following commands give? $ lpstat -H $ lpstat -h localhost -H $ lpstat -h localhost:631 -H ypig% lpstat -H lip-printserver1.lip.ens-lyon.fr:631 ypig% lpstat -h localhost -H lip-printserver1.lip.ens-lyon.fr:631 ypig%

Bug#711192: cups-client: clients (lpstat, lpq...) no longer work via http

Package: cups-client Version: 1.6.2-8 Severity: grave Justification: renders package unusable The CUPS clients no longer work via http: ypig:~ lpq -P lipucb-mono-1 lpq: Unknown destination lipucb-mono-1. ypig:~ lpstat -a lpstat: Bad Request I don't know what information is needed.

Bug#711192: cups-client: clients (lpstat, lpq...) no longer work via http

On 2013-06-05 23:05:40 +0200, Didier 'OdyX' Raboud wrote: It doesn't appear to be wildly documented; can you try the following versions? ServerName lip-printserver1.lip.ens-lyon.fr/version=1.1 ServerName lip-printserver1.lip.ens-lyon.fr/version=1.1 ServerName

Bug#622598: hplip: depends on libsane-hpaio 3.11.1-2 instead of 3.11.1-2+b1

Package: hplip Version: 3.11.1-2+b1 Severity: grave Justification: renders package unusable hplip 3.11.1-2+b1 depends on libsane-hpaio 3.11.1-2 instead of 3.11.1-2+b1 thus cannot be installed. -- Package-specific info: error: NOT FOUND! This is a REQUIRED/RUNTIME ONLY dependency. Please make