Pattern inside SVG not influenced by SVG offset inside PDF, unexpected point of origin

[DarSim2]

I have a SVG containing a pattern and a rect which is filled with said pattern:

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:svgjs="http://svgjs.dev/svgjs" width="200" height="200">
    <defs>
        <pattern x="0" y="0" width="20" height="20" patternUnits="userSpaceOnUse" id="SvgjsPattern1003">
            <rect width="10" height="10" fill="purple" x="0" y="0"></rect>
            <rect width="10" height="10" fill="pink" x="10" y="10"></rect>
        </pattern>
    </defs>
    <rect width="75" height="75" fill="url('#SvgjsPattern1003')"></rect>
</svg>

When I convert to PDF with a x and/or y offset then the pattern doesn't inherit the offset. It doesn't start at (0, 0) of the SVG inside the PDF but apparently the pattern starts at (0, 0) of the PDF.

const pdfDoc = new jsPDF({ orientation: 'l', unit: 'pt', format: 'a4' })
pdfDoc.svg(nested.node, {
                x: 17,
                y: 32,
            })
            .then(() => {
                pdfDoc.save('testStuffPDF')
            })

And when I print the PDF then the printer adds some margins of its own which offsets the pattern again so that the printed element filled with the pattern doesn't look the same as its counterpart on the screen.

I know that the pattern inside a SVG always starts at (0, 0) of the SVG itself.
This is the behavior I would also expect to be seen in the PDF. Pattern should start at the origin of the SVG inside the PDF not the origin of the PDF.

pattern_no_offset.pdf
pattern_with_offset.pdf

[HackbrettXXX]

Thanks for the bug report. I was able to reproduce it.

[DarSim2]

Hi, I just wanted to ask, if there is any development in this matter?

Because this became kind of a pressing matter for me, so I forked svg2pdf and tried to analyze the issue with a collegue.
We didn't manage to find a fix. Our current observations are the following, maybe this will help you:

1. BoundingBox in pattern.ts is calculated correctly (for the pattern element)
2. Our guess is that the rendered children of the pattern in their render() call do not take the offset of the pattern parent element into account

[yGuy]

Unfortunately, there was no progress, here, so far. We would have removed the "help wanted" tag if we were working on the task. HackbrettXXX is not available at the moment and won't be for the next couple of months, as far as I can tell. I am sorry to say, so we depend on the community to step in.

Is this a problem with the way we interpret the SVG or is this a problem with the way js2pdf writes the PDF? Have you been able to narrow down the issue?

What are the corresponding involved specs for the behavior?

[DanielBretzigheimer]

I have looked into the issue and I am trying to fix it. In my research, I have found some other issues:

1. using a unit other than pt will scale the pattern elements wrong
   In the following sample the red rectange has the same size as the blue rectangles in the svg (20 x 20). With unit 'pt' this works correct, but when changed to e.g. 'mm' they scale differently.
   SVG:
   
   PDF:
   

2. adding an offset to the pattern will result in differences between svg and pdf (see here)
   
   PDF:
   

I'll find these bugs and create a PR which hopefully resolves all these issues.

[DanielBretzigheimer]

After further investigation, we found a solution for the scaling problem in units besides pt. We had to apply the context.pdf.internal.scaleFactor to the TilingPattern and the child transform. This worked, but showed the next issue we couldn't solve.

The tiling pattern doesn't start at y = 0 and looks to be offset a little. We speculated that this could be from text baseline or something like that. If you have any idea how this could be fixed, please tell us. We will look further into the issue.

SVG:

PDF: