TagStudioDev
feat: add pdf thumbnail support (port #378)
This PR is a port of #378 which previously targeted thumbnails/Alpha-v9.4 to main (aka v9.5x).
This adds thumbnail/preview support for PDF files.
I noticed that on my machine (Windows 10) I had to regenerate the png preview to get the test to pass locally - it seems that for whatever reason, the text is aliased slightly differently when generating on my machine, resulting in a few different pixels that cause the test to fail.
We may need to go with a different line of testing for this, or introduce a margin of error. I'd like to get your thoughts on this.
I noticed that on my machine (Windows 10) I had to regenerate the png preview to get the test to pass locally - it seems that for whatever reason, the text is aliased slightly differently when generating on my machine, resulting in a few different pixels that cause the test to fail.
We may need to go with a different line of testing for this, or introduce a margin of error. I'd like to get your thoughts on this.
perhaps generating the image in a higher resolution (parameter size) could eliminate the discrepancies caused by different antialiasing. Or maybe having a PDF containing just a black square or some other simple shape (so no antialiasing) could do the trick.
Another option could be to make the values for render_options.setRenderFlags() somehow dynamic, so in tests there would be no antialiasing, thus no discrepancies.
I noticed that on my machine (Windows 10) I had to regenerate the png preview to get the test to pass locally - it seems that for whatever reason, the text is aliased slightly differently when generating on my machine, resulting in a few different pixels that cause the test to fail. We may need to go with a different line of testing for this, or introduce a margin of error. I'd like to get your thoughts on this.
perhaps generating the image in a higher resolution (parameter
size) could eliminate the discrepancies caused by different antialiasing. Or maybe having a PDF containing just a black square or some other simple shape (so no antialiasing) could do the trick.Another option could be to make the values for
render_options.setRenderFlags()somehow dynamic, so in tests there would be no antialiasing, thus no discrepancies.
Unfortunately it's not anti-aliasing causing the discrepancies, but rather the way the aliased text itself is rendered. The downscaling/anti-aliasing step comes later down the line.
Maybe the font is different from platform to platform, causing the discrepancies? That would at least be easier to work around than the idea of PIL just having slightly different rendering techniques between each platform. If it's indeed an issue with fonts specifically, then the black square approach shouldn't raise issues - same goes for the SVG previews.
Top: Windows, Second: macOS (presumably), Middle: Difference, Bottom: Overlay
Changed the test to a black square, seems to be working both on my Windows machine and inside the workflow