feat(preview): introducing new class ImaginaryPDF #46508
Conversation
ernolf
force-pushed
the
ernolf/enh/imaginary-pdf-handling
branch
from
385aee8
to
c3e3738
Compare
ernolf
requested review from
ChristophWurst,
miaulalala and
nickvergessen
as code owners
|
The rebase went bad. It seems unrelated commits have been pulled into this branch |
ernolf
force-pushed
the
ernolf/enh/imaginary-pdf-handling
branch
from
76ddcd0
to
5565d69
Compare
Yes. Fixed. Sorry for the noise. |
ernolf
force-pushed
the
ernolf/enh/imaginary-pdf-handling
branch
3 times, most recently
from
b90c6e8
to
a41ed80
Compare
|
Please revert all changes to the autoloaders in |
| @@ -40,7 +40,7 @@ public function getMimeType(): string { | |||
| } | |||
|
|
|||
| public static function supportedMimeTypes(): string { | |||
| return '/(image\/(bmp|x-bitmap|png|jpeg|gif|heic|heif|svg\+xml|tiff|webp)|application\/(pdf|illustrator))/'; | |||
| return '/(image\/(bmp|x-bitmap|png|jpeg|gif|heic|heif|svg\+xml|tiff|webp)|application\/illustrator)/'; | |||
There was a problem hiding this comment.
| return '/(image\/(bmp|x-bitmap|png|jpeg|gif|heic|heif|svg\+xml|tiff|webp)|application\/illustrator)/'; | |
| return '/(image\/(bmp|x-bitmap|png|jpeg|gif|heic|heif|svg\+xml|tiff|webp)/'; |
|
|
||
| class ImaginaryPDF extends Imaginary { | ||
| public static function supportedMimeTypes(): string { | ||
| return '/application\/pdf/'; |
There was a problem hiding this comment.
| return '/application\/pdf/'; | |
| return '/application\/(illustrator|pdf)/'; |
Did you read #46447 (comment) I wouldn't classify Illustrator files as PDF files, they are more like (non text-)postscript files, which are of course all very closely related. In the narrowest sense, they are vector-based graphics. What convinced me not to include them in PDF is that they have the file extension .ai and not .pdf and therefore are not assigned a unique icon in Nextcloud like is the case with PDF. My aim was to clearly devide pure PDF documents - they have a good Icon which is way better than any preview thumb - from other, not (pure PDF) documents. |
No I havent.
Fine by me then 👍 |
Signed-off-by: ernolf <raphael.gradenwitz@googlemail.com> Signed-off-by: Daniel Kesselberg <mail@danielkesselberg.de>
kesselb
force-pushed
the
ernolf/enh/imaginary-pdf-handling
branch
from
9f48093
to
a8bdd4f
Compare
|
Thank you! I rebased your pr, updated the autoloaders again and squashed the commits. |
|
Thanks for your first pull request and welcome to the community! Feel free to keep them coming! If you are looking for issues to tackle then have a look at this selection: https://github.com/nextcloud/server/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 |
kesselb
added
the
pending documentation
kesselb
removed
the
pending documentation
|
Hello there, We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process. Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6 Thank you for contributing to Nextcloud and we hope to hear from you soon! (If you believe you should not receive this message, you can add yourself to the blocklist.) |
Resolves: Add Option to Disable Imaginary PDF Previews #42175
Replaces: feat., Imaginary: disable document processing by default #46447
Summary
Document previews often appear as minimal, almost blank "miniatures" that can inadvertently reveal content, which may not always be desired.
Many users prefer having document icons instead of these previews.
The classic preview provider settings have considered this preference.
feat: Add separate provider for Imaginary PDF handling
This allows for more granular control over which mimetypes are processed by Imaginary.
The approach from #46447 was too cumbersome and deviated too much from the uniform handling of preview providers. This approach has now fully implemented the suggestions and ideas from there.
TODO
Checklist