Make geometric transforms consistent with PDF specification#51
Make geometric transforms consistent with PDF specification#51BobLd merged 3 commits intoBobLd:0.1.12-skia3from
Conversation
| _canvas.Concat(textMatrix.ToSkMatrix()); | ||
| _canvas.Concat(renderingMatrix.ToSkMatrix()); | ||
| _canvas.Scale(1, -1, 0, 0); |
There was a problem hiding this comment.
API specs on DrawShapedText are pretty scarce. No ideas why text must be flipped along Y axis.
| if (_updateCurrentStreamOriginalTransform) | ||
| { | ||
| // Update the original transform for form XObject | ||
| _currentStreamOriginalTransforms.Push(CurrentTransformationMatrix.ToSkMatrix()); | ||
|
|
||
| _updateCurrentStreamOriginalTransform = false; | ||
| } | ||
| } | ||
|
|
||
| // Note that recursive calls are possible here for nested form XObjects | ||
| protected override void ProcessFormXObject(StreamToken formStream, NameToken xObjectName) | ||
| { | ||
| // Indicate that we want to update the original transform for form XObject | ||
| _updateCurrentStreamOriginalTransform = true; | ||
|
|
||
| base.ProcessFormXObject(formStream, xObjectName); | ||
|
|
||
| // Restore previous original transform | ||
| _currentStreamOriginalTransforms.Pop(); | ||
| } | ||
|
|
||
| private bool _updateCurrentStreamOriginalTransform; |
There was a problem hiding this comment.
I wish there would be better handling of transformation change done in base ProcessFormXObject method. But couldn't come up with concise solution.
There was a problem hiding this comment.
@PsykerUdot I had a look and could not find the reason why this is needed, maybe the problem is in PdfPig, but is not visible as it seems to mainly impact shadings.
If you have a way to create a test document relying on letters (similar to the shader based test documents you added), that would help debug in PdfPig (PdfPig does not render shadings, but if we can check the letters bounding box are properly aligned, that'd be a start)
There was a problem hiding this comment.
@BobLd It is definitely not a problem of PdfPig. The code is dedicated solely to enable correct pattern coordinates mapping.
My concern is that piece of code is somewhat hacky. I thought originally to collect original transformations stack in PdfPig, but unless PdfPig processes patterns in any way it seems impractical.
It is also possible to make ProcessOperations method virtual so derived classes can handle the case in their own implementations.
|
@PsykerUdot thanks a lot for this great contribution. I'll review it shortly |
|
@PsykerUdot I have updated branch |
|
@BobLd Excellent! Switched the PR to |
|
@PsykerUdot rthanks again for the hard work here - much appreciated! I ran the One tests shows a regression though:
This is the expected image (zoomed in on the problem): And the actual image generated from your branch (issues circled in red): Some icons have disappeared... Can you have a look? I need to add documentation on these tests but this is the high level on how they work:
This is what the diff shows for this tests, showing the missing icons: I hope this helps for debugging - reviewing your code changes (another failing test that might show an error - really not sure - is EDIT: It seems like your version of PDFBOX-1869-4_1_1 is correct, the previous was wrong |
|
@BobLd I'll take a look. Thank you for your feedback and clarification on how to read test results! |
|
@BobLd I checked it carefully and afraid a regression was introduced with UglyToad/PdfPig@e11dc6b. |
|
@PsykerUdot thanks a lot for investigating! This was a bug in PdfPIg indeed - will fix shortly |
* consistent geometric transformations; fixes * include new test samples in Tests project



This pull request refactors the Skia rendering pipeline to meet PDF specifications and make coordinate transformations fully affine, so not only point coordinates are transformed but the whole shape.
Changes involve simplifying transformation logic and standardizing coordinate usage.
These changes require also changes in UglyToad/PdfPig: UglyToad/PdfPig#1198
Rendering pipeline simplification and fixes:
SKRect,SKPoint, path drawing).Test coverage additions:
Notes
Test case PDFBOX-1869-4 shows some differences to expected image. That is because Type1 (Function-based) Shading implementation had flaws in terms of coordinate transformations.
During development I targeted SkiaSharp 3.119.1, as version 2.88.* seems completely outdated.