[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: cups



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.



Reply to: