Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #183991 > unrolled thread

cups

Back to article view | Back to linux.debian.user

Contents

  cups Pol Hallen <deben@fuckaround.org> - 2017-07-20 20:00 +0200
    Re: cups Mark Fletcher <mark27q1@gmail.com> - 2017-07-21 00:50 +0200
    Re: cups Gene Heskett <gheskett@shentel.net> - 2017-07-21 03:00 +0200
      Re: cups Curt <curty@free.fr> - 2017-07-21 10:50 +0200
    Re: cups Erik Christiansen <dvalin@internode.on.net> - 2017-07-21 08:20 +0200
      Re: cups Darac Marjal <mailinglist@darac.org.uk> - 2017-07-21 10:30 +0200
    Re: cups Brian <ad44@cityscape.co.uk> - 2017-07-21 20:40 +0200
      Re: cups Pol Hallen <deben@fuckaround.org> - 2017-07-22 15:10 +0200
        Re: cups Brian <ad44@cityscape.co.uk> - 2017-07-23 18:20 +0200
          Re: cups Pol Hallen <deben@fuckaround.org> - 2017-07-23 21:10 +0200
            Re: cups Brian <ad44@cityscape.co.uk> - 2017-07-24 13:20 +0200
              Re: cups Pol Hallen <deben@fuckaround.org> - 2017-07-24 20:50 +0200
                Re: cups Brian <ad44@cityscape.co.uk> - 2017-07-24 22:10 +0200
                  Re: cups Pol Hallen <deben@fuckaround.org> - 2017-07-24 22:30 +0200
                    Re: cups Brian <ad44@cityscape.co.uk> - 2017-07-24 22:50 +0200
                      Re: cups Pol Hallen <deben@fuckaround.org> - 2017-07-24 23:00 +0200

#183991 — cups

Hi all :-)

can someone tell me how cups handles pdf files?

I've cups on server and some clients connected to it (ipp://ip/printer)

 From client I print (ie: a 300Kb of pdf), in log cups server I see that 
file size about 4/5Mb (why?), so the printer before print it I've to 
wait also 15 minutes :-/

This happens only with a client with debian testing (and latest update 
of cups) before this updates no problem.

thanks for help and advices :-)))
-- 
Pol

[toc] | [next] | [standalone]

#184015

On Thu, Jul 20, 2017 at 07:51:19PM +0200, Pol Hallen wrote:
> Hi all :-)
> 
> can someone tell me how cups handles pdf files?
> 
> I've cups on server and some clients connected to it (ipp://ip/printer)
> 
> From client I print (ie: a 300Kb of pdf), in log cups server I see that file
> size about 4/5Mb (why?), so the printer before print it I've to wait also 15
> minutes :-/
> 
> This happens only with a client with debian testing (and latest update of
> cups) before this updates no problem.
> 
> thanks for help and advices :-)))

Total guess here, and no doubt Brian or someone who's a real CUPS expert 
will reply shortly, but I'm wondering if your PDF file contains a lot of 
images? Or a single large image? My guess is the client is assuming 
(probably correctly, I would have thought) that it has to preprocess 
those images from some potentially-highly-compressed format into a 
bitmap format of one kind or another to send to the printer, and that is 
causing it to take more space. That could explain the much larger size 
of what is being processed than the size of the document. Shouldn't take 
15 minutes to print a document even in that case though. Is it 15 mins 
of nothing apparently happening at all or 15 minutes of the printer 
futzing around looking like it's getting ready to print but not actually 
taking the paper and getting on with it? I have that latter symptom on 
my system (for 1-2 minutes, not 15!) when I haven't printed for a while 
and the printer decides that the moment I need a document in a hurry is 
the moment to clean the print nozzles...

Mark

[toc] | [prev] | [next] | [standalone]

#184019

On Thursday 20 July 2017 13:51:19 Pol Hallen wrote:

