https://bugs.kde.org/show_bug.cgi?id=415985

Michael Weghorn <m.wegh...@posteo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |WAITINGFORINFO

--- Comment #33 from Michael Weghorn <m.wegh...@posteo.de> ---
(In reply to bruce.samha...@samhaber.ca from comment #14)
> I will repeat the whole process just to be sure. 
> It looked to me like there was lots of old log information in the Error_log
> file. Should I clear the Error_log file and how to do that, is it just
> delete it? 
> I notice that there are many lines like 
> D [28/Apr/2020:19:02:28 -0400] [Job 389] Loading from cache...
> every time I print something, but these are all for old jobs that are long
> gone. Should I get rid of those, if so how? 

Thanks for the additional information.
Those old entries are no problem.


(In reply to bruce.samha...@samhaber.ca from comment #28)
> Created attachment 128008 [details]
> New /var/log/cups/error_log   file

This new log file actually contains the relevant information.
It looks like a PostScript file is passed to CUPS (printing system) by Okular
as expected, but there is a problem in the processing inside of the printing
system; a CUPS filter (gstopdf) fails.

>From the log file:

> D [29/Apr/2020:14:18:38 -0400] [Job 602] pdftopdf: Last filter determined by 
> the PPD: foomatic-rip; FINAL_CONTENT_TYPE: application/vnd.cups-pdf => 
> pdftopdf will log pages in page_log.
> D [29/Apr/2020:14:18:38 -0400] [Job 602] STATE: -connecting-to-device
> D [29/Apr/2020:14:18:38 -0400] cupsdMarkDirty(---J-)
> D [29/Apr/2020:14:18:38 -0400] cupsdSetBusyState: newbusy="Printing jobs and 
> dirty files", busy="Dirty files"
> D [29/Apr/2020:14:18:38 -0400] cupsdMarkDirty(----S)
> D [29/Apr/2020:14:18:38 -0400] cupsdSetBusyState: newbusy="Printing jobs and 
> dirty files", busy="Printing jobs and dirty files"
> D [29/Apr/2020:14:18:38 -0400] [Job 602] Unrecoverable error: rangecheck in 
> --.trysetparams--
> D [29/Apr/2020:14:18:38 -0400] [Job 602] Operand stack:
> D [29/Apr/2020:14:18:38 -0400] [Job 602] true  true  true  --nostringval--  
> --nostringval--  --nostringval--  --nostringval--  --nostringval--  
> --nostringval--  --nostringval--  --nostringval--  true  --nostringval--  
> %MediaSource  0  %MediaDestination  0  .LockSafetyParams  true  
> --nostringval--  --nostringval--  --nostringval--  7  --nostringval--  false  
> --nostringval--
> D [29/Apr/2020:14:18:38 -0400] [Job 602] PID 5317 
> (/usr/lib/cups/filter/gstopdf) stopped with status 1.
>
> [...]
>
D [29/Apr/2020:14:18:39 -0400] [Job 602] GPL Ghostscript 9.27: ? eprn: This
document requests a page size of 0 x 0 bp.
D [29/Apr/2020:14:18:39 -0400] [Job 602] GPL Ghostscript 9.27:   This size is
not supported as a discrete size and it exceeds the
D [29/Apr/2020:14:18:39 -0400] [Job 602] custom page size limits for the HP
DeskJet 1120C.
D [29/Apr/2020:14:18:39 -0400] [Job 602] **** Unable to open the initial
device, quitting.
D [29/Apr/2020:14:18:39 -0400] [Job 602] renderer exited with status 1
D [29/Apr/2020:14:18:39 -0400] [Job 602] Possible error on renderer command
line or PostScript error. Check options.Kid3 exit status: 3
D [29/Apr/2020:14:18:39 -0400] [Job 602] PID 5319
(/usr/lib/cups/filter/foomatic-rip) stopped with status 9.
D [29/Apr/2020:14:18:39 -0400] [Job 602] PID 5320
(/usr/lib/cups/backend/parallel) exited with no errors.


It looks like there probably isn't much that can be done from Okular side in
this case.
Does this happen for every file you're trying to print? Can you attach a sample
file, so I can test whether the filter fails the same way for me on Debian
testing?
What version of the package cups-filters do you have? (as far as I I know, that
is the package that provides the gstopdf filter.)

(In reply to Christoph Feck from comment #32)
> Okular uses QPrintDialog. If it lists more/different printers than you have
> available, then it would be a bug there. This was already seen in bug
> 417186, but I don't know if the reporter opened a ticket at the Qt bug
> tracker.

Yes, I suppose this additional printer also shows up in other KDE applications,
e.g. Kate?
In case you plan to open a separate bug report for this, please leave a link
here. The 'lpstat -v' output might be helpful to find out more about this.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to