Attach (recommended) or Link to PDF file here:

• dvisvgm-gh228.pdf
• dvisvgm-gh228-readable.pdf decompressed version created by mutool clean -ad dvisvgm-gh228.pdf dvisvgm-gh228-readable.pdf

Configuration:

• Web browser and its version: Chrome 110.0.5481.77
• Operating system and its version: macOS 12.6.2
• PDF.js version: 3.4.77 (the one used by https://mozilla.github.io/pdf.js/web/viewer.html)
• Is a browser extension: no

Steps to reproduce the problem:

1. Visit https://mozilla.github.io/pdf.js/web/viewer.html
2. Open dvisvgm-gh228(-readable).pdf

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

Background

The pdf is created by LaTeX using tikz package. dvisvgm-gh228.tex.zip

Specifically, the broken left pattern can be generated by the short LaTeX example below, shortened from mgieseki/dvisvgm#228:

\documentclass[margin=5pt]{standalone}
\usepackage{tikz}
\usetikzlibrary{patterns.meta}

\begin{document}
\begin{tikzpicture}[pattern color=blue]
  \draw[draw, pattern={Lines}] (0,0) rectangle (1,1);
\end{tikzpicture}
\end{document}

Analysis
The broken left pattern has

• /BBox [ -1.49442 -1.49442 1.49442 1.49442 ] and
• content stream q 0.3985 w -1.49442 0.0 m 1.49442 0.0 l S Q

while the right pattern has

• /BBox [ 0 0 2.98883 2.98883 ] and
• content stream q 0.3985 w 0.0 0.0 m 2.98883 0.0 l 0.0 2.98883 m 2.98883 2.98883 l S Q

In class TilingPattern, when the bounding box is shifted to ensure coordinates x0 and y0 non-negative, it seems some transformations like 1 0 0 1 -x0 0 and 1 0 0 1 -y0 0 should be additionally applied to the stream content. The corresponding code is added in a52c0c6. Actually its commit message already said that negative bounding boxes on tiling patterns is still broken:

These fixes broke #11473, but highlighted that we were drawing that correctly by
accident and not correctly handling negative bounding boxes on tiling patterns.

Current issue is different from the already fixed #11473:

• The example in Wrong rendering of pattern #11473 uses patterns provided by tikz library patterns, which have larger bounding box than X-/Y-steps. For tikz pattern crosshatch, it's /BBox [ -.99628 -.99628 3.9851 3.9851 ] /XStep 2.98883 /YStep 2.98883.
• The example in current issue uses (relatively newer and more powerful) pattern Lines provided by tikz library patterns.meta, which has the size of bounding box exactly the same as X-/Y-steps. For the broken left pattern, it's /BBox [ -1.49442 -1.49442 1.49442 1.49442 ] /XStep 2.98883 /YStep 2.98883, and for the right it's /BBox [ 0 0 2.98883 2.98883 ] /XStep 2.98883 /YStep 2.98883.

Also the specific stream content used in the attached example shows since the content will be clipped, shifting the bounding box may raise the need to manipulating the contents as well, which I guess could be non-trivial.