> Hi all :-)
>
> can someone tell me how cups handles pdf files?
>
> I've cups on server and some clients connected to it
> (ipp://ip/printer)
>
>  From client I print (ie: a 300Kb of pdf), in log cups server I see
> that file size about 4/5Mb (why?), so the printer before print it I've
> to wait also 15 minutes :-/
>
> This happens only with a client with debian testing (and latest update
> of cups) before this updates no problem.
>
> thanks for help and advices :-)))

A .pdf file is quite compressed. I've had a 12 meg pdf unpack to several 
gigabytes, and use close to 800 pages of Georgia-Pacifics finest 24 lb 
bright white to make it into dead tree format.

The method of makeing the pdf, is actually one of the better compressors 
extant.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#184035

On 2017-07-21, Gene Heskett <gheskett@shentel.net> wrote:
>
> A .pdf file is quite compressed. I've had a 12 meg pdf unpack to several 
> gigabytes, and use close to 800 pages of Georgia-Pacifics finest 24 lb 
> bright white to make it into dead tree format.

My better half prints PDFs (knitting diagrams, mostly) from a wireless
windows client via ipp to my Brother HL-2030 connected via usb and never
ever has it taken anywhere close to fifteen minutes of cogitation for
the printer to start spitting out copy (in fact it's always been a
matter of a handful of seconds). 

Are we sure there is no problem to be identified?

Maybe the log files could be revealing.

> The method of makeing the pdf, is actually one of the better compressors 
> extant.
>
> Cheers, Gene Heskett


-- 
“We’ll sit around talking about the good old days, when we wished that we were dead.”
--Samuel Beckett, speculating on the nature of the afterlife.

[toc] | [prev] | [next] | [standalone]

#184028

On 20.07.17 19:51, Pol Hallen wrote:
> From client I print (ie: a 300Kb of pdf), in log cups server I see that file
> size about 4/5Mb (why?), so the printer before print it I've to wait also 15
> minutes :-/

Is the file for the printer postscript? That is always bigger than the
pdf equivalent, even before you get to the fancy compression of images
that Gene mentions.

A printer with a slow processor can take many minutes to process large
volumes of postscript. I have a small HP 3-in-1 laserprinter, and it can
be slow. I don't remember how PCL5 compares to postscript for speed.

> This happens only with a client with debian testing (and latest update of
> cups) before this updates no problem.

That may be "why", but the file format will elucidate "how", which is the
technically revealing bit.

Erik

[toc] | [prev] | [next] | [standalone]

#184033

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 21, 2017 at 04:19:02PM +1000, Erik Christiansen wrote:
>On 20.07.17 19:51, Pol Hallen wrote:
>> From client I print (ie: a 300Kb of pdf), in log cups server I see that file
>> size about 4/5Mb (why?), so the printer before print it I've to wait also 15
>> minutes :-/
>
>Is the file for the printer postscript? That is always bigger than the
>pdf equivalent, even before you get to the fancy compression of images
>that Gene mentions.
>
>A printer with a slow processor can take many minutes to process large
>volumes of postscript. I have a small HP 3-in-1 laserprinter, and it can
>be slow. I don't remember how PCL5 compares to postscript for speed.

That's because Postscript isn't an image format, it's a drawing
language. For example, this fairly simple looking postscript file [1]
will use the printer's postscript engine to calculate a full-page
Mandelbrot fractal. Some printers can take *hours* to perform all the
necessary calculations required to render the page.

[1] https://gist.github.com/dln/bc88911f6bf8e55856d9

>
>> This happens only with a client with debian testing (and latest update of
>> cups) before this updates no problem.
>
>That may be "why", but the file format will elucidate "how", which is the
>technically revealing bit.
>
>Erik
>

-- 
For more information, please reread.

[toc] | [prev] | [next] | [standalone]

#184047

On Thu 20 Jul 2017 at 19:51:19 +0200, Pol Hallen wrote:

