Qpdf

[melf]

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?

[Silvan Scherrer]

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

[melf]

Thanks for your answer Silvan. Sounds as good news with a plugin system on Qpdf and I must say I really like the app.

[Michaelhz]

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.

[ivan]

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.

[melf]

---// 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."

[Silvan Scherrer]

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

[Silvan Scherrer]

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

[Doug Bissett]

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.

[guzzi]

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?

[Doug Bissett]

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.

[ivan]

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!

[Paul Smedley]

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.

[Doug Bissett]

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...

[Pete]

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