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

NEW
Unassigned

Status

()

Core
Printing: Output
2 years ago
2 years ago

People

(Reporter: Tung, Unassigned)

Tracking

({regression, testcase})

35 Branch
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

1.10 KB, text/html
Details
(Reporter)

Description

2 years ago
Created attachment 8751681 [details]
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

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

Surely a patch about Moz2D GeneralPattern.
Status: UNCONFIRMED → NEW
Component: Untriaged → Printing: Output
Ever confirmed: true
Flags: needinfo?(jwatt)
Keywords: regression, testcase
Product: Firefox → Core
Version: 46 Branch → 35 Branch

Comment 2

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

Comment 3

2 years ago
Via local build
Last Good: 5805c4e57d56
First Bad: ece627b5e46a

Regressed by: Bug 1073964
Blocks: 1073964
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?
Flags: needinfo?(jwatt) → needinfo?(bas)
(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?
Flags: needinfo?(bas)

Comment 6

2 years ago
I tested Nightly, it's not fixed.
You need to log in before you can comment on or make changes to this bug.