Author Topic: qpdfview  (Read 34586 times)

Neil Waldhauer

  • Hero Member
  • *****
  • Posts: 1024
  • Karma: +24/-0
    • View Profile
    • Blonde Guy
qpdfview
« on: March 04, 2015, 04:58:04 am »
I'm trying to run qpdfview-0_4_14-GA, but when I open a pdf, I get a message box saying

could not load plug-in for type 'PDF'

I think I loaded all the prerequisites. Is there a way to find out why it could not load the plug-in?
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #1 on: March 04, 2015, 05:32:52 am »
Try PMDLL. It will probably tell you which DLL you need. I had to put the QPDFView directory into LibPath. Just using BeginLibPath didn't cut it, for some reason.

FWIW, I updated to qpdfview-0_4_14-GA this afternoon. I needed to do some updates from the RPM ZIP files (as described). I got QPDFView to work, but AOO4.1.1 was crashing hard, when i tried to start it. It would either initiate a system dump, hang hard (no mouse movement), or just spontaneously reboot. After messing around with that for a while, I restored my boot drive, AOO, and QPDFView. Now the older versions are working. Something, somewhere, is really broken, and I don't have the time to try to sort it out.

I have decided that YUM means "DLL HELL". It may make life a little easier for those who port *NIX programs, but it is starting to make life very difficult for users.

Neil Waldhauer

  • Hero Member
  • *****
  • Posts: 1024
  • Karma: +24/-0
    • View Profile
    • Blonde Guy
Re: qpdfview
« Reply #2 on: March 04, 2015, 03:40:12 pm »
Well, I'd hope to know which dll files, or yum commands. Because the install.os2 isn't clear on that. get some zip files from the ftp site, but what are the names of the zip files? Once you have the correct zip files, which files from the zip files are needed?

That's the information that is incomplete in install.os2. And for developers of the package; they already had the files, so they didn't experience the need to describe them fully.

I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?
Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

Silvan Scherrer

  • Full Member
  • ***
  • Posts: 200
  • Karma: +1/-0
    • View Profile
Re: qpdfview
« Reply #3 on: March 04, 2015, 04:08:17 pm »
Well, I'd hope to know which dll files, or yum commands. Because the install.os2 isn't clear on that. get some zip files from the ftp site, but what are the names of the zip files? Once you have the correct zip files, which files from the zip files are needed?

That's the information that is incomplete in install.os2. And for developers of the package; they already had the files, so they didn't experience the need to describe them fully.

I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?
what yum commands are not clear? Imho the install.os2 is written with the enduser in mind.

regards
Silvan
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #4 on: March 04, 2015, 06:04:35 pm »
Quote
I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?

I agree, that you should not need to use PMDLL, but it seems to be necessary, far too often. I just start with the EXE file, and see where that takes me.

Quote
what yum commands are not clear?

Well, ALL of them if you want the correct answer. When YUM actually works, it seems to do some magic, that makes no sense to the average user. When it fails (which happens far too often), it can leave a user hung up, with little choice but to restore their system from a backup, since trouble shooting what YUM does, or doesn't do, is almost impossible for a user, that is really the only recourse that a user has.

Quote
Imho the install.os2 is written with the enduser in mind.

No it isn't (although it is better than many). It is written with the programmer in mind. If it was written for the end user, it would have a lot more detail, like proper links to the exact files, and instructions, including commands, on how to extract the proper files, and where to put them. If a guy like Neil (who is an experienced OS/2 programmer) has trouble with it, so will every average user. And don't tell me that I must use YUM. That is a non starter. I would rather spend some time sorting out ZIP files, than trying to sort out a YUM screwup (which I have been doing far too much of lately, while testing the Arca Noae Package Manager, which works great, until YUM screws up - usually indicating that there was no problem. Then the user is up the creek, without a paddle).
« Last Edit: March 04, 2015, 06:48:21 pm by Doug Bissett »

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #5 on: March 04, 2015, 06:47:41 pm »
Quote
could not load plug-in for type 'PDF'

