0.99.7 Mac: Bug in PDF thumbnail and display

[joao]

Recently, I've come across this bug that shows up with certain matplotlib (with tex backend) created pdfs.
Xnview correctly generates the thumbnails and opens the file. But the background is grey. It should be white (it's a white box background, no transparency). Other Mac apps open the file and generate it properly.

Could someone take a look and see what is going on with this file?

Thanks.

Joao

XnView: MP 0.99.7 - 64-bit
OS: macOS Big Sur - 11.6.2
Ghostscript: 9.55.0

[xnview]

it works here, which gs version do you have?

[joao]

Thanks so much for checking it out on your system. I was afraid of that.
I'll update the original post with the system specs. The ghostscript version is 9.55.0, installed by homebrew on /usr/local/bin as standard.
I'm not sure how xnview has access to it unless that path is coded in though, as it should not be available to gui apps launched from the finder.
I have done what was recommended in the forums:

Code: Select all

sudo launchctl config user path /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

but that made no difference.* From my understanding, that should not make any difference on my system anyway, since that workaround is not meant to work on the latest MacOS versions (I'm on v.11, Big Sur). This makes sense, as that would open up all gui apps to the homebrew bin dir which may break things. From what I gather this should be written in the plist of xnview, or somewhere else. I have since reverted to the default.

I also launched xnview from the terminal, hoping it would bring in the environment variables for gs correctly. It displays the same behaviour. It also prints a bunch of errors / warnings on the terminal console, related to libpng which I don't think are relevant:

Code: Select all

libpng warning: iCCP: known incorrect sRGB profile
QCssParser::parseColorValue: Specified color without alpha value but alpha given: 'rgb 20, 20, 20, 178'
QCssParser::parseColorValue: Specified color without alpha value but alpha given: 'rgb 223, 223, 223, 255'
qt.qpa.fonts: Populating font family aliases took 874 ms. Replace uses of missing font family ".SF NS Text" with one that exists to avoid this cost.

All other image viewers and browsers are displaying the pdfs correctly (though I don't believe they use homebrew's gs). In addition, this only happens in xnview with some pdfs, like the one I sent, which is generated by latex through matplotlib.

* the forum recommendation was actually this, but there is no /opt/homebrew directory:

Code: Select all

sudo launchctl config user path /usr/bin:/bin:/usr/sbin:/sbin:/opt/homebrew/bin

Either way, would it not be possible to include the Ghostscript binary in xnview (i realise it's agpl.....)?

Here's a screenshot of what I see:

[xnview]

I had gs 9.22, i remove it and install 9.55, but always no problem.
You have not multiple gs??

Either way, would it not be possible to include the Ghostscript binary in xnview (i realise it's agpl.....)?

Not possible with their license

[joao]

You have not multiple gs??

In /usr/local no. LaTex is using the homebrew gs - I don't install the one that comes with Mactex. Just opened a terminal with the standard Macos path, there is no gs there. Can't think of anything else installing it apart from Conda.

Good to know that everything seems to work well in 9.55 as it brought a lot of changes.

I will try to revert to an older gs and get back to you (homebrew does not make this as easy as it should). Unrelated but will see if an older gs helps as well: I've also began seeing xnview hang while generating thumbnails: unresponsive, gs at full cpu in the activity monitor. Does it with the old .config files and with a new empty .config dir. Seems to happen while browsing in one specific folder.

[joao]

Been too busy to check on this but found some time today.

Cannot reproduce the issue anymore, both in XNViewMP 0.99.7 and the new 1.0 beta 2. Homebrew tells me that the Ghostscript version remains the same. The only ghostscript dependency that got an update since I opened the issue was little-cms2, for color management. Either that, a minor MacOS update, or the digital spirits fixed the issue.

Please feel free to close this bug report.
Thank you for checking it out.

Joao