> Hi all :-)
> 
> can someone tell me how cups handles pdf files?

Impossible to say in your situation without knowing the printer make
and model and the PPD used.

> I've cups on server and some clients connected to it (ipp://ip/printer)

Please post the outputs of 'lpstat -t' and 'lpoptions -p <queue_name> on
the client. (<queue_name> is the printer the PDF is sent to).

> From client I print (ie: a 300Kb of pdf), in log cups server I see that file
> size about 4/5Mb (why?),

Impossible to say because we do not know how you printed on the client.
The 4/5MB was obtained from http://localhost:631/jobs?which_jobs=all on
the server?

>                          so the printer before print it I've to wait also 15
> minutes :-/

Impossible to diagnose without information from sources others have
suggested you look at.

> This happens only with a client with debian testing (and latest update of
> cups) before this updates no problem.

What happens when the PDF is printed from the server with lp?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#184075

Hello and thanks to all :)

> Impossible to say in your situation without knowing the printer make
it's a lexmark e460dn: I tried also ppd from lexmark website and many 
from foomatic, etc
I tried the ppd from a debian stable installation (where there printers 
runs) but same problem

> Please post the outputs of 'lpstat -t' and 'lpoptions -p <queue_name> on
> the client. (<queue_name> is the printer the PDF is sent to).

device for E460DN: ipp://192.168.1.100/printers/E460DN
E460DN accepting requests since Sat 22 Jul 2017 02:50:39 PM CEST
printer E460DN now printing E460DN-2253.  enabled since Sat 22 Jul 2017 
02:50:39 PM CEST
E460DN-2253             max             282624   Sat 22 Jul 2017 
02:50:39 PM CEST

>>  From client I print (ie: a 300Kb of pdf), in log cups server I see that file
>> size about 4/5Mb (why?),
> 
> Impossible to say because we do not know how you printed on the client.
> The 4/5MB was obtained from http://localhost:631/jobs?which_jobs=all on
> the server?

file size of pdf is 789K: printing from debian testing, on server jobs I 
see 13Mb

same file using debian stable, on server jobs I see 1043K and works

> What happens when the PDF is printed from the server with lp?

same situation

thanks for help

Pol

[toc] | [prev] | [next] | [standalone]

#184136

On Sat 22 Jul 2017 at 14:55:19 +0200, Pol Hallen wrote:

> Hello and thanks to all :)
> 
> >Impossible to say in your situation without knowing the printer make
> it's a lexmark e460dn: I tried also ppd from lexmark website and many from
> foomatic, etc
> I tried the ppd from a debian stable installation (where there printers
> runs) but same problem

The PPD is probably not the problem; The Debian one should be good enough
to use.
 
> >Please post the outputs of 'lpstat -t' and 'lpoptions -p <queue_name> on
> >the client. (<queue_name> is the printer the PDF is sent to).
> 
> device for E460DN: ipp://192.168.1.100/printers/E460DN
> E460DN accepting requests since Sat 22 Jul 2017 02:50:39 PM CEST
> printer E460DN now printing E460DN-2253.  enabled since Sat 22 Jul 2017
> 02:50:39 PM CEST
> E460DN-2253             max             282624   Sat 22 Jul 2017 02:50:39 PM
> CEST

Looks ok. The size of the file being processed is 282624, so you are
sending the 300K PDF. However, it looks like you are processing twice:
once on the client and again on the server. This is not recommended. It
works for you because the client produces PostScript (the e460dn is a
PostScript printer) and the server will accept and process PostScript.

For the testing client, post the output of

  lpoptions -p e460dn

and the content of /etc/cups/printers.conf.
  
> >> From client I print (ie: a 300Kb of pdf), in log cups server I see that file
> >>size about 4/5Mb (why?),
> >
> >Impossible to say because we do not know how you printed on the client.
> >The 4/5MB was obtained from http://localhost:631/jobs?which_jobs=all on
> >the server?
> 
> file size of pdf is 789K: printing from debian testing, on server jobs I see
> 13Mb

