-
Notifications
You must be signed in to change notification settings - Fork 3.3k
LibPDF: Add "slow path" for text rendering that can handle transforms #26292
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
base: master
Are you sure you want to change the base?
Conversation
While working on SerenityOS#26292, I noticed that while fills/strokes can be Gfx::PaintStyles in LibPDF, currently they never are, which confused me. It turns out that a few years ago, tiled patterns were implemented in PR SerenityOS#22197, but were partially reverted due to crashes in SerenityOS#22364, leaving around a partial implementation. It appears the author was going to look into the crashes, but never got around to it. So, this patch resolves all the crashes on `0000.zip`, mainly by checking types and not assuming dictionary keys exist. Summary of `./Meta/test_pdf.py ~/Downloads/0000`: ``` Stacks: 0 crashes (0.0%) 0 distinct crash stacks 7 failed to open (0.7%) /home/macdue/Downloads/0000/0000346.pdf /home/macdue/Downloads/0000/0000202.pdf /home/macdue/Downloads/0000/0000399.pdf /home/macdue/Downloads/0000/0000421.pdf /home/macdue/Downloads/0000/0000480.pdf /home/macdue/Downloads/0000/0000920.pdf /home/macdue/Downloads/0000/0000819.pdf 3 files with password (0.3%) 909 files without issues (90.9%) ```
This reverts commit 6032c06. This relands the original commit with fixups to make `PatternColorSpace` more robust to unexpected inputs. While working on SerenityOS#26292, I noticed that while fills/strokes can be Gfx::PaintStyles in LibPDF, currently they never are, which confused me. It turns out that a few years ago, tiled patterns were implemented in PR SerenityOS#22197, but were partially reverted due to crashes in SerenityOS#22364, leaving around a partial implementation. It appears the author was going to look into the crashes, but never got around to it. So, this patch resolves all the crashes on `0000.zip`, mainly by checking types and not assuming dictionary keys exist. Summary of `./Meta/test_pdf.py ~/Downloads/0000`: ``` Stacks: 0 crashes (0.0%) 0 distinct crash stacks 7 failed to open (0.7%) /home/macdue/Downloads/0000/0000346.pdf /home/macdue/Downloads/0000/0000202.pdf /home/macdue/Downloads/0000/0000399.pdf /home/macdue/Downloads/0000/0000421.pdf /home/macdue/Downloads/0000/0000480.pdf /home/macdue/Downloads/0000/0000920.pdf /home/macdue/Downloads/0000/0000819.pdf 3 files with password (0.3%) 909 files without issues (90.9%) ``` Co-authored-by: MacDue <[email protected]>
This reverts commit 6032c06. This relands the original commit with fixups to make `PatternColorSpace` more robust to unexpected inputs. While working on #26292, I noticed that while fills/strokes can be Gfx::PaintStyles in LibPDF, currently they never are, which confused me. It turns out that a few years ago, tiled patterns were implemented in PR #22197, but were partially reverted due to crashes in #22364, leaving around a partial implementation. It appears the author was going to look into the crashes, but never got around to it. So, this patch resolves all the crashes on `0000.zip`, mainly by checking types and not assuming dictionary keys exist. Summary of `./Meta/test_pdf.py ~/Downloads/0000`: ``` Stacks: 0 crashes (0.0%) 0 distinct crash stacks 7 failed to open (0.7%) /home/macdue/Downloads/0000/0000346.pdf /home/macdue/Downloads/0000/0000202.pdf /home/macdue/Downloads/0000/0000399.pdf /home/macdue/Downloads/0000/0000421.pdf /home/macdue/Downloads/0000/0000480.pdf /home/macdue/Downloads/0000/0000920.pdf /home/macdue/Downloads/0000/0000819.pdf 3 files with password (0.3%) 909 files without issues (90.9%) ``` Co-authored-by: MacDue <[email protected]>
This will make reusing the logic to determine glyph IDs easier. No behaviour change intended.
This adds a slow path for drawing text (that is not simply scaled or translated), which works by creating a Gfx::Path for the text, applying the transform, then filling it. This supports arbitrary (affine) transforms. Currently, the APIs needed to support this are only implemented for TrueType fonts. It should be possible to extend to other (non-bitmap) fonts too, but since not all PDF fonts are built on top of the existing Gfx::Font classes, it requires more work to implement.
Seems a little neater. This excludes Type0Fonts for now, but it looks like not much of the implementation would be shared. No behaviour change intended.
|
Any thoughts on this one? |
|
I think it's great, I'm super excited about it, and I want to make some time to take a real look. I have some notes on this feature somewhere I'd like to re-read, etc. Hopefully this week! |
|
Okay, no worries, no rush 😄 |
|
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions! |


See commits for details:
Progression


rotated.pdf:Before:
After: