Test suite fails on s390x (big endian?)

[hpreusse]

Test suite fails on s390x (big endian?)

[stloeffler]

Thanks for reporting. I will have to look into building the virtual qemu machine - if you have any pointers on how to do that "right" I would appreciate it.
Two things I noted about the logs so far:

• The attached LastTest_qt6.log file shows failures in two test-suites (test_poppler-qt6 and test_Utils), whereas the log linked from the pseudo-excuse page only shows failures in test_poppler-qt6 (as does the linked LastTest_qt5.log). Is the failure in test_Utils (which seems to relate to problems running the command echo "OK") reproducible?
• The failures in test_poppler-qt6 occur in rendering test cases, i.e., the rendered page images show too large differences to the reference images. This should be investigated on a case-by-case basis, of course (e.g., by saving the rendered page images and comparing manually). However, I don't currently think that this should be related to the endianess. Also, note that specifying the exact threshold for image comparison has been difficult in the past (as the exact rendering depends on fonts, text metrics, potentially poppler version and other factors, the images will never be pixel-perfectly identical). Maybe those values need to be adjusted on this platform again - or maybe there is some other underlying problem...

[hpreusse]

* The attached `LastTest_qt6.log` file shows failures in two test-suites (test_poppler-qt6 and test_Utils), whereas the log linked from the [pseudo-excuse page](https://qa.debian.org/excuses.php?experimental=1&package=texworks) only shows failures in test_poppler-qt6 (as does the linked `LastTest_qt5.log`). Is the failure in test_Utils (which seems to relate to problems running the command `echo "OK"`) reproducible?

Yes, I've seen that too. I tend to ignore the errors in test_Utils for now, as these could be specific to my environment.

[stloeffler]

I finally managed to create a debian (bullseye) qemu image and to reproduce the issue.
I stand corrected, the problem does appear to be (at least partially) an endianness issue with the ordering of bytes in each pixel of the rendered images:

Curiously, there appears to be a change in behavior around column 310; to the left of it, the three color bytes simply seem reversed; to the right of it, an additionally 0xff seems to be shifted into the blue channel (which could be related to the fact that internally, pixel data is probably stored as 32bit values by default).

In any case, AFAICT, the image as produced by poppler (20.09.0 in my bullseye image) already has this problem, so it doesn't seem to be related to any TeXworks code itself. Could you perhaps check this in the GUI of TeXworks and other poppler-based programs? (I only have a text-based qemu image right now)

[hpreusse]

Unfortunately same here: just a text-based qemu image and I'm not sure if this can be easily changed. Let's assume I'll contact that s390 people and ask to do an experiment: what would nees to be done? Just open the file ./modules/QtPDF/unit-tests/poppler-data.pdf using a poppler based program (e.g. xpdf) and send a screen shot of the window?

[stloeffler]

Yes, that would certainly be a good start. Although I suspect that xpdf does not use the Qt bindings of poppler. So to have a situation as similar as possible, it might be better to use a Qt-based program such as okular (if that is available).

If the screenshot does not show the issue, it would also be good to know which versions of the libraries (particularly poppler/poppler-qt) were used to facilitate further testing.

If the screenshot does show the issue, then a comparison with, e.g., xpdf would be helpful in determining if the problem is in the poppler core code or in the poppler's Qt binding (which probably does some copying and adapting to Qt's internal image data format).

[stloeffler]

I can confirm that the problem exists in the underlying poppler library. The following minimal test program with poppler-qt5 shows exactly the same behavior as mentioned above:

#include <memory>
#include <poppler-qt5.h>
#include <QImage>

int main() {
  std::unique_ptr<Poppler::Document> doc{Poppler::Document::load("poppler-data.pdf")};
  std::unique_ptr<Poppler::Page> page{doc->page(0)};

  QImage img = page->renderToImage();
  img.save("test.png");
  return 0;
}

The following minimal test program with poppler-cpp (entirely independent of Qt) shows a similar issue, but now with the whole text being blue for some reason:

#include <memory>
#include <poppler-document.h>
#include <poppler-page.h>
#include <poppler-page-renderer.h>

int main() {
  std::unique_ptr<poppler::document> doc{poppler::document::load_from_file("poppler-data.pdf")};
  std::unique_ptr<poppler::page> page{doc->create_page(0)};

  poppler::page_renderer renderer;
  poppler::image img = renderer.render_page(page.get());
  img.save("test.png", "png");  
  return 0;
}

So it seems that this is not a TeXworks bug but rather a poppler bug.

Caveat: all these investigations were carried out in an old virtual machine using poppler 20.09. Could someone repeat these experiments with a more recent version of poppler?

[hpreusse]

I used

ii  libpoppler-dev:ppc64     22.12.0-2+b1 ppc64        PDF rendering library -->
ii  libpoppler-qt5-1:ppc64   22.12.0-2+b1 ppc64        PDF rendering library (Q>
ii  libpoppler-qt5-dev:ppc64 22.12.0-2+b1 ppc64        PDF rendering library -->
ii  libpoppler126:ppc64      22.12.0-2+b1 ppc64        PDF rendering library

I can confirm that the picture generated on PowerPC looks different from that on amd64. I tested the first piece of code.

[hpreusse]

I've opened Debian bug 1059943. I guess we can close the issue here,

[stloeffler]

Thanks. It's probably a bug in upstream poppler (or one of its dependencies), not in the debian packaging, though.

If you have access to a (reasonably fast) box, it might be worth-while to build the latest poppler from sources, which then comes with a bunch of unit tests of its own, and see if those check out. If not, this should be reported to poppler (though I don't know how much effort they want to put into supporting big endian).

Anyway, closing it here for now as I don't think there's anything we can do on the TeXworks side of things.