Okay, after restoring my boot drive (to get the DLLs back where they were), QPDFView, and AOO4.1.1, last night, I tried again. This time, I did not just follow the directions. I simply updated QPDFView, then tried it. It opened, and closed. Okay, POPUPLOG.OS2 mentions POPPLER, so I updated POPPLER. Now, QPDFView opens, but complains that it can't find the PDF plugin. Odd, it is in the directory with the program, and I do have the dot entry in LibPath. PMDLL shows that QPDFPDF.DLL loads properly, but QPDFView still can't find it. On a hunch, I copied the QPDFView directory to my boot drive (the DLLs are in \eCS\DLL). Now, QPDFView opens, and it can find the plugin (the plugin is still in the QPDFView directory).  This is, of course, unacceptable.

The KLIBC Pathrewriter may be a fix, if I can figure out exactly what it needs. Another possible fix, is to simply give up, and move all of the system DLLs to the drive where I install software. That, in turn, really complicates life because it means that I need to figure out how to handle having two boot systems, sharing that stuff, and it screws up almost every installer. I suppose that I could just keep the *NIX junk on the programs drive, and keep the OS/2 DLLs on the boot drive. It may also be a good idea to use the *NIX directory structure, so that programmers don't have to think about what they are, or are not, doing.
« Last Edit: March 04, 2015, 06:49:16 pm by Doug Bissett »

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #6 on: March 04, 2015, 09:58:18 pm »
Okay the QPDFView install instructions point you to http://rpm.netlabs.org/release/00/zip. There, you find three versions of PTHREAD, the newest is pthread-20140814-16_oc00.zip. This is the one that is causing the hard crash with AOO4.1.1. Version pthread-20140425-15_oc00.zip does not cause the problem, and it works with QPDFView. This problem also happens when you use YUM to update PTHREAD. If you downgrade to the older version, you can fix the crash problem. Then, of course, you need to remember that you did that, and you need to try again when/if the package gets updated (which doesn't mean that it will fix the problem).

I tried moving the DLLs to the programs drive. QPDFView still can't find the PDF plugin. It seems that qpdfview-0_4_14-GA must be installed on the boot drive, or it can't find the PDF plugin (and probably the other plugins as well). Programs, like QPDFView do not belong on a boot drive.

Neil Waldhauer

  • Hero Member
  • *****
  • Posts: 1024
  • Karma: +24/-0
    • View Profile
    • Blonde Guy
Re: qpdfview
« Reply #7 on: March 04, 2015, 10:16:54 pm »
Well, I'd hope to know which dll files, or yum commands. Because the install.os2 isn't clear on that. get some zip files from the ftp site, but what are the names of the zip files? Once you have the correct zip files, which files from the zip files are needed?

That's the information that is incomplete in install.os2. And for developers of the package; they already had the files, so they didn't experience the need to describe them fully.

I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?
what yum commands are not clear? Imho the install.os2 is written with the enduser in mind.

regards
Silvan

In install.os2, I can either use yum or not. I prefer to use yum. Where there are yum commands, they are clear. But then

djvulibre
---------

  not available as a rpm at this time of writing

cups
----

  not available as a rpm at this time of writing

ghostscript
-----------

  not available as a rpm at this time of writing


I'm not completely clear what is going on here. Come to think of it, how does qpdfview find ghostscript?

Well, so far I can't get it to work. I have 4.1.13 working, so all is not lost.

Thanks to Doug for all the ideas, but so far, none are working.

Expert consulting for ArcaOS, OS/2 and eComStation
http://www.blondeguy.com

ivan

  • Hero Member
  • *****
  • Posts: 1557
  • Karma: +17/-0
    • View Profile
Re: qpdfview
« Reply #8 on: March 04, 2015, 10:49:52 pm »
You would think that the qpdfview zip file would include all the required DLLs because they all appear to be dependant on each other and you have install them all for anything to work.

Since they are all required DLLs is it too difficult to adjust qpdfview.exe such that it looks in its install directory first to find what it wants in the way of support files?

Since most uses of qpdfview is to read pdf files (at least here it is) why not allow users to select what other features they want to use and give a page in the settings that allows the user to give the whereabouts of such things as ghostscript, cups and freetype/fontconfig?