The testing client is producing the 13MB PostScript file, probably with
Ghostscript. For very complex PDFs the processing time can be long and
the file size large. We might get some idea of time and size with

  time pdf2ps 789K_PDF output.ps

Post the screen display and the output of 'ls -l output.ps'
 
> same file using debian stable, on server jobs I see 1043K and works

It does not appear the stable client is doing processing of the input
PDF in the same way as the stable client. 1043K is not much bigger than
789K and could be due to the printing application used. (An application
such as Evince does not send the original file to the server but a new
one that it produces).

Post the outputs of

  ls -l /etc/cups/ppd

and

  lpoptions -p <queue>

from the stable client machine.

> >What happens when the PDF is printed from the server with lp?
> 
> same situation

Is it jessie, stretch or testing on the server? Is it possible to
provide links to the two PDFs you mention?

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#184144

Hi Brian

 >For the testing client, post the output of
 >lpoptions -p e460dn

lpoptions -p E460DN.fuckaround.org
copies=1 device-uri=ipp://10.10.10.1/printers/E460DN finishings=3 
job-cancel-after=10800 job-hold-until=no-hold job-priority=50 
job-sheets=none,none marker-change-time=1500823547 
marker-colors=#000000,none,none marker-levels=-1,100,-1 
marker-names='Toner\ nero,Unit?\ di\ fusione,Kit\ manutenzione' 
marker-types=toner,other,other number-up=1 
printer-commands=AutoConfigure,Clean,PrintSelfTestPage 
printer-info=E460DN.fuckaround.org printer-is-accepting-jobs=true 
printer-is-shared=false printer-is-temporary=false printer-location 
printer-make-and-model='Lexmark E460dn Foomatic/Postscript' 
printer-state=3 printer-state-change-time=1500823572 
printer-state-reasons=none printer-type=10530844 
printer-uri-supported=ipp://localhost/printers/E460DN.fuckaround.org

 >and the content of /etc/cups/printers.conf.

<Printer E460DN.fuckaround.org>
UUID urn:uuid:93096773-7e23-3138-6562-d82e1935b64f
AuthInfoRequired none
Info E460DN.fuckaround.org
MakeModel Lexmark E460dn Foomatic/Postscript
DeviceURI ipp://10.10.10.1/printers/E460DN
State Idle
StateTime 1500823572
ConfigTime 1500823259
Type 8433692
Accepting Yes
Shared No
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job
Attribute marker-colors \#000000,none,none
Attribute marker-levels -1,100,-1
Attribute marker-names Toner nero,Unit? di fusione,Kit manutenzione
Attribute marker-types toner,other,other
Attribute marker-change-time 1500823547
</Printer>

 >time pdf2ps 789K_PDF output.ps

time pdf2ps 158.pdf 158.ps

real	0m3.482s
user	0m3.164s
sys	0m0.312s

 >Post the screen display and the output of 'ls -l output.ps'

ls -l 158.ps
-rw-r--r-- 1 max max 12180217 Jul 23 20:14 158.ps

 > same file using debian stable, on server jobs I see 1043K and works

 >Post the outputs of
 >ls -l /etc/cups/ppd

-rw-r----- 1 root lp 10364 Jul 23 17:20 E460DN.fuckaround.org.ppd
-rw-r----- 1 root lp 10372 Jul 23 17:20 E460DN.fuckaround.org.ppd.O

lpoptions -p <queue>

from the stable client machine.

 >Is it jessie, stretch or testing on the server?

I making test with 2 servers: one it's old-old stable, another with 
old-stable server (same situation: from debian stable everything works)

lpstat -d E460DN
E460DN-2544             max            9726976   Sun 23 Jul 2017 
08:30:00 PM CEST

that's the problem: 9726976

when I print from stable debian, on cups server file size is correct: 760832

