Would it make sense that some thumbnails are rendering fine and others not? Because this appears to be happening and I cannot explain why. All the PDFs are produced the same way in ABBYY Reader, as searchable PDFs.
This one is fine:
These two are not:
They should all look kind of like the first image.
Presumably itās the red text thatās the problem in those 2 incorrect ones? If you have the ability to share them, the actual source PDFs would probably be helpful in determining whatās happening, or at least what should be happening.
@jflatnes I can either share them with you individually or you can create a login for our site to log in (maoistlegacy.de) and have a look. For legal reasons I canāt share them publicly anywhere.
The two thumbnails with the red text arenāt rendering at all. They should have the same texture / look as the first thumbnail with the brown pages etc. The red text is in the original PDFs, so thatās irrelevant; itās a document title that in the original is also red.
Oh, that does sound like it might be the same basic issue thenā¦ since the first one is clearly an embedded image in the PDF and the others look like theyāre just text being rendered.
You can look at some things on your own related to those PDFs: you can run pdfimages -list to see what the format of the images embedded in the PDF are (that command comes from a package usually called pdf-utils or poppler-utils). Typically weāve seen these kinds of errors with JPEG2000 images only (I believe pdfimages reports that format as jpx). You can also do a test conversion āofflineā:
convert "test.pdf[0]" test.jpg
to see if youāre getting any error output from ImageMagick. If thatās happening it may also be already in your Omeka log, if you have logging enabled. Comparing a āgoodā and ābadā PDF on those two commands above should give you an idea of whatās happening, at least if itās this kind of problem others have experienced.
Hi John - thanks for the quick response. When I run pdfimages that does seem to be the difference. Most PDFs have all jpegs, but these include several jpx images. Odd as we created them apparently the same way as all the others. Not sure what the heck happened.
In any case: to do test conversion offline, do you mean I have to extract the JPGs from the PDF and then in command prompt /terminal just convert them all? How does that work given that they are searchable PDFs???
Or really any solution to this issue would be helpful.
I just meant trying to run convert to see how/if it complains on the ābadā vs āgoodā PDFs.
A solution would probably be akin to what was described in the other thread, updating to a better version of Ghostscript. Thatās basically always been the culprit when thereās issues with JPEG2000 in PDFs in my experience. Depending on your system/distribution itās possible that thereās simply an update in the package manager you can doā¦ otherwise weāve had several people build from source to get a working version. Ghostscript happens to be a relatively easy project to build because they bundle basically all the dependencies.
Otherwiseā¦ you can extract the images themselves with pdfimages and convert thoseā¦ you could manually replace the thumbnails, or upload the images as separate filesā¦ neither is really a better option in my opinion than fixing Ghostscript/ImageMagick.
So Iām trying to do this and after doing the Ghostscript make install suddenly Iām getting some weird errors on the Omeka side. I donāt know if itās connected, Iām lost as to whatās happened!
Omeka has encountered an error
Zend_Http_Client_Adapter_Exception
Unable to Connect to ssl://maoistlegacy.de:443. Error #0: php_network_getaddresses: getaddrinfo failed: System error
exception āZend_Http_Client_Adapter_Exceptionā with message āUnable to Connect to ssl://maoistlegacy.de:443. Error #0: php_network_getaddresses: getaddrinfo failed: System errorā in /var/www/vhosts/maoistlegacy.de/httpdocs/db/application/libraries/Zend/Http/Client/Adapter/Socket.php:235 Stack trace: #0 /var/www/vhosts/maoistlegacy.de/httpdocs/db/application/libraries/Zend/Http/Client.php(1073): Zend_Http_Client_Adapter_Socket->connect(āmaoistlegacy.deā, 443, true)
ā¦ etc
This happens when trying to open an item on the admin side, but I can still thankfully view all the items on the public side.
Also, am I supposed to overwrite the old ghostscript files with the new ones? Right now there are two folders: ghostscript/gs and the latest version I just installed. Maybe thereās some weird conflict going on there?
That error doesnāt really look like itās relatedā¦ itās about your server not being able to connect over HTTPS to itselfā¦ presumably to connect to MediaWiki for Scripto purposes. Iām not sure what the issue is but I donāt think itās really happening at the Omeka levelā¦ the error indicates some kind of problem with DNS resolution on your system.
As for Ghostscriptā¦ it really depends what you did when installing it. A ādefaultā install should have gone to /usr/local so youād have /usr/local/bin/gs . Generally Iād suggest keeping things that way (installing separately rather than overwriting). If you do install to a location like that, you need to edit ImageMagickās delegates.xml file to tell it where to find your copy of gs (basically, replacing instances of just gs in the file with the full path to your desired version is the simplest option).
I didnāt think it would be related either, but I canāt figure out why it would have occurred right after I installed the latest version of ghostscript. It doesnāt make much sense; everything was fine this morning when I went it to look at the items. I cannot access them anymore from within the admin panel (any of them, not just some). I donāt know why the DNS issue would appear when I try to choose an item (not just scripto - mediawiki).
Iām considering just reverting to the backup I made 20 minutes before trying to install ghostscript.
You should have more to that error message which should tell you where the call is originating from, i.e. the rest of the traceback. But, Iād imagine itās still Scriptoā¦ unless you have something else set up to make connections to your own server like that. It may just be checking status or something similar. Of course the problem probably doesnāt have anything to do with Scripto per se, itās just that it happens to be something that will do a DNS lookup.
Itās also possible that simply restarting/reloading Apache/PHP/the server will resolve the problem.
@jflatnes you were right: restarting PHP did the trick. How oddā¦
Re: ghostscript. I installed it in where all the other libraries are under bin, but didnāt rename it to gs (itās the default ghostscript with version number). Where would the delegates.xml file be located, do you know??
I honestly canāt find this file at allā¦ itās definitely installed, I checked the version number and found convert in the /usr/bin location. I did a grep in /usr/bin and on /etc and a few other places, canāt find delegates.xml. Searching via Google not helping. Any insight?
EDIT: found it. Under /etc not /usr/bin
EDIT2: changed the delegates.xml file to replace āgsā with āghostscript-9.25ā (name of the new version) and for some reason it didnāt immediately work. Perhaps I need to restart ImageMagick?