OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Applications => Topic started by: melf on January 23, 2013, 10:48:49 pm

Title: Qpdf
Post by: melf on January 23, 2013, 10:48:49 pm
I have used Qpdf, the Qt pdf reader, for a while now. It is just so much better than Lucide when scrolling among pages. No jerkiness at all, not even when viewing "heavy" pages. AFAIK both Lucide and Qpdf are based on the same "engine" (Poppler), but behave very different. How come that this runtime based app runs faster and smother than the native one?

Additionally it has the nice features of making notes and add highlights and moreover to open pdf:s in tabs. As Lucide it also works very well when filling in forms.

What I miss most is the great function in Lucide to browse among pdf:s by pressing Shift + PgUp/PgDn, the fast start up time and the plugin system. Haven't yet installed CUPS (it's a prerequisite, but it works to drop cups.dll in the program folder) so I don't know about printing.

Is it possible to make Lucide to be a such a smoothe reader as Qpdf?
Title: Re: Qpdf
Post by: Silvan Scherrer on January 24, 2013, 11:49:14 am
There are a couple of reasons Lucide is slower. One is that Lucide is poppler based, but it uses a older poppler.
Lucide is so many drawbacks (IMHO) that i gave up on it and ported Qpdfview. Qpdfview is now getting a plugin based system also. This means with Qpdfview 0.4.0 (coming soon) you can view PDF and DjVu files. If i have enough time also PS will be there.

Of course Lucide could also get the lattest poppler engine, but for that someone needs to do the work. poppler changes api a lot and those api always need to be changed by Lucide as well. This is a big issue and I'm not going to do that anymore.

so I'm sorry, but IMHO Lucide is a dead end by now.

regards
Silvan
Title: Re: Qpdf
Post by: melf on January 24, 2013, 01:27:18 pm
Thanks for your answer Silvan. Sounds as good news with a plugin system on Qpdf and I must say I really like the app.
Title: Re: Qpdf
Post by: Michael Holzapfel on January 24, 2013, 01:54:15 pm
hm.. silvan worte that qpdf will not have a plugin-based system. Beside that, it is full OK to shift some "standard" app to qt-based counterparts. At the end our system is less complex and easier to maintain. So thanks for the port!

BTW: the readme of qtpdfview is wrong:

"yum install jpeg" does not work, it is "yum install libjpeg"

Is there really a need for cups.dll? Actually cups-server is only installed on a server. I do not want to have a full cups-install on every machine.
Title: Re: Qpdf
Post by: ivan on January 24, 2013, 02:05:45 pm
The big problem I find with qpdfview is that if I try and open a pdf on another partition (qpdfview installed in e:\qt4-apps, want to open pdf in f:\download) it locks the machine solid and I have to power off and then on again.
Title: Re: Qpdf
Post by: melf on January 24, 2013, 03:32:03 pm
---// hm.. silvan worte that qpdf will not have a plugin-based system. //---


I think that was just a typo, not should probably be now:

"Qpdfview is not getting a plugin based system also. This means with Qpdfview 0.4.0 (coming soon) you can view PDF and DjVu files. If i have enough time also PS will be there."
Title: Re: Qpdf
Post by: Silvan Scherrer on January 24, 2013, 05:49:05 pm
hm.. silvan worte that qpdf will not have a plugin-based system. Beside that, it is full OK to shift some "standard" app to qt-based counterparts. At the end our system is less complex and easier to maintain. So thanks for the port!

BTW: the readme of qtpdfview is wrong:

"yum install jpeg" does not work, it is "yum install libjpeg"

Is there really a need for cups.dll? Actually cups-server is only installed on a server. I do not want to have a full cups-install on every machine.

that was really a typo. qpdfview is now getting....
i changed it already. and i will also fix the readme.

regards
Silvan
Title: Re: Qpdf
Post by: Silvan Scherrer on January 24, 2013, 05:51:49 pm
The big problem I find with qpdfview is that if I try and open a pdf on another partition (qpdfview installed in e:\qt4-apps, want to open pdf in f:\download) it locks the machine solid and I have to power off and then on again.

do you have that with other Qt apps as well?
could you describe your system a bit more? and how was Qt installed? did you open a ticket in either Qt Apps or Qt?

