Bug 110925

Summary: PDFPlugin: PDF orientation isn't respected when printing or print-previewing
Product: WebKit Reporter: Tim Horton <thorton>
Component: PDFAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: ap
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
print ap: review+

Tim Horton
Reported 2013-02-26 16:49:31 PST
<rdar://problem/13008621>
Attachments
print (1.62 KB, patch)
2013-02-26 17:32 PST, Tim Horton 		ap: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Tim Horton
Comment 1 2013-02-26 17:32:07 PST
Created attachment 190400 [details] print
Tim Horton
Comment 2 2013-02-26 17:32:07 PST
Created attachment 190401
Alexey Proskuryakov
Comment 3 2013-02-26 19:16:06 PST
Comment on attachment 190400 [details] print View in context: https://bugs.webkit.org/attachment.cgi?id=190400&action=review > Source/WebKit2/WebProcess/WebPage/mac/WebPageMac.mm:812 > + NSInteger rotation = [pdfPage rotation]; > + if (rotation == 90 || rotation == 270) > + std::swap(cropBox.size.width, cropBox.size.height); Please add a comment about why this is the right thing to do (which is because we always autorotate). When we looked at this code previously, we both agreed that it was wrong, so it's not at all obvious what's going on.
Tim Horton
Comment 4 2013-02-28 11:19:08 PST
http://trac.webkit.org/changeset/144333
Note You need to log in before you can comment on or make changes to this bug.