<html>
    <head>
      <base href="https://bugs.webkit.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - backface-visibility style not applied when printing"
   href="https://bugs.webkit.org/show_bug.cgi?id=160860#c2">Comment # 2</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - backface-visibility style not applied when printing"
   href="https://bugs.webkit.org/show_bug.cgi?id=160860">bug 160860</a>
              from <span class="vcard"><a class="email" href="mailto:nathan&#64;maxmo.net" title="Nathan Perkins &lt;nathan&#64;maxmo.net&gt;"> <span class="fn">Nathan Perkins</span></a>
</span></b>
        <pre>After finding this bug, I thought this might be an interesting introduction to the WebKit project and have done some digging and think I found the underlying issue. This is a  dauntingly complex open source project, far beyond what I have worked on in the past, but hopefully my investigations and findings will be of some use. I am happy to iterate on improving the solution or revising, or just handing it off to someone more experienced.

It appears that when printing (or when capturing a view as an image using Cocoa APIs on Mac), a separating painting code path is used. Normally, the 3D-transformed elements are rendered using a PlatformCALayer and backface-visibility is achieved through the PlatformCALayer::setDoubleSided method to hide elements when the backface is visible.

When printing, the 3D transform is achieved at paint time using the RenderLayer::paintLayerByApplyingTransform function, which does not take into account backface visibility.

I have added code to the beginning of that function that checks the backface visibility and uses the existing TransformationMatrix::isBackFaceVisible to abort painting if the backface is visible.

Given my limited knowledge of WebKit, I am not sure if aborting painting can lead to other problems, but in my test case and a few variations, it all produced the expected results.

I have not tried to create tests, as I am not sure how to force a 3D transformed element to be rendered using the alternative path described above. If anyone can provide some guidance on that, I am happy to take a stab at adding tests.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>