regards
Silvan
Title: Re: Qpdf
Post by: Doug Bissett on January 24, 2013, 06:07:56 pm
I installed QPDFView (after figuring out that there is bad information about JPEG, which should be LIBJPEG). It seems to display okay, but trying to print locks the program, and the desktop. I can CAD to CADH, and kill it, but something is wrong. Yes, I do have CUPS 1.4.8 installed, but it doesn't work very well with my printer (Canon i960, using the BJC-8200 CUPS driver, which is recommended for this printer. It works far better with the OMNI driver for the Canon i950).

On the bright side, I no longer have a mangled display, when scrolling a few lines at a time (at least I haven't seen such a thing, yet). I was never able to get Lucide to edit a PDF file, and QPDFView does do that, although I am not sure that the font that it uses will be acceptable to the government bureaucrats for the form that I want to edit. I will need to compare what it does to Acrobat reader in windows.

I am not sure why I would want plugins. All I ever use Lucide, or now QPDFView, for, is to read, and print, PDF files (and now, possibly, to edit them, as allowed). Since QPDFView won't print (for me), I guess I need to keep Lucide for that job.

The big problem I find with qpdfview is that if I try and open a pdf on another partition (qpdfview installed in e:\qt4-apps, want to open pdf in f:\download) it locks the machine solid and I have to power off and then on again.

I tried that. It works okay, for me. That may indicate that something in printer support is causing a problem. AH!. My CUPS printer driver is installed on my boot drive (poor choice of location, but not worth moving it now). The test, that hung, that I did was on my data drive, where I installed QPDFView. I copied the test PDF to my boot drive, and it opens with no trouble. It still hangs when I click Print. KLibc Pathrewriters might be needed. I will need to find the time to experiment with that stuff.
Title: Re: Qpdf
Post by: guzzi on January 24, 2013, 06:38:58 pm
If I try to open a pdf from another directory than that where qpdfview is installed it complains about popqt44.dll not found. So it seems to me that qpdfview doesn't look in it's own directory for its dlls. Is that correct and does it have to be placed in the path or at least do the dlls have to be moved to a directory in the path?
Title: Re: Qpdf
Post by: Doug Bissett on January 24, 2013, 09:28:39 pm
If I try to open a pdf from another directory than that where qpdfview is installed it complains about popqt44.dll not found. So it seems to me that qpdfview doesn't look in it's own directory for its dlls. Is that correct and does it have to be placed in the path or at least do the dlls have to be moved to a directory in the path?

Two things should help. One is that the Working Directory (in the program icon properties) should be the directory where QPDFView is installed. The other is that you should have ".;" (dot semi-colon, without the quotes) in the LibPath statement, in CONFIG.SYS. That is usually close to the beginning of that line. Having the dot entry tells the system to look in the current path (the Working directory) for DLLs. Of course, if you try to use QPDFView from the command line, you need to put the install directory in LibPath, or put the DLLs in a directory that is in the LibPath.
Title: Re: Qpdf
Post by: ivan on January 24, 2013, 09:29:42 pm
Hi Silvan,

I tried it on three systems all running AMD64 processors, 1 single core, 1 2 core and the third a 4 core unit.  All have 4GB memory and WSeB, with SMP on the two multi core.

So far I have 22 QT4 apps that I use without any problems at all, open files from anywhere.  QT4 is installed in os2\apps\qt4.

Out of curiosity I tried running it on the standby server, an HP DL385 with 2 2 core AMD processors and 32GB ram running WSeB.  It locked that solid as well when I tried to open a PDF that was on a different partition.


Edit to add that it works as expected if the PDFs are on the same partition a qpdfview, generally mine are not!
Title: Re: Qpdf
Post by: Paul Smedley on January 24, 2013, 11:14:23 pm
hm.. silvan worte that qpdf will not have a plugin-based system. Beside that, it is full OK to shift some "standard" app to qt-based counterparts. At the end our system is less complex and easier to maintain. So thanks for the port!

BTW: the readme of qtpdfview is wrong:

"yum install jpeg" does not work, it is "yum install libjpeg"

Is there really a need for cups.dll? Actually cups-server is only installed on a server. I do not want to have a full cups-install on every machine.

cups.dll is used to support printing as it provides the cient side api's to talk to a cups server.
Title: Re: Qpdf
Post by: Doug Bissett on January 25, 2013, 12:21:00 am
cups.dll is used to support printing as it provides the cient side api's to talk to a cups server.

Hmmm. That might explain some of the odd occurrences that I see when trying to print using CUPS. I have this:
--------------------
 6-10-12  6:57p       920,419    124 a---  cups.dll
        1 file(s)     920,419 bytes used

Directory of M:\cups\sbin

 8-31-11  6:19p       869,291      0 a---  cups.dll
        1 file(s)     869,291 bytes used
------------------------------

Which one is right? Neither one of them is in LibPath. Perhaps that explains why I can't print from QPDFView. AHA!, yes it does. I tried BeginLibPath to M:\cups\lib and it no longer hangs. It still doesn't print. It pops up a message box that says "Could not print <the file name>". Not extremely helpful, but better than a hang. Now, to try more things...
Title: Re: Qpdf
Post by: Pete on January 25, 2013, 03:20:54 am
Hi All

Having extracted the libjpeg.dll and zlib.dll from the zip files and put them on the libpath then unzipped qpdf and created a qPDF program object and gave it a try.

Seems to work well - no problem opening pdf files on different partitions here.

Printing does not work. Having checked the CUPS Jobs I see that is because the job state is:-

stopped
"Unable to execute pdftops program: No such file or directory"

I opened a command window and had a check for the file

[J:\]dir pdftops* /s

The volume label in drive J is eCSApps.
The Volume Serial Number is 969D:85C1.

Directory of J:\cups\lib\cups\filter

11-06-12  6:10a        11,316    124 a--r  pdftops.exe
        1 file(s)      11,316 bytes used


I tried to print a different document and this failed with:-

stopped
"/cups/lib/cups/filter/pdftops.exe failed"

In both instances the cups log shows "Unable to execute pdftops program: No such file or directory"

The file exists so the question is: Is this a CUPS or qpdf error?

As both Paul and Silvan seem to be reading this thread I'm hoping for a definitive answer and maybe a fix?


Regards

Pete
Title: Re: Qpdf
Post by: Silvan Scherrer on January 25, 2013, 11:49:53 am
which cups do you have? you need very latest cups.dll from Paul, as older ones did not work with Qt Apps.

regards
Silvan
Title: Re: Qpdf
Post by: Doug Bissett on January 25, 2013, 10:45:53 pm
which cups do you have? you need very latest cups.dll from Paul, as older ones did not work with Qt Apps.

I thought I had the latest, but apparently the latest is only available in the ZIP file download.

11-03-12 10:41p       913,935    124 a---  cups.dll

(MM-DD-YY). So, now I can print ONCE, after a boot. I can use other apps to print through CUPS, but QPDFView only prints once, then it complains that is could not print. On the down side, if I print using CUPS (ANY program), I end up with one (of 4) of my CPUs stuck at 99.9%, for about 10 minutes, after the print is finished. Then, that stops. While it is stuck, I have a LOT of trouble doing other things. After it stops, everything seems to be normal again. I can find no indication of what is hogging CPU time. TOP doesn't show it, only the Pulse widget shows it.
Title: Re: Qpdf
Post by: Doug Bissett on January 26, 2013, 12:10:34 am
I found another problem with QPDFView. It has put two directories in the root of my boot drive: .config and .local. Normally, those things follow the %HOME% environment variable, which certainly does not point to the root of my boot drive.
Title: Re: Qpdf
Post by: melf on January 26, 2013, 12:37:15 am
For me qpdf makes directories in D:\home\default\.config and .local.  My bootdrive is C: and Qpdf is in D:\APPS\Qpdf.
Title: Re: Qpdf
Post by: Doug Bissett on January 27, 2013, 01:45:19 am
It looks like the FIRST time I open QPDFView, it puts entries into %HOME%, as I expect ("adds" entries would be more accurate). The second time I open it, it puts the same entries into the root of my boot drive. My boot drive is M:, and QPDFView is in W:\APPS\QPDFVIEW. The PDF file is in W:\DOWNLOAD. The working directory, in the program icon, is set to W:\APPS\QPDFVIEW. CUPS is on M:.

I will say that when it works, QPDFView is pretty good, although I do have a discrepancy about what the real Acrobat Reader , in windows, does, and what QPDFView does, when editing fields in a PDF file. I need to figure that out, and report it somewhere.
Title: Re: Qpdf
Post by: Pete on January 27, 2013, 10:22:41 pm
Hi All

Having updated cups to the very latest I can now print from qpdf - once. Any attempt to print another document fails - nothing happens.

In order to try and see what the problem is I attempted to start my browser. No go, Seamonkey will not start with any established Profiles or with the Profile Manager.

I closed qpdf and retried Seamonkey - which started without problems.

So, qpdf can print once and does not allow Seamonkey to start while qpdf is running. No problem starting qpdf with Seamonkey already running though.

I had a look at my cups log to see what had gone wrong with my 3 printing attempts (after the successul print). The answers are:-

/cups/lib/cups/filter/pstoraster failed"
/cups/lib/cups/filter/pstoraster failed"
"/cups/lib/cups/filter/pdftops.exe failed"

Obviously qpdf needs a bit more work but looks promising.

Regards

Pete


Title: Re: Qpdf
Post by: Dave Yeo on February 06, 2013, 10:08:12 pm

In order to try and see what the problem is I attempted to start my browser. No go, Seamonkey will not start with any established Profiles or with the Profile Manager.

I closed qpdf and retried Seamonkey - which started without problems.

So, qpdf can print once and does not allow Seamonkey to start while qpdf is running. No problem starting qpdf with Seamonkey already running though.


The problem is that the fntcfg2.dll shipped with qpdf is incompatible with SeaMonkey and probably Firefox and Thunderbird 10.12. Fix is to replace it with the one meant for Mozilla,
or remove it and have the Mozilla versions in your libpath.
The freetyp2.dll for Mozilla is probably newer as well.
Title: Re: Qpdf
Post by: Silvan Scherrer on February 07, 2013, 10:28:26 am
this will be fixed with the upcoming qpdf 0.4.0 beta1. and yes the freetype dll coming with qpdfview is a bit older than the one from dave.
Title: Re: Qpdf
Post by: Paul Smedley on February 08, 2013, 09:53:08 am
this will be fixed with the upcoming qpdf 0.4.0 beta1. and yes the freetype dll coming with qpdfview is a bit older than the one from dave.

welcome to DLL hell :( - a reason I tend to use static linking - larger executables but no clashes of dll versions
Title: Re: Qpdf
Post by: Andy Willis on February 09, 2013, 05:11:01 am
this will be fixed with the upcoming qpdf 0.4.0 beta1. and yes the freetype dll coming with qpdfview is a bit older than the one from dave.

welcome to DLL hell :( - a reason I tend to use static linking - larger executables but no clashes of dll versions
This was a concern I had with not to continue static linking it into Mozilla.  However, as long as the newer dll works with the older apps it is not unexpected that an app would require the newer dll.  The windows DLL hell was that newer versions of their DLLs such as the mfc ones would break compatibility and not work with older apps so that you had to have multiple versions lying around.
Title: Re: Qpdf
Post by: ivan on May 11, 2013, 05:27:04 pm
Reviving this old topic but I would like to know if anyone has got the latest drop to open a PDF file?

All I get when I try to open a PDF is a message box marked Critical with the statement Could not load PDF plug-in!

I have followed the instructions as closely as possible (no ecs dir on WSeB so dlls go into os2\dll), what am I missing?
Title: Re: Qpdf
Post by: melf on May 11, 2013, 08:35:01 pm
I had the same message Ivan, but now it works. I think I just deleted Qpdf:s home directory and let it make a new one, but in fact I don't remember entirely sure.
Title: Re: Qpdf
Post by: ivan on May 12, 2013, 10:52:50 am
Thanks melf but that didn't do anything - still the same message.  I'm wondering if it has the ecs file structure hard wired in as the readme says to put the dlls into ecs\dll.
Title: Re: Qpdf
Post by: Silvan Scherrer on May 12, 2013, 11:09:29 am
Which qpdf Version? And there is no hard wired ECS/DLL structure in it.
Im sure you Miss some DLL. Try To redirect output and See which.
Title: Re: Qpdf
Post by: ivan on May 12, 2013, 06:00:28 pm
Thanks for your reply Silvan.

The version that gives the error message is v0.4.1 and I think I have all the DLLs required but I'm not sure as there is no definitive list.  The fact that all the other Qt4 apps that I am using work without any problems shows that Qt4 and the gcc and klibc dlls are installed correctly.  Cups sometimes prints to the printer on the network print server but I think those problems are caused by the print server going into standby mode and not being woken up correctly.

I have z.dll, jpeg.dll, djv.dll, fntcfg2.dll and freetyp2.dll in \os2\dll so the question is what am I missing.

Note that version 0.3.7b1 works as long as the PDF files are on the same volume as qpdf.
Title: Re: Qpdf
Post by: Silvan Scherrer on May 13, 2013, 10:14:56 am
please try to redirect the output with qpdfview >out.txt and qpdfview 2>out2.txt and see if there is an error. as there must be a missing dll. and i'm almost sure the latest qpdfview readme is exact on what you need.
Title: Re: Qpdf
Post by: ivan on May 13, 2013, 01:31:55 pm
Thank you Silvan.

Out.txt was blank
out2.txt is attached.  The qpdfpdf.dll is in the same directory as qpdfview.exe, I also tried with it in \os2\dll and got the same results.
Title: Re: Qpdf
Post by: Silvan Scherrer on May 13, 2013, 01:58:30 pm
I have z.dll, jpeg.dll, djv.dll, fntcfg2.dll and freetyp2.dll in \os2\dll so the question is what am I missing.
from what date are the fntcfg2.dll, freetyp2.dll and jpeg.dll?

Title: Re: Qpdf
Post by: Silvan Scherrer on May 13, 2013, 02:47:19 pm
Thank you Silvan.

Out.txt was blank
out2.txt is attached.  The qpdfpdf.dll is in the same directory as qpdfview.exe, I also tried with it in \os2\dll and got the same results.

to load qpdfpdf.dll you need at least libc065.dll, Qtcore4.dll, QtXml4.dll, gcc446.dll, stdcpp.dll poppqt44.dll, popp34.dll, tiff.dll, jpeg.dll
so either you miss one of those or it's a wrong one.
Title: Re: Qpdf
Post by: ivan on May 13, 2013, 03:25:35 pm
To answer your questions.
fntcfg2.dll 05/01/13
freetyp2.dll 05/01/13
jpeg.dll 19/12/11

All the dlls you list are in \os2\dll or the program directory.
Title: Re: Qpdf
Post by: Silvan Scherrer on May 13, 2013, 05:31:12 pm
To answer your questions.
fntcfg2.dll 05/01/13
freetyp2.dll 05/01/13
jpeg.dll 19/12/11

All the dlls you list are in \os2\dll or the program directory.
search on hobbes for chkdll32 and see if poppqt44.dll and popp34.dll can load all dependencies.

and it would not hurt to install qpdfview 0.4.2 beta 1, as it has some fixes also. but qpdfview 0.4.2 uses popp36.dll instead of popp34.dll
Title: Re: Qpdf
Post by: Silvan Scherrer on May 13, 2013, 05:42:21 pm
if it's not on hobbes get it from here http://www.os2site.com/sw/dev/dll/

and use chkdll32 -! popp34.dll and see if all dll can be loaded
Title: Re: Qpdf
Post by: Silvan Scherrer on May 13, 2013, 05:51:49 pm
if it's not on hobbes get it from here http://www.os2site.com/sw/dev/dll/

and use chkdll32 -! popp34.dll and see if all dll can be loaded

or even better use pmdll from hobbes.
Title: Re: Qpdf
Post by: ivan on May 13, 2013, 07:16:56 pm
This is getting very frustrating.  Pmdll shows that all the dependencies are loaded apparently without problems yet I still get the error that it can not the pdf.
Title: Re: Qpdf
Post by: Silvan Scherrer on May 13, 2013, 07:50:13 pm
i hope you did it via cmdline and from the same dir as you invoke qpdfview.exe.
try also pmdll against qpdfpdf.dll
which qt version do you have? and how did you install qt? by hand or via rpm?
Title: Re: Qpdf
Post by: ivan on May 13, 2013, 08:46:18 pm
Progress of a sort. 

I downloaded qpdfview 0.4.2b1 and tried that.  It opens PDF files!!  Downside the PDF files have to be in the same volume as Qpdfview - try opening a pdf on another volume and it locks the WPS requiring a reset button restart.

Qpdfpdf.dll also appears to have no problems.

I will now move Qpdfview 0.4.2b1 to the same volume as the bulk of the PDF files and continue testing but I like what I see at the moment.

Qt4 is v4.7.3 ga2 according to the change log. 
Qt4 was originally installed using warpin but has been updated from zip files using the same directory structure and placement.  As I said all the other Qt4 applications work without problems. CoolReader3 is especially well used for checking how epubs appear - thank you for that - now a question, how much work is it to port a Qt4 based application, I'm wondering if I could do anything like getting Sigil more up to date?

 
Title: Re: Qpdf
Post by: Silvan Scherrer on May 14, 2013, 09:59:23 am
Progress of a sort. 

I downloaded qpdfview 0.4.2b1 and tried that.  It opens PDF files!!  Downside the PDF files have to be in the same volume as Qpdfview - try opening a pdf on another volume and it locks the WPS requiring a reset button restart.
thats really strange and has for sure nothing to do with qpdfview. either a broken qt installation or a old xwp or....

Qpdfpdf.dll also appears to have no problems.

I will now move Qpdfview 0.4.2b1 to the same volume as the bulk of the PDF files and continue testing but I like what I see at the moment.
sounds good for me

Qt4 is v4.7.3 ga2 according to the change log.
Qt4 was originally installed using warpin but has been updated from zip files using the same directory structure and placement.  As I said all the other Qt4 applications work without problems. CoolReader3 is especially well used for checking how epubs appear - thank you for that - now a question, how much work is it to port a Qt4 based application, I'm wondering if I could do anything like getting Sigil more up to date?
to update a qt app is usually not a big problem, but you need to have a good working build env. and that mostly the biggest problem.
Title: Re: Qpdf
Post by: Silvan Scherrer on May 14, 2013, 03:43:47 pm
I'm wondering if I could do anything like getting Sigil more up to date?
Sigil is one of the special cases, as it already needs Qt5 and we don't have that atm. So no chance to get a recent version i'm afraid.
Title: Re: Qpdf
Post by: ivan on May 14, 2013, 11:22:55 pm
Sigil is one of the special cases, as it already needs Qt5 and we don't have that atm. So no chance to get a recent version i'm afraid.

As far as I remember Sigil 0.5.3 is the last version that works with Qt4.7.3.  Sigil 0.6.0 series require Qt4.8.x and Sigil 0.7.x requires Qt5.0.x.

I found Sigil 0.5.3 was very usable with many improvements over the v0.2 that Paul produced, which I still use for quick corrections to epubs - saves having to start windows in VirtualBox/2.

If you can tell me what is needed to setup a build environment I have a spare computer I can dedicate to the task.  It should give me something to do in the long evenings and, hopefully, keep my mind in trim - they say old dogs can't learn new tricks but this one is going to try.
Title: Re: Qpdf
Post by: Silvan Scherrer on May 15, 2013, 02:30:57 pm
If you can tell me what is needed to setup a build environment I have a spare computer I can dedicate to the task.  It should give me something to do in the long evenings and, hopefully, keep my mind in trim - they say old dogs can't learn new tricks but this one is going to try.
first you need a working rpm env. with that set up see: http://svn.netlabs.org/rpm/wiki/RpmHowToDevelopers for seting up the basic build env. to have qt4-devel you need also "yum install qt4-devel-kit".
this gives you a good starting point and as long as qt projects use .pro files qmake produces you the makefiles. also read the qt4 readme about shadow building.

have fun
Silvan
Title: Re: Qpdf
Post by: Neil Waldhauer on June 26, 2013, 01:52:40 am
Reviving an old thread, I tried qpdfview 0.4.3 and at first I only got an error message "could not load pdf plugin", but then I deleted %home%\.config\Trolltech.ini and pdf loaded fine.

Now I'm seeing the whole pdf on the screen, but when I print, I get only the first page. I tried both an eCups and a non-eCups printer, and both print only the first page.
Title: Re: Qpdf
Post by: Silvan Scherrer on June 26, 2013, 11:49:53 am
Reviving an old thread, I tried qpdfview 0.4.3 and at first I only got an error message "could not load pdf plugin", but then I deleted %home%\.config\Trolltech.ini and pdf loaded fine.
Thats a known problem and fixed for the next Qt release. This happened when not all requirements are there, when you try to open a pdf the first time.
Now I'm seeing the whole pdf on the screen, but when I print, I get only the first page. I tried both an eCups and a non-eCups printer, and both print only the first page.
Hmm printing to a non-eCups printer? You need cups always and you need the very latest cups, as earlier ones had problems with printing pdf.
Title: Re: Qpdf
Post by: Neil Waldhauer on July 23, 2013, 03:13:32 am
OK, I tried from a ecups printer, with the latest version from a fresh install of a recent eCS 2.2 beta. QPDFview displays the document well, but the print lacks most of the text. The document is a tax form for the State of California.

https://www.ftb.ca.gov/forms/2012/12_540.pdf

Lucide prints and displays the document perfectly.

Sorry about the non-eCups printer remark above, I must have been mistaken.