printing problems: CUPS, claws-mail, firefox and xpdf-4

[O. Hartmann]

Am Wed, 20 Dec 2017 10:22:03 -0700
Gary Aitken <ah at dreamchaser.org> schrieb:

> On 12/20/17 08:29, Hartmann, O. wrote:
> > At first, please CC me in your response, I'm not subscribing to the
> > list.
> > 
> > I have problems printing on FreeBSD CURRENT (12.0-CURRENT #37 r327022:
> > Wed Dec 20 15:07:55 CET 2017 amd64).
> > 
> > print/cups, graphics/xpdf, mail/claws-mail and www/firefox are of most
> > recent version as of usr/ports revvision r456793.
> > 
> > The phenomenon is that I can not print via firefox' printing facility
> > (printer symbol which should open a requester showing all the available
> > printers), neither via xpdf or claws-mail.
> > 
> > CUPS is up and running ans sockstat indicates, that cupsd is listening
> > 
> > USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS FOREIGN ADDRESS
> > root     cupsd      28838 5  tcp4   127.0.0.1:631         *:*
> > root     cupsd      28838 7  stream /var/run/cups.sock
> > 
> > Connecting via firefox and https://localhost:631 works, also printing a
> > testpage to any printer configured.
> > 
> > The not-so-funny part is that either claws-mail, xpdf or firefox'
> > printing facility seem to take a long time when selected from menu,
> > showing then nothing but printing to file. In firefox, it takes ages to
> > come up with this residual set of printing options, xpdf and claws-mail
> > are a bit faster.
> >   
> >>From the console, lpstat -a shows every configured printer and printing  
> > PS or PDF to a queue from a xterm or console works as expected.
> >   
> >>From a Linux forum I gathered some pieces of information regarding the  
> > fact that possibly gtk3 problems may the reason but recompiling the
> > usual suspicious ports didn't help, even recompiling firefox, xpdf or
> > claws-mail or poppler/podofo didn't change the situation.
> > 
> > I'm out of ideas. Maybe somebody faces the same problem and has some
> > hints - I'd appreciate any tip.  
> 
> ideas, although I'm currently fighting another issue:
> 
> Have a look at /var/log/cups and check error_log and access_log.
> Also try using complete path to commands, as the cups commands have
> the same name as non-cups ones, e.g. /usr/local/bin/lpr not lpr
> which goes to /usr/bin/lpr, the non-cups cmd.
> 
> Gary

I have already checked this (obvious) path problem, but it doesn't trigger the problem.
Even if I rename the base system's lpr command or prevent the LPR subsystem
via /etc/src.conf to be installed, the problem persists.

Prior to the update of Firefox to their "Quantum" version, R 57, I faced a similar
problem on on of our workstations: the printer window in Firefox came up quickly, but
presented only printing to a file - after a while, say 2 or 3 minutes, the CUPS served
printers (even those locally) came up. The problem magically vanished into thin air after
a update to Firefox 57.0.

The fact that on the system in question the problems appear in X11, but manually printing
via /usr/local/bin/lpr -P printer-name file.pdf/file.ps does work as expected, makes me
believe that something is out-of-synchronisation. The question is: what and how to find
it or better, how to resolve it.

The fact, that claws-mail, xpdf-4 and firefox are affected (I didn't test other software
like GIMP, Inkscape or Scribus, I'll do this later when back in the office) let me
believe it must have to do something with a commonly used subsystem ...

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20171221/cae1ccab/attachment.sig>