91559 - [RFE] Use native PDF rendering instead of plug-in on Mac OS X

Status: RESOLVED WONTFIX

(Core :: Layout, enhancement, P3)

Description

[Terence Tan]

Mac OS X uses Display Postscript to draw things to screen, and as such can 
natively display PDF documents. This ability is built into the graphics 
subsystem (Quartz) on Mac OS X.

We should leverage this ability and show PDF documents internally, without 
needing to use a plug-in (of course, a plug-in could be configured to override 
this).

Also refer to bug 74245, which refers to Quartz font rendering.

-----

Because of our current build architecture (using the old QuickDraw methods 
under Carbon CFM?), we probably can't do this yet. But I'd like to register 
this idea somewhere... someone please target this to Future :-)

Comment 1

[Ashley Bischoff (blog at handcoding.com)]

No dupes found. Confirming, and adding "acrobat" keyword.

Reporter: For future reference, please include your build number in bug reports.

Comment 2

[Henri Sivonen (:hsivonen)]

Potential problems for the record:
* Quartz doesn't support PDF 1.4.
* Quartz fails to render text in numerous PDF files produced with Distiller 
  and GhostScript.* Quartz provides no document navigation support.

Comment 3

[Adam]

I don't think this will ever be feasible. Quartz only provides a rudimentary
subset of PDF features, not enough to be suitable for displaying most PDF documents.

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->nobody, because I really don't know who would implement this.

Comment 5

[Terence Tan]

The idea isn't to provide whiz-bang support for latest version PDF documents; if 
the user wants that, they can install Acrobat Reader and its plug-in and Mozilla 
should use that instead.

The idea is to provide some fall-back for PDF support, because most people won't 
have Acrobat Reader installed (although I may be mistaken on that). They'd 
otherwise end up opening the document in Preview, which presumably has the same 
limitations.

Oh, another potential problem is printing the document, since PDF documents have 
their own pagination scheme.

This bug may be trivial and not worth implementing, but I thought I'd put it on 
file anyway in case someone decides they like it :-)

Comment 6

[Mike Pinkerton (not reading bugmail)]

let adobe write the plugin. that's not our job.

Comment 7

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Adobe wouldn't write a plugin for basic PDF support.  They'd write a full
acrobat plug-in with all its overhead.  This request was for basic PDF support
(like ps2pdf or OSX might make), which, if the Carbon<->Cocoa stuff winds up
working properly (bug 74245) should be rather straightforward.  Of course it'd
be an OSX-only feature so a third-party should probably pick this up as a
project.  I don't see anything philosophically wrong with Mozilla rendering PDF
though (This doesn't mean I don't see anything philosophically wrong with Adobe
- this might need to be marked 'RESOLVED WONTGOTOJAIL'). 

Comment 8

[Mike Pinkerton (not reading bugmail)]

the whole reason for plugins was so mozilla didn't have to implement the entire 
kitchen sink. we can barely get html right, now you want us to tackle pdf too? ;) 
;) :)

Comment 9

[Chris Lawson (gone)]

Reopening per pink on IRC. We'll figure out a way to do this somehow, be it with PDFKit (10.4+) or otherwise.

Comment 10

[Håkan Waara]

This would be easy to do 10.4-only and Camino-only.  Do we want to do it in Core too? Do we want it for Xlib and GTK1? :-)

Comment 11

[Samuel Sidler (old account; do not CC)]

(In reply to comment #10)
> This would be easy to do 10.4-only and Camino-only.  Do we want to do it in
> Core too? Do we want it for Xlib and GTK1? :-)
> 

Since this is a Mac-only bug, doing it in Core would require doing it in a way Gecko could use it, regardless of it being Camino or Firefox or SeaMonkey.

Comment 12

[Jesse Ruderman]

Safari does this really well.  I can even use the normal browser shortcuts for changing the font size while viewing a PDF in Safari.

Comment 13

[Chris Lawson (gone)]

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

Comment 15

[Marc Bejarano]

see also bug 344620

Comment 19

[Marc Bejarano]

hallelujah!

while we wait for somebody to find time / motivation to do this in core directly, users can at least get goodness with fx3 via plug-in, now:
http://firefox-mac-pdf.googlecode.com

woop!

Comment 20

[Mike Schroepfer]

We'd like this for 1.9.1 -->vlad unless he can find a better owner.

Comment 22

[Shawn Wilsher :sdwilsh]

Attachment: proper approach discussion

I talked to bz and vlad about this recently.  I won't have cycles for this, but this will help whoever wants to do this.

Comment 24

[Chris Lawson (gone)]

(In reply to comment #19)
> hallelujah!
> 
> while we wait for somebody to find time / motivation to do this in core
> directly, users can at least get goodness with fx3 via plug-in, now:
> http://firefox-mac-pdf.googlecode.com

Has anyone approached the developer of that plugin about putting his efforts toward fixing this bug? I suspect most of the work is already done and the only thing he'd need to do at this point is to integrate the code he's got with native Gecko (rather than the NPAPI code).

Comment 25

[Shawn Wilsher :sdwilsh]

(In reply to comment #24)
> Has anyone approached the developer of that plugin about putting his efforts
> toward fixing this bug? I suspect most of the work is already done and the only
> thing he'd need to do at this point is to integrate the code he's got with
> native Gecko (rather than the NPAPI code).
Per comment 22, we do not want a plugin for this, but want to do it with a native frame.

Comment 26

[Chris Lawson (gone)]

(In reply to comment #25)
> Per comment 22, we do not want a plugin for this, but want to do it with a
> native frame.

Right, that's my point. Presumably the plugin code would be a good head start toward doing this natively.

Comment 29

[Boris Zbarsky [:bzbarsky]]

Just one note.  If we do this, there really needs to be a way to disable this on the user's part and just use Preview instead.

Comment 30

[Michael]

I second that.  Viewing PDFs in the browser is really bad in many cases, because the proportions of the PDF do not match the proportions of the browser window.  For example, if you view a technical paper as a PDF, you need a window of a very different size and shape than is appropriate for a browser window, in order to be able to view the paper legibly.  (Download almost any paper from Google Scholar to see what I mean.)  Plus, those of us who use PDFs heavily (such as those doing technical research) don't just want to view a PDF once - we need to be able to save and manipulate the PDF, and we depend on some of the advanced features in external PDF viewers.  Preview is excellent on the Mac for this.  If there were no way to skip a built in browser PDF viewer, I would have to switch to a different browser - it would just disrupt my work too much otherwise.

Comment 31

[Terence Tan]

Cross-referencing this bug to https://wiki.mozilla.org/PDF.js - a PDF renderer in pure HTML5+JavaScript (very cool). A possible way forward?

Comment 32

[Josh Aas]

This is almost certainly not going to happen at this point. If we integrate PDF viewing we'll do it with non-native code (e.g. PDF.js). Marking WONTFIX.