Discussion:
Only "Print to file" in xpdf?
(too old to reply)
Mike Spencer
2023-03-25 05:45:21 UTC
Permalink
The xpdf distributed with Slack 15.0 only offers "Print to File" in
its print menu pane. Adding either:

defaultPrinter "lpr -P pdf2"

to ~/.xpdfrc doesn't change that.

I've expunged CUPS and replace it with lprng (see earlier
posts/discussion here re. CUPS) and that seems to be working fine with
Seamonkey.

Is there a way to induce xpdf to print to an lpr command?

I see that this version of xpdf calls itself XpdfReader and
references www.xpdfreader.com. That website says:

The Xpdf open source project includes a PDF viewer along with a
collection of command line tools which perform various functions
on PDF files:

xpdf: PDF viewer (click for a screenshot)

[snip list]

But the screenshot shows XpdfReader, of which the website goes on to
say:

XpdfReader, available from the download page, is a closed source
version of the PDF viewer, which includes a few extra features
not found in the open source xpdf viewer.

So what happened to open-source xpdf and what happened to printing to
an lpr command? Am I going to have to revert to the 14.2-release
version of xpdf?

(I see that Derek Noonburg's FooLabs site has passed xpdf to
xpdfreader.com and xpdf.com belongs to a completely different company
with a very different, for-fee product.)

Of course, if I'm reading a PDF file in xpdf, I can print the file
directly from the sommand line using "lpr -P pdf2 [filename]" but will
have to do extra steps if viewing a PDF passed directly from the
browser.

More niggling bother in setting up Slack 15. Watch this space; I
have more. :-)
--
Mike Spencer Nova Scotia, Canada
David Robley
2023-03-25 06:27:04 UTC
Permalink
Post by Mike Spencer
The xpdf distributed with Slack 15.0 only offers "Print to File" in
defaultPrinter "lpr -P pdf2"
to ~/.xpdfrc doesn't change that.
I've expunged CUPS and replace it with lprng (see earlier
posts/discussion here re. CUPS) and that seems to be working fine with
Seamonkey.
Is there a way to induce xpdf to print to an lpr command?
I see that this version of xpdf calls itself XpdfReader and
The Xpdf open source project includes a PDF viewer along with a
collection of command line tools which perform various functions
xpdf: PDF viewer (click for a screenshot)
[snip list]
But the screenshot shows XpdfReader, of which the website goes on to
XpdfReader, available from the download page, is a closed source
version of the PDF viewer, which includes a few extra features
not found in the open source xpdf viewer.
So what happened to open-source xpdf and what happened to printing to
an lpr command? Am I going to have to revert to the 14.2-release
version of xpdf?
(I see that Derek Noonburg's FooLabs site has passed xpdf to
xpdfreader.com and xpdf.com belongs to a completely different company
with a very different, for-fee product.)
Of course, if I'm reading a PDF file in xpdf, I can print the file
directly from the sommand line using "lpr -P pdf2 [filename]" but will
have to do extra steps if viewing a PDF passed directly from the
browser.
More niggling bother in setting up Slack 15. Watch this space; I
have more. :-)
Fresh install of Slack 15 to new bare metal; just used XPDF for the
first time, opened a document and went to the Print dialog, which
happily shows my printer as well as the print to file option.

Printer is managed by CUPS.
Henrik Carlqvist
2023-03-25 11:46:31 UTC
Permalink
Post by David Robley
Fresh install of Slack 15 to new bare metal; just used XPDF for the
first time, opened a document and went to the Print dialog, which
happily shows my printer as well as the print to file option.
Printer is managed by CUPS.
I also now tried xpdf for the first time on Slackware 15.0 and note that
the only option is "print to file" where the file type is pdf. Rather
poingless...

Usually I use an old package of Acrobat Reader to view and print pdf
files, but included in Slackware is also gv which is able to view not
only PostScript files but also pdf files. It seems as if gv is able to
print even though I am also using LPRng instead of CUPS.

regards Henrik
John Forkosh
2023-03-25 11:52:22 UTC
Permalink
<snip>
Usually I use an old package of Acrobat Reader <snip>
Do you have to install (32-bit) multilib to run that,
or can you run it under slack64 alone? If so, how?
--
John Forkosh ( mailto: ***@f.com where j=john and f=forkosh )
Jim Diamond
2023-03-25 19:00:33 UTC
Permalink
Post by John Forkosh
<snip>
Usually I use an old package of Acrobat Reader <snip>
Do you have to install (32-bit) multilib to run that,
or can you run it under slack64 alone? If so, how?
I don't know about Henrik or anyone else, but I had to install all the
multilib stuff to be able to run acroread (V 9.55). Maybe there is some
way to do it without installing multilib (containers? ...?).

