Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add pdf thumbnail support (port #378) #543

Merged
merged 9 commits into from
Oct 14, 2024
Merged

feat: add pdf thumbnail support (port #378) #543

merged 9 commits into from
Oct 14, 2024

Conversation

CyanVoxel
Copy link
Member

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.

@CyanVoxel CyanVoxel added Type: Enhancement New feature or request Type: UI/UX User interface and/or user experience Priority: Low Doesn't require immediate attention Status: Review Needed A review of this is needed labels Oct 11, 2024
@CyanVoxel CyanVoxel added this to the Alpha v9.5 (Post-SQL) milestone Oct 11, 2024
def replace_transparent_pixels(
img: Image.Image, color: tuple[int, int, int, int] = (255, 255, 255, 255)
) -> Image.Image:
"""Replaces (copying/without mutating) all transparent pixels in an image with the color.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"""Replaces (copying/without mutating) all transparent pixels in an image with the color.
"""Replace (copying/without mutating) all transparent pixels in an image with the color.

"""Render a thumbnail for a PDF file.

filepath (Path): The path of the file.
size (tuple[int,int]): The size of the icon.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this type doesnt match the parameter (int)

@@ -786,6 +798,52 @@ def _model_stl_thumb(self, filepath: Path, size: int) -> Image.Image:

return im

def _pdf_thumb(self, filepath: Path, size: int) -> Image.Image:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would be nice to have a test for this. Rather than explaining what and how, I made the test, so feel free to cherry-pick/merge it into the branch. But it looks like the final png isnt really transparent 🤔

b1bae1f

@CyanVoxel
Copy link
Member Author

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.

@yedpodtrzitko
Copy link
Collaborator

yedpodtrzitko commented Oct 13, 2024

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.

@CyanVoxel
Copy link
Member Author

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
image

@CyanVoxel
Copy link
Member Author

Changed the test to a black square, seems to be working both on my Windows machine and inside the workflow

@CyanVoxel CyanVoxel merged commit 3d7629b into main Oct 14, 2024
10 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Low Doesn't require immediate attention Status: Review Needed A review of this is needed Type: Enhancement New feature or request Type: UI/UX User interface and/or user experience
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

2 participants