lpstat -d E460DN
system default destination: E460DN.fuckaround.org_via_VNC_from_misha
E460DN-2547             psycheye        760832   Sun 23 Jul 2017 
09:05:57 PM CEST

thanks!

Pol

[toc] | [prev] | [next] | [standalone]

#184163

On Sun 23 Jul 2017 at 21:09:01 +0200, Pol Hallen wrote:

> Hi Brian
> 
> >For the testing client, post the output of
> >lpoptions -p e460dn
> 
> lpoptions -p E460DN.fuckaround.org
> copies=1 device-uri=ipp://10.10.10.1/printers/E460DN finishings=3
> job-cancel-after=10800 job-hold-until=no-hold job-priority=50
> job-sheets=none,none marker-change-time=1500823547
> marker-colors=#000000,none,none marker-levels=-1,100,-1 marker-names='Toner\
> nero,Unit?\ di\ fusione,Kit\ manutenzione' marker-types=toner,other,other
> number-up=1 printer-commands=AutoConfigure,Clean,PrintSelfTestPage
> printer-info=E460DN.fuckaround.org printer-is-accepting-jobs=true
> printer-is-shared=false printer-is-temporary=false printer-location
> printer-make-and-model='Lexmark E460dn Foomatic/Postscript' printer-state=3

This is the PPD being used by the E460DN queue. It confirms my
suspicion that filtering to produce a PostScript file takes place
on the client.

> printer-state-change-time=1500823572 printer-state-reasons=none
> printer-type=10530844
> printer-uri-supported=ipp://localhost/printers/E460DN.fuckaround.org
> 
> >and the content of /etc/cups/printers.conf.
> 
> <Printer E460DN.fuckaround.org>
> UUID urn:uuid:93096773-7e23-3138-6562-d82e1935b64f
> AuthInfoRequired none
> Info E460DN.fuckaround.org
> MakeModel Lexmark E460dn Foomatic/Postscript
> DeviceURI ipp://10.10.10.1/printers/E460DN
> State Idle
> StateTime 1500823572
> ConfigTime 1500823259
> Type 8433692
> Accepting Yes
> Shared No
> JobSheets none none
> QuotaPeriod 0
> PageLimit 0
> KLimit 0
> OpPolicy default
> ErrorPolicy retry-job
> Attribute marker-colors \#000000,none,none
> Attribute marker-levels -1,100,-1
> Attribute marker-names Toner nero,Unit? di fusione,Kit manutenzione
> Attribute marker-types toner,other,other
> Attribute marker-change-time 1500823547
> </Printer>

Looking for any sign of cups-browsed. A bit pointless considering what
is on the server!
 
> >time pdf2ps 789K_PDF output.ps
> 
> time pdf2ps 158.pdf 158.ps
> 
> real	0m3.482s
> user	0m3.164s
> sys	0m0.312s

Just over 3 seconds to convert a PDF to a PostScript file. But
15 minutes to have the job printed. Surely this would mean the
server or the printer is the bottleneck?

> >Post the screen display and the output of 'ls -l output.ps'
> 
> ls -l 158.ps
> -rw-r--r-- 1 max max 12180217 Jul 23 20:14 158.ps
>
> > same file using debian stable, on server jobs I see 1043K and works
> 
> >Post the outputs of
> >ls -l /etc/cups/ppd
> 
> -rw-r----- 1 root lp 10364 Jul 23 17:20 E460DN.fuckaround.org.ppd
> -rw-r----- 1 root lp 10372 Jul 23 17:20 E460DN.fuckaround.org.ppd.O
> 
> lpoptions -p <queue>
> 
> from the stable client machine.
> 
> >Is it jessie, stretch or testing on the server?
> 
> I making test with 2 servers: one it's old-old stable, another with
> old-stable server (same situation: from debian stable everything works)

The filtering is distinctly different on these distributions from
post-wheezy. I've forgotten the details, but it could be a factor.

