*.jpg files not displayed within the PDF compiled with beamer latex

[srocheepfl]

Hi,

I have jpg files within my beamer presentation. After compiling, they are in the PDF files. But when using Dual-Screen PDF viewer, they are not displayed both on the preview and the slides. Does it need any setting to solve the problem?

Best.

[dannyedel]

Hi,

dspdfviewer does not require anything special to render images included in the PDF. I tried to create a minimal testcase which does render (see screenshot below, ~260kb) on my system.

Please try rendering (and rebuilding) the testcase aswell and see if that works (it may be an issue with your presentation, not with dspdfviewer) Please make sure to call use pdflatex directly, calling latex -> dvi2pdf (or similar) will not work correctly with jpeg images. Please also try to rebuild the testcase to ensure your LaTeX installation is allright.

If the problem is in dspdfviewer, please include the following information to help me reproduce the issue:

• What Operating System or Distribution are you running? (Debian, MacOS, Windows, Gentoo, etc)
• What version of dspdfviewer are you running? (call dspdfviewer --version)
• Did you install a binary package or compile from source?

[srocheepfl]

Hi,

Thank you for your fast answer. Even with your documents, it doesn’t work. I can compile your latex file. I get the same PDF than you with the picture inside. When launching with dspdfviewer, no picture in the “file”.

• What Operating System or Distribution are you running? (Debian, MacOS, Windows, Gentoo, etc) Windows 8.1
• What version of dspdfviewer are you running? (call dspdfviewer --version) It doesn’t give any result on my computer
• Did you install a binary package or compile from source? I used setup.exe for installing

Best regards.

Steph

[dannyedel]

Okay, this sounds like a genuine bug in dspdfviewer. I will do my best to reproduce and then fix.

@srocheepfl Do you remember which version you downloaded (v1.13.1 Qt5 / Duplication of audience screen / German translation pre-release) from the windows binaries?

@projekter: Can you check whether this is a windows-specific (or even, windows-8.1-specific) bug?

[projekter]

It seems to be Windows-specific. I have just tested the PDF. There is no JPG displayed; after that, I tried the old Qt4 version. In this, the JPG is shown. As soon as I have time, I will have a look into it. There are several possibilities. Perhaps it is a bug or misconfiguration in turbojpeg, which I used for compiling the Qt5 version. I will give it a try using the normal jpeg library.

[dannyedel]

@projekter Thanks for checking this out so quickly! The qt4 version should allow @srocheepfl to get some work done while we solve the problem. Good thing github doesn't delete old binaries : )

I will also create a regression test for this, to automatically detect if it ever breaks again.

[srocheepfl]

These are the versions I have been tested with the same bug:

v1.14-335-g9bd0175https://github.com/projekter/dspdfviewer/tree/v1.14-335-g9bd0175 v1.13-218-g83eb2d8

It’s working fine with v1.13-38-g290aed9.

[dannyedel]

@projekter: I have added a regression test to master, so this kind of thing can be caught in the future.

Once you have some time, could you git rebase the windows port against the current master, and verify that runningmake test (or ctest --output-on-failure for more detailed output) detects the image rendering failure?

[projekter]

I managed to track down the problem to one of the jpeg dependencies. Compiling without turbojpeg and OpenJPEG (using the unmaintained internal DCT and JPX decoder of poppler) displays the images properly. I don't think OpenJPEG is the problem but turbojpeg. I think I can fix the problem today.

[projekter]

Confirmed, problem is solved in #118. libjpeg/turbojpeg (I tried both and also older versions of libjpeg) triggered the problem. I found no proper solution (not even a reason), this will require some more work. But compiling poppler without libjpeg works, although not recommended. And the pictures are shown.

[projekter]

Finally, after lots of investigations, I can at least provide a more detailed description when the problem happens and why:

• The test applications delivered with poppler render the jpegs without any problems when compiled with turbojpeg.
• So does a minimal test application of mine, which just loads the PDF, creates an image of the first page and saves it to a file.
• When I create a minimal library with the only task to do the step above, and this library is called by a main program that only does this call and nothing else, it still works.
• However, as soon as I add the line Q_IMPORT_PLUGIN(QWindowsIntegrationPlugin) to the main program, the jpeg is not printed any more. (Note the problem does arise when I do not take the detour with a library!)
• I could track down the problem to poppler's DCTStream.cc file. If I once compile the programm with and without the Windows integration plugin, the functions jpeg_* (in particular jpeg_create_decompress, which either works or raises an exception) resolve to different assembly addresses). I just switched to a new computer with Visual Studio 2015, and this time, I did not want to compile Qt on my own, but instead used the pre-built versions kindly provided here. Therefore, I cannot debug Qt; however, I strongly suspect that instead of going into the functions as they are defined in turbojpeg, they are resolved to their Qt counterparts (in QtGui). And this counterparts seems to behave differently when the Windows integration plugin is loaded. Perhaps this can be solved by loading the Qt jpeg plugin, but sadly, it is not included in the pre-built version. But I suspect this name-clash with the two libraries is the reason why I had to turn off libjpeg. Changing the linker precedence did not work, either.