Jim
Henrik Carlqvist
2023-03-26 14:52:38 UTC
Permalink
Post by John Forkosh
Do you have to install (32-bit) multilib to run that,
Yes, I have multilib installed.
Post by John Forkosh
or can you run it under slack64 alone? If so, how?
-8<-------------------------------------
file /opt/Adobe/Reader8/Reader/intellinux/bin/acroread
/opt/Adobe/Reader8/Reader/intellinux/bin/acroread: ELF 32-bit LSB
executable, Intel 80386, version 1 (SYSV), dynamically linked,
interpreter /lib/ld-lsb.so.3, stripped
-8<-------------------------------------

No, that old Acrobat Reader installation would not be possible to run
without multilib.

regards Henrik
Rich
2023-03-25 13:54:26 UTC
Permalink
Post by Mike Spencer
The xpdf distributed with Slack 15.0 only offers "Print to File" in
Mine offers both my network printer and "print to file".
Post by Mike Spencer
defaultPrinter "lpr -P pdf2"
to ~/.xpdfrc doesn't change that.
With the older xpdf from Slackware in the 14.x series, to "print to a
program" you had to prefix the command line with a pipe (|). Try:

defaultPrinter "|lpr -P pdf2"
Post by Mike Spencer
I've expunged CUPS and replace it with lprng (see earlier
posts/discussion here re. CUPS) and that seems to be working fine
with Seamonkey.
This is likely the cause of your issue. I am using the default CUPS
install. CUPS on 14.x worked fine with my printer, and pointing 15.0's
CUPS at the printer's ipp: port, and loading the PPD I had found online
when I first bought the printer, brought everything up in working
order.
Post by Mike Spencer
Is there a way to induce xpdf to print to an lpr command?
Try my pipe suggestion above.
Post by Mike Spencer
More niggling bother in setting up Slack 15. Watch this space; I
have more. :-)
This particular bother was likely brought on by your "expunging cups",
so it is not Slackware's fault. You have only yourself to blame for
that decision and the fallout that results therefrom.
Mike Spencer
2023-03-28 05:58:10 UTC
Permalink
I was hoping someone more knowledgeable than I would have a fix.
Apparently there isn't one.

I now see that five years go, Derek Noonberg explained on an xpdf
forum that he had changed from GTK to Qt libs. That means he's using
the Qt print dialog. AFAICT from

https://fossies.org/linux/xpdf/xpdf-qt/XpdfWidget.h)

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4930

inter alia the Qt print dialog backend is hardcoded to use CUPS.

There's something called Common Print Dialog Backends but if it can be
used as a hook to subvert how the Qt print dialog identifies available
printers, it's above my pay grade.
Post by Rich
With the older xpdf from Slackware in the 14.x series, to "print to a
defaultPrinter "|lpr -P pdf2"
Not on my installation. The print dialog comes up with a choice of
"print to file" or "enter a command" without that in xpdfrc.
Post by Rich
Post by Mike Spencer
I've expunged CUPS and replace it with lprng (see earlier
posts/discussion here re. CUPS) and that seems to be working fine
with Seamonkey.
This is likely the cause of your issue.
Yes, clearly. See above.
Post by Rich
Post by Mike Spencer
More niggling bother in setting up Slack 15. Watch this space; I
have more. :-)
This particular bother was likely brought on by your "expunging
cups", so it is not Slackware's fault. You have only yourself to
blame for that decision and the fallout that results therefrom.
Ha! Yes, of course. But you don't know the half of it. ;-)

<RANT>

I used to do presentations on blacksmithing for groups of 1st year MIT
students in a course on the history of technology. Part of their
reading was on Frederick Taylor, the father of "scientific management".
Taylor (q.g. if he's new to you) introduced things like standardized
shovel sizes for specific materials -- various sizes of coal, sand
etc. -- which he claimed would maximize the amount of work
accomplished by laborers using shovels. He asserted that there was
one best way for all tasks and all "workers" that would maximize
efficiency and managers should determine those ways and and enforce
their use.

Now blacksmithing was likely to be seen by students at a prestigious
university as a blue-collar labor occupation so it's reasonable to
infer that they would bring their recent Taylor reading to the
blacksmith shop. It was an opportunity for me to point out to them
that no self-respecting blacksmith would have anything to do with
Taylor's management "science".

But that's not because smiths don't care for efficiency. Blacksmiths
configure their tools and workspace very carefully. E.g., handles of
my frequently-used hammers are individually shaped to fit my hand.
Smiths coordinate timing of operations, body movement and choice of
tool moment by moment on the fly. After all, as soon as a workpiece
comes out of the fire, it's cooling off, racing toward being
unweldable or unforgeable. Every blacksmith shop is a unique
constellation of carefully crafted idiosyncrasies, ergonomic
configurations, custom-made tooling and more, all devoted to
personalized efficiency.

I shouldn't have to say, at this point, that this predisposition is
salient among the reasons why I use Slackware and not Windoes of
Ubuntu.

</RANT>
--
Mike Spencer Nova Scotia, Canada
Loading...