> lpstat -d E460DN
> E460DN-2544             max            9726976   Sun 23 Jul 2017 08:30:00 PM
> CEST
> 
> that's the problem: 9726976
> 
> when I print from stable debian, on cups server file size is correct: 760832
> 
> lpstat -d E460DN
> system default destination: E460DN.fuckaround.org_via_VNC_from_misha
> E460DN-2547             psycheye        760832   Sun 23 Jul 2017 09:05:57 PM
> CEST

If the file file arriving at the server is unchanged in size (or
practically so) it would indicate no processing is taking place
on the stable client. Please post the output of 'lpoptions -p ...'
for the queue there.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#184183

A discovered that: debian testing before sending to cups server my pdf 
file uses ghostscript with ps2write and send ps file to. So the original 
pdf (about 200/300K) becomes a ps file with 9Mb of size :-/

this is the header of file:

%!PS-Adobe-3.0
%%HiResBoundingBox: 0 0 596.00 842.00
%%Creator: GPL Ghostscript 921 (ps2write)
%%LanguageLevel: 2
%%CreationDate: D:20170724202031+02'00'
%%For: (max)
%%Title: (158.pdf)

Forcing remove ghostscript local cups doesn't works, do you have an idea 
to create a work-around? for ghostscript ps2write is a device.

thanks for help :-)

Pol

[toc] | [prev] | [next] | [standalone]

#184188

On Mon 24 Jul 2017 at 20:46:31 +0200, Pol Hallen wrote:

> A discovered that: debian testing before sending to cups server my pdf file
> uses ghostscript with ps2write and send ps file to. So the original pdf
> (about 200/300K) becomes a ps file with 9Mb of size :-/

Indeed. A PostScript file is produced because the queue uses a PPD which
instructs it to do this.
 
> this is the header of file:
> 
> %!PS-Adobe-3.0
> %%HiResBoundingBox: 0 0 596.00 842.00
> %%Creator: GPL Ghostscript 921 (ps2write)
> %%LanguageLevel: 2
> %%CreationDate: D:20170724202031+02'00'
> %%For: (max)
> %%Title: (158.pdf)
> 
> Forcing remove ghostscript local cups doesn't works, do you have an idea to
> create a work-around? for ghostscript ps2write is a device.

Ghostscript cannot be removed - cups-filters depends on it. But you can
have it not being used on the testing client by setting a queue which
avoids filtering. This would bring it into line with the stable client's
queue, which I guess also avoids filtering. (You did not answer my query
in the last mail, lpoptions -p ...; that is why it is a guess).

1. Set up this queue:

      lpadmin -p testq -v ipp://192.168.1.100/printers/E460DN -E -m raw

2. Print:

      lp -d testq 158.pdf

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#184190

> 1. Set up this queue:
>        lpadmin -p testq -v ipp://192.168.1.100/printers/E460DN -E -m raw
> 2. Print:
>        lp -d testq 158.pdf

works!!! :))) thanks

Can I create a permanently queue so to avoid filtering from this client?

Pol

[toc] | [prev] | [next] | [standalone]

#184192

On Mon 24 Jul 2017 at 22:19:43 +0200, Pol Hallen wrote:

> >1. Set up this queue:
> >       lpadmin -p testq -v ipp://192.168.1.100/printers/E460DN -E -m raw
> >2. Print:
> >       lp -d testq 158.pdf
> 
> works!!! :))) thanks
> 
> Can I create a permanently queue so to avoid filtering from this client?

You just have! But you probably don't want its name to be testq. So do

  lpadmin -p E460DN -v ipp://192.168.1.100/printers/E460DN -E -m raw

(Remove testq with 'lpadmin -x testq')

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#184193

>    lpadmin -p E460DN -v ipp://192.168.1.100/printers/E460DN -E -m raw

many thanks for your help Brian!

Cheers!

Pol

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web