Inability to load PDF plugin leads to inability to start Lucide

[Lewis Rosenthal]

The underlying cause is not a Lucide issue, as evidenced by the following output in POPUPLOG.OS2:

12-18-2016  13:50:11  SYS2070  PID 1035  TID 0001  Slot 01b4
C:\PROGRAMS\LUCIDE\LUCIDE.EXE
FNTCNF1->LIBCX0._read
127

(We get two of those in a row.) However, the end result is that Lucide will not start (no .TRP file is created in the Lucide directory). The above condition occurred under 1.4.0 RC4.

Renaming or removing lupopplr.dll allows Lucide to start.

It would be nice if we could load (not loading is a defect) and advise the user that we were unable to load all plugins (an enhancement).

[Gregg Young]

Lucide loads fine if poppler is the wrong version. You can't open pdfs but it loads. This appears to be a case where a poppler dependency isn't installed. I can look at the code but I'm not sure we should be test loading dlls which is probably what it would take to address this. Basically we check to see if the correct poppler is installed and only load the plugin if it is. Checking the whole dll chain isn't really practical. It might be possible to exit lupopplr.dll on failure and continue to load but Lucide might not be stable in that case. An error message might be possible.

[Lewis Rosenthal]

This is working as designed with 1.4.1 RC1. As a test, I forced the removal of openjpeg2 (rpm -e --nodeps openjpeg2) which effectively breaks poppler. Lucide loaded the plugin, but when attempting to open a document, I was presented with a "no suitable plugin available" message, which while perhaps somewhat cryptic to the uninitiated, is factually correct (well, "could not load library for the installed plugin to read the document" would be closer, but I'm not sure what poppler returns in this case.

Anyway, we can document this behavior somewhere.