Bug 65076 – WebKit2: Printing to PDF loses URL links

• Component: PDF
• Status: RESOLVED FIXED

Prior to Safari 5.1 printing into a PDF kept all links intact - great for archiving scientific articles.

After upgrading to Safari 5.1 (both on Lion and Snow Leopard) those links are gone, breaking my workflow because it need to keep the URLs.

From a user perspective it seems that it is an old bug reappearing:

     https://bugs.webkit.org/show_bug.cgi?id=10216

Can be reproduced on Mac OS X 10.6.8 and 10.7:
- open any web page containing links
- print to pdf using pdf services
- open pdf in Preview.app

[Alexey Proskuryakov]

<rdar://problem/9831050>

Created attachment 103742 [details]
Printed PDF from r83010

Created attachment 103743 [details]
Printed PDF from r83080

Traced the issue a bit further:

Nightly build r83010: prints as expected
Nightly build r83080 fails

Open the attached PDF files in Preview.app and hover over the embedded links.

Both files were printed from highly builds r83010 / r83080 using the specified URL from above:

http://www.wikipedia.de

[Tom Andersen]

There is lots of grief about this bug on the web. 

It looks to me like the culprit may have something to do with https://bugs.webkit.org/show_bug.cgi?id=57916 and the m_alwaysCreateLineBoxes variable.

Perhaps the optimization should be off when printing. 

RenderInline::RenderInline(Node* node)
     : RenderBoxModelObject(node)
     , m_lineHeight(-1)
+    , m_alwaysCreateLineBoxes

Might give someone a clue for an easy fix.

from not a webkit developer.

[collegeitdept]

Will this very annoying and disruptive bug ever get fixed?

It still hasn't been assigned to anyone.

Please fix this bug.

[collegeitdept]

This bug is still present and has NOT been fixed in the recent Safari update 5.1.1.

Does someone have an update for an ETA??

Thanks.

[Alexey Proskuryakov]

*** Bug 71573 has been marked as a duplicate of this bug. ***

[Tobias]

This affects not only Safari but lots of Mac software used to archive web sites.

