1272274 - Pattern is not printed if patternTransform attribute is set to rotate(180)

Status: NEW

(Core :: Printing: Output, defect)

Description

[Tung]

Attachment: index.html

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/50.0.2661.94 Safari/537.36

Steps to reproduce:

- Draw a <path stroke-width="3" d="M 5480,-2782 L 5480,-3102 L 5800,-3102 L 5800,-2782 L 5480,-2782" h="2DD6" stroke="transparent" fill="url(#XHatch_GROUP_17)" hatch-key="_GROUP_10140" spacing="9"></path>

- Define a pattern 

<pattern id="XHatch_GROUP_17" patternUnits="userSpaceOnUse" width="26.6313" height="26.631" x="0" y="0" viewBox="0 0 26.631388 26.6313" add_by="dynamic" hatch-key="_GROUP_10140" patternTransform="rotate(180)">
            <line x1="0" y1="0" x2="26.63138784316648" y2="0" stroke-width="12.366597493489584" stroke="rgb(0,0,255)"></line>
        </pattern>
- Fill the pattern to the path
- Press Ctrl + P to print the page to paper or any files 
- Attach file Example(index.html)


Actual results:

Pattern is not printed in the paper or files. If change rotate to 181 degree it works


Expected results:

My expectation is the pattern should be printed

Comment 1

[Loic]

Regression range:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9d66436af432&tochange=7c24470b6b3a

Surely a patch about Moz2D GeneralPattern.

Comment 2

[Alice0775 White]

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=467d08aeefd0&tochange=3e31ac0e3997

Comment 3

[Alice0775 White]

Via local build
Last Good: 5805c4e57d56
First Bad: ece627b5e46a

Regressed by: Bug 1073964

Comment 4

[Jonathan Watt [:jwatt]]

The only substantive change that bug 1073964 made was to nsSVGPatternFrame.cpp, to create the DrawTarget  into which the pattern is drawn to be of the same type as the DrawTarget that the result is painted into instead of creating it using CreateOffscreenContentDrawTarget. I believe that when we print on Windows we print to a cairo backed DrawTarget. Despite this, prior to bug 1073964 landing we would still have used a D2D backed transient DrawTarget to paint the pattern during printing, but after it we would match the print DrawTarget and use a cairo backed DrawTarget. I'd guess there is a bug in the cairo backend that we are now exposing during printing.

Bas, does this sound plausible? Do you happen to know of such a bug already being filed?

Comment 5

[Bas Schouten (:bas.schouten)]

(In reply to Jonathan Watt [:jwatt] (Away Jun. 27 - Jul. 13) from comment #4)
> The only substantive change that bug 1073964 made was to
> nsSVGPatternFrame.cpp, to create the DrawTarget  into which the pattern is
> drawn to be of the same type as the DrawTarget that the result is painted
> into instead of creating it using CreateOffscreenContentDrawTarget. I
> believe that when we print on Windows we print to a cairo backed DrawTarget.
> Despite this, prior to bug 1073964 landing we would still have used a D2D
> backed transient DrawTarget to paint the pattern during printing, but after
> it we would match the print DrawTarget and use a cairo backed DrawTarget.
> I'd guess there is a bug in the cairo backend that we are now exposing
> during printing.
> 
> Bas, does this sound plausible? Do you happen to know of such a bug already
> being filed?

That does seem plausible. I fixed a Cairo transform bug a while back so I wonder if this may already be fixed on nightly?

Comment 6

[Loic]

I tested Nightly, it's not fixed.