Bug 105905

Summary:	Blank page when tiling pattern's cell is too far
Product:	poppler	Reporter:	Marek Kasik <mkasik>
Component:	cairo backend	Assignee:	poppler-bugs <poppler-bugs>
Status:	RESOLVED MOVED	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:
Attachments:	reproducer Fix tiling patterns when pattern cell is too far Fix tiling patterns when pattern cell is too far

Description Marek Kasik 2018-04-05 14:21:22 UTC

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

Comment 1 Marek Kasik 2018-04-05 14:23:35 UTC

Created attachment 138622 [details] [review]
Fix tiling patterns when pattern cell is too far

Comment 2 Albert Astals Cid 2018-04-05 17:51:34 UTC

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?

Comment 3 Marek Kasik 2018-04-06 13:10:34 UTC

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.

Comment 4 Marek Kasik 2018-07-30 12:09:08 UTC

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

Comment 5 Jason Crain 2018-07-31 20:31:54 UTC

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?

Comment 6 Marek Kasik 2018-08-07 14:37:09 UTC

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).

Comment 7 GitLab Migration User 2018-08-20 22:05:53 UTC

-- 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.