Because of problems with the last few builds of qpdfview we have now standardised on the last lucide build, for both us and our clients, for reading pdf files and ghostscript for printing where necessary.

TeLLie

  • Full Member
  • ***
  • Posts: 226
  • Karma: +11/-0
    • View Profile
Re: qpdfview
« Reply #9 on: March 04, 2015, 10:55:15 pm »
Hihi
As  readme says for zip install:


djvulibre
---------

  1. Download djvulibre from ftp://ftp.netlabs.org/pub/unixos2/djvulibre-3_5_25.zip
  2. Unpack and install djvu.dll to your libpath eg. x:\ecs\dll

cups
----

  1. Go to eCUPS wiki to see how to install eCUPS (http://svn.netlabs.org/ecups)
  2. Install eCUPS according to the above wiki

ghostscript
-----------

  1. Download ghostscript as zip from ftp://ftp.netlabs.org/pub/unixos2/gs910os2.zip
  2. Unpack and install the gsdll2.dll to your libpath eg. x:\ecs\dll
     (note this ghostscript should be compatible with P. Smedley's 9.10 port, but his ports lack
     some features needed for qpdfview)

Silvan Scherrer

  • Full Member
  • ***
  • Posts: 200
  • Karma: +1/-0
    • View Profile
Re: qpdfview
« Reply #10 on: March 05, 2015, 06:35:06 am »
Well, I'd hope to know which dll files, or yum commands. Because the install.os2 isn't clear on that. get some zip files from the ftp site, but what are the names of the zip files? Once you have the correct zip files, which files from the zip files are needed?

That's the information that is incomplete in install.os2. And for developers of the package; they already had the files, so they didn't experience the need to describe them fully.

I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?
what yum commands are not clear? Imho the install.os2 is written with the enduser in mind.

regards
Silvan

In install.os2, I can either use yum or not. I prefer to use yum. Where there are yum commands, they are clear. But then

djvulibre
---------

  not available as a rpm at this time of writing

cups
----

  not available as a rpm at this time of writing

ghostscript
-----------

  not available as a rpm at this time of writing


I'm not completely clear what is going on here. Come to think of it, how does qpdfview find ghostscript?

Well, so far I can't get it to work. I have 4.1.13 working, so all is not lost.

Thanks to Doug for all the ideas, but so far, none are working.

I will rephrase this part, that it gets more clear.
regards
Silvan
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

Silvan Scherrer

  • Full Member
  • ***
  • Posts: 200
  • Karma: +1/-0
    • View Profile
Re: qpdfview
« Reply #11 on: March 05, 2015, 06:37:06 am »
Quote
I should not have to use PMDLL. Even if I did, what is the base plugin DLL to start with?

I agree, that you should not need to use PMDLL, but it seems to be necessary, far too often. I just start with the EXE file, and see where that takes me.

Quote
what yum commands are not clear?

Well, ALL of them if you want the correct answer. When YUM actually works, it seems to do some magic, that makes no sense to the average user. When it fails (which happens far too often), it can leave a user hung up, with little choice but to restore their system from a backup, since trouble shooting what YUM does, or doesn't do, is almost impossible for a user, that is really the only recourse that a user has.

Quote
Imho the install.os2 is written with the enduser in mind.

No it isn't (although it is better than many). It is written with the programmer in mind. If it was written for the end user, it would have a lot more detail, like proper links to the exact files, and instructions, including commands, on how to extract the proper files, and where to put them. If a guy like Neil (who is an experienced OS/2 programmer) has trouble with it, so will every average user. And don't tell me that I must use YUM. That is a non starter. I would rather spend some time sorting out ZIP files, than trying to sort out a YUM screwup (which I have been doing far too much of lately, while testing the Arca Noae Package Manager, which works great, until YUM screws up - usually indicating that there was no problem. Then the user is up the creek, without a paddle).
So if you think you can do it better, why don't you contribute?
Everyone is free to send readme/install text proposals.

regards
Silvan
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: qpdfview
« Reply #12 on: March 05, 2015, 07:27:09 am »
Quote
You would think that the qpdfview zip file would include all the required DLLs because they all appear to be dependent on each other and you have install them all for anything to work.

Yeah, but that introduces duplicate DLLs, which WILL cause a problem later, or, it introduces the possibility of breaking something else (note that updating the PTHREAD package to the latest version, breaks AOO4.1.1, and that package appears to have been around since August), or both. Who knows what has been broken, and not yet noticed, by simply updating DLLs, whether you use YUM, or not. Those who have used the AOO-4111-GA-rpm.wpi package to make AOO4.1.1 work, will eventually have DLL problems (if they don't already), simply because that package installs common DLLs, used by many programs, in the program directory, leaving what could be down level DLLs in the default DLL directory. Eventually one, or the other, will become down level, and something else won't work because of that. It could be very difficult to sort it out, because it will depend on which DLL gets loaded first, whether something will run, or fail.

The whole thing is totally out of control.

Quote
Because of problems with the last few builds of qpdfview we have now standardised on the last lucide build

Personally, I thought that the first QPDFView build was far better than the last Lucide build. It is obvious that whoever is doing QPDFView needs a lot more help with beta testing, to avoid these silly problems. Meanwhile, rather than using Lucide, I would be more inclined to stay with older versions of QPDFView (assuming that some other thing doesn't break them, which is entirely too possible).

Quote
So if you think you can do it better, why don't you contribute?

Nobody can do it better. RPM/YUM is a total disaster, and there aren't enough people using OS/2 to test each package properly to be sure that they work. I am working with the Arca Noae Package Manager (currently called Yumie). It would work well, if YUM would do things the way it was advertized to do. One of the main problems is that YUM screws up, then tells Yumie that all is well. At other times, YUM tries to update itself, and turns into a vegetable until somebody figures out what went wrong, and figures out how to fix the problem. More often, something goes wrong, and nobody knows why. Trying again about 2 days later, and it works, as if nothing happened. Now updating PTHREAD kills AOO4.1.1. It is depressing.

Personally, I do some WarpIn packages, but I will make no attempt to try to keep up with what is going on in your world, because it appears that you don't even know what is going on.

Silvan Scherrer

  • Full Member
  • ***
  • Posts: 200
  • Karma: +1/-0
    • View Profile
Re: qpdfview
« Reply #13 on: March 05, 2015, 08:17:59 am »
Quote
You would think that the qpdfview zip file would include all the required DLLs because they all appear to be dependent on each other and you have install them all for anything to work.

Yeah, but that introduces duplicate DLLs, which WILL cause a problem later, or, it introduces the possibility of breaking something else (note that updating the PTHREAD package to the latest version, breaks AOO4.1.1, and that package appears to have been around since August), or both. Who knows what has been broken, and not yet noticed, by simply updating DLLs, whether you use YUM, or not. Those who have used the AOO-4111-GA-rpm.wpi package to make AOO4.1.1 work, will eventually have DLL problems (if they don't already), simply because that package installs common DLLs, used by many programs, in the program directory, leaving what could be down level DLLs in the default DLL directory. Eventually one, or the other, will become down level, and something else won't work because of that. It could be very difficult to sort it out, because it will depend on which DLL gets loaded first, whether something will run, or fail.

The whole thing is totally out of control.

Quote
Because of problems with the last few builds of qpdfview we have now standardised on the last lucide build

Personally, I thought that the first QPDFView build was far better than the last Lucide build. It is obvious that whoever is doing QPDFView needs a lot more help with beta testing, to avoid these silly problems. Meanwhile, rather than using Lucide, I would be more inclined to stay with older versions of QPDFView (assuming that some other thing doesn't break them, which is entirely too possible).

Quote
So if you think you can do it better, why don't you contribute?

Nobody can do it better. RPM/YUM is a total disaster, and there aren't enough people using OS/2 to test each package properly to be sure that they work. I am working with the Arca Noae Package Manager (currently called Yumie). It would work well, if YUM would do things the way it was advertized to do. One of the main problems is that YUM screws up, then tells Yumie that all is well. At other times, YUM tries to update itself, and turns into a vegetable until somebody figures out what went wrong, and figures out how to fix the problem. More often, something goes wrong, and nobody knows why. Trying again about 2 days later, and it works, as if nothing happened. Now updating PTHREAD kills AOO4.1.1. It is depressing.

Personally, I do some WarpIn packages, but I will make no attempt to try to keep up with what is going on in your world, because it appears that you don't even know what is going on.
Thanks for the nice "because it appears that you don't even know whats going on." You can be sure I KNOW WHATS GOING ON!!!!

When I read such comments I really wonder why I invest sooooooooooooo much time in porting any software for free. But so it goes.
And I didn't even say you should contribute in yum or whatever. I only mentioned the readme/install text files.

So instead of writing IMHO usless stuff about how you dislike yum, send me a changed install.os2. I personally like yum and it works like a charm here. And of course you are free to dislike yum, we don't urge anyone to use it.

regards
Silvan
kind regards
Silvan
CTO bww bitwise works GmbH

Please help us with donations, so we can further work on OS/2 based projects. Our Shop is at https://www.bitwiseworks.com/shop/index.php

guzzi

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +0/-0
    • View Profile
Re: qpdfview
« Reply #14 on: March 05, 2015, 05:30:21 pm »
Quote
You would think that the qpdfview zip file would include all the required DLLs because they all appear to be dependent on each other and you have install them all for anything to work.

Yeah, but that introduces duplicate DLLs, which WILL cause a problem later, or, it introduces the possibility of breaking something else (note that updating the PTHREAD package to the latest version, breaks AOO4.1.1, and that package appears to have been around since August), or both. Who knows what has been broken, and not yet noticed, by simply updating DLLs, whether you use YUM, or not. Those who have used the AOO-4111-GA-rpm.wpi package to make AOO4.1.1 work, will eventually have DLL problems (if they don't already), simply because that package installs common DLLs, used by many programs, in the program directory, leaving what could be down level DLLs in the default DLL directory. Eventually one, or the other, will become down level, and something else won't work because of that. It could be very difficult to sort it out, because it will depend on which DLL gets loaded first, whether something will run, or fail.

The whole thing is totally out of control.

Quote
Because of problems with the last few builds of qpdfview we have now standardised on the last lucide build

Personally, I thought that the first QPDFView build was far better than the last Lucide build. It is obvious that whoever is doing QPDFView needs a lot more help with beta testing, to avoid these silly problems. Meanwhile, rather than using Lucide, I would be more inclined to stay with older versions of QPDFView (assuming that some other thing doesn't break them, which is entirely too possible).

Quote
So if you think you can do it better, why don't you contribute?

Nobody can do it better. RPM/YUM is a total disaster, and there aren't enough people using OS/2 to test each package properly to be sure that they work. I am working with the Arca Noae Package Manager (currently called Yumie). It would work well, if YUM would do things the way it was advertized to do. One of the main problems is that YUM screws up, then tells Yumie that all is well. At other times, YUM tries to update itself, and turns into a vegetable until somebody figures out what went wrong, and figures out how to fix the problem. More often, something goes wrong, and nobody knows why. Trying again about 2 days later, and it works, as if nothing happened. Now updating PTHREAD kills AOO4.1.1. It is depressing.

Personally, I do some WarpIn packages, but I will make no attempt to try to keep up with what is going on in your world, because it appears that you don't even know what is going on.

PTHREAD doesn't break AOO 4.1.1.1 here.
Installed Packages
pthread.i386                        20140814-16.oc00

QPDF works like a charm too. The last 2 versions work better than the previous ones because they don't need the 3 qpdf dll's in the path anymore for qpdfview to work in any way I choose to open it  (command line, FC/2 association, wps, firefox).

I agree that YUM isn't always very clear when something goes wrong. Then again, it doesn't go wrong all that often, and when it does it can be user error too. In general, it works well and prevents this dll hell you mentioned.

I don't want to start a flame war, but I do have to say I disagree with the way you regularly imho insult developers, this time by saying they don' know what going on. What is actually going on is that they provide us all with the software needed to keep eCS running, they fix bugs, run bug trackers and actively monitor them. Instead of flaming them a "thank you" would be more appropriate.