Created attachment 138621 [details] reproducer Rendering of tiling pattern which has pattern matrix moving pattern cell far away (e.g. /Matrix [ 0.96000 0 0 -0.96000 42.54000 245481.37900 ]) can fail on allocation of memory (e.g. in CairoOutputDev). I've prepared a patch which solves this issue by moving the pattern cell as close to (0,0) as possible by integer number of cells in pattern matrix before it is passed to tilingPatternFill(). Attached is page number 332 from a document where this can be reproduced (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/pdf/virtualization_deployment_and_administration_guide/Red_Hat_Enterprise_Linux-7-Virtualization_Deployment_and_Administration_Guide-en-US.pdf). Link to the original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1557355
Created attachment 138622 [details] [review] Fix tiling patterns when pattern cell is too far
Given that this works fine in the Splash and PS backends and only seems to fail on the Cairo backend, how hard is to get a fix that doesn't affect the other rendering pipelines?
Created attachment 138652 [details] [review] Fix tiling patterns when pattern cell is too far (In reply to Albert Astals Cid from comment #2) > Given that this works fine in the Splash and PS backends and only seems to > fail on the Cairo backend, how hard is to get a fix that doesn't affect the > other rendering pipelines? It was not that hard as I thought at the end (having already the patch for Gfx helped). Here is a patch which fixes the issue in Cairo backend directly. It solves the issue by modifying of cairo pattern matrix so that its offset is closer to the path filled by the pattern.
Hi, I would like to push the patch downstream but it changes quite complicated part. Could you have a look at it whether it looks correct? Thanks
I'm not sure if I understand how this works. Can you tell me if I've got this right? You're transforming the translation components of pmat by pmat^(-1) to find how far that point is in the pattern's coordinate system. You set xoffset and yoffset to the number of repetitions of the pattern that are required to get there. Then shift pattern_matrix over by that amount?
Hi, I'm sorry for late answer. (In reply to Jason Crain from comment #5) > I'm not sure if I understand how this works. Can you tell me if I've got > this right? I think that you've got this right :). > You're transforming the translation components of pmat by pmat^(-1) to find > how far that point is in the pattern's coordinate system. You set xoffset > and yoffset to the number of repetitions of the pattern that are required to > get there. Then shift pattern_matrix over by that amount? Yes, I have to shift the pattern_matrix so that when it is applied to the cairo context in "cairo_transform (cairo, &pattern_matrix)" we get closer to (0,0). Otherwise, cairo tries to allocate huge bitmap for the pattern. I've tested the patch also for different types of translations (scale, skew and rotation).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/190.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.