(In reply to comment #1)
> <rdar://problem/9831050>

If this were on http://openradar.appspot.com we could all watch it ;)

[Boris Raicheff]

Will someone kindly look at this issue already?  It was reported more than 5 MONTHS ago and is still unassigned!

The functionality is critical for online research activities and this defect is extremely annoying!

[Mark Rowe (bdash)]

Created attachment 121534 [details]
Patch v1

[Mark Rowe (bdash)]

(In reply to comment #9)
> This affects not only Safari but lots of Mac software used to archive web sites.

This bug is actually specific to Safari. If you're seeing a problem with another application then this bug is not it.

[Alexey Proskuryakov]

Comment on attachment 121534 [details]
Patch v1

View in context: https://bugs.webkit.org/attachment.cgi?id=121534&action=review

r=me assuming you tested multi-page PDFs.

> Source/WebKit2/UIProcess/API/mac/WKPrintingView.mm:509
> +    RetainPtr<NSData> pdfData(AdoptNS, [[NSData alloc] initWithBytes:pdfDataBytes.data() length:pdfDataBytes.size()]);

It's a little sad that we now copy the data.

> Source/WebKit2/UIProcess/API/mac/WKPrintingView.mm:533
> +        RetainPtr<NSData> pdfData(AdoptNS, [[NSData alloc] initWithBytes:_printedPagesData.data() length:_printedPagesData.size()]);

Ditto.

[Mark Rowe (bdash)]

(In reply to comment #13)
> (From update of attachment 121534 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=121534&action=review
> 
> r=me assuming you tested multi-page PDFs.

Printing multipage documents works as well as printing single-page documents. 

> > Source/WebKit2/UIProcess/API/mac/WKPrintingView.mm:509
> > +    RetainPtr<NSData> pdfData(AdoptNS, [[NSData alloc] initWithBytes:pdfDataBytes.data() length:pdfDataBytes.size()]);
> 
> It's a little sad that we now copy the data.
> 
> > Source/WebKit2/UIProcess/API/mac/WKPrintingView.mm:533
> > +        RetainPtr<NSData> pdfData(AdoptNS, [[NSData alloc] initWithBytes:_printedPagesData.data() length:_printedPagesData.size()]);
> 
> Ditto.

It should be possible to avoid copying the data, but it would require a bit of reworking our assumptions about the state of _printedPagesData at various places throughout the class.  I'll file a follow-up about it.

[Mark Rowe (bdash)]

(In reply to comment #12)
> (In reply to comment #9)
> > This affects not only Safari but lots of Mac software used to archive web sites.
> 
> This bug is actually specific to Safari. If you're seeing a problem with another application then this bug is not it.

What you're describing may be bug 75768.

[Mark Rowe (bdash)]

Fixed in r104377.

[Mark Rowe (bdash)]

(In reply to comment #14)
> It should be possible to avoid copying the data, but it would require a bit of reworking our assumptions about the state of _printedPagesData at various places throughout the class.  I'll file a follow-up about it.

Bug 75770.

[Tobias]

(In reply to comment #12)

> This bug is actually specific to Safari.

It's in all applications that use /System/Library/Frameworks/WebKit.framework for instance http://c-command.com/eaglefiler/

Google Chrome also doesn't "print" clickable links, but I don't know if it ever did.

On Snow Leopard the r104378 nightly only ever prints blank pages, so I can't confirm that this is fixed.

[Boris Raicheff]

> On Snow Leopard the r104378 nightly only ever prints blank pages, so I can't confirm that this is fixed.

I just tested r104378 (SL 10.6.8) and can confirm that printing to PDF now retains the links, so it seems to work perfectly.

Thanks a million!

I just tested r104398 and it works !

Thanks to Mark to take care of it !!

r105048 on Lion 10.7.2 restores functionality of hyperlinks in "Save to PDF" -- however, the color of the hyperlink on the HTML page was not carried over to the PDF, so there's no visual indication that there is a hyperlink (at least in OS X Preview).

See "ScreenShot_2012-01-16" (PDF views in Preview on the left; WebKit on the right)

Created attachment 122677 [details]
PDF in Preview.app on left; WebKit on right

[Mark Rowe (bdash)]

That's a completely separate issue.  Please file a new bug report about it.

Sorry -- opened bug #76406

(In reply to comment #23)
> That's a completely separate issue.  Please file a new bug report about it.

[collegeitdept]

Actually one URL link is not preserved (and is now broken... it used to work before the patch)... The footer URL of the originating webpage no longer works.  It used to be generated as a link now it is not.

[collegeitdept]

Other than this one last issue... Thank you for your help fixing this issue!

[Mark Rowe (bdash)]

Please file a new bug with specific steps to reproduce that problem.

[Michael Tsai]

I see this is resolved as fixed, however I just observed the problem (printing to PDF does not preserve clickable links) in Safari 5.1.3 on Mac OS X 10.7.3, both with Safari itself and with my WebKit-using app (EagleFiler).

[Mark Rowe (bdash)]

That's expected. Safari 5.1.3 does not contain the fix.

[collegeitdept]

Do we know when this fix will appear in an official Safari release from Apple?  I was really looking forward to the update for the potential fix to this disruptive bug.

Until then I have to continue to use Firefox with its Adobe Create PDF extension.

[Mark Rowe (bdash)]

Topics such as Apple's release schedule are outside of the scope of this bug.

[Tom Andersen]

It looks like Safari 5.1.4 has been released for testing (as seen on the web http://www.google.ca/search?q=Safari+5.1.4 ) with suggestions to test print to PDF, etc - so it looks like that is the Mac version with the fix.

Mark,

I tried  Safari 5.1.4 and indeed it works (just like with the WebKit builds) so thanks for your effort.

But something is still strange: I use NewNewsWire as RSS reader. After updating Safari it still has the bug. I tried Vienna, same. I tried OmniBrowser and RapidWeaver - both work. Strange...

There might be a second place where your code changes need to be applied. Could you check again ?

Thanks,
Karsten

[Mark Rowe (bdash)]

Safari 5.1.4 did not update the system version of WebKit when installed on Lion. The fact that this still reproduces in third-party applications is currently expected, and will be resolved when the system version of WebKit is updated.

Just a final update:

With the recent Mac OS X 10.7.4 / Safari 5.1.7 update WebKit got fixed, too.
So apps like NetNewsWire, Vienna and others, which use WebKit to display 
HTML pages are fixed now.

Thanks again,
Karsten