ANN: Firefox (version 19) now has an internal PDF renderer
- Chrome and Firefox both render PDF internally now.
Firefox is using PDF.js http://mozilla.github.com/pdf.js/
I posted about this last year and it finally made it into production. I am quite impressed with how fast it is.
Now we just need XSLFO.js :)
- That's very cool. I had turned off PDF association in FF because I had
locked down all the Adobe browser stuff. Nice to finally have PDF viewing
back in that browser.
Coupled with an FO engine or a PDF-generating tool like Apache PDFBox or
even ImageMagick, can make some fun stuff at little more reliable to
On 2/19/13 5:20 PM, "matt_kaatman" <mkaatman@...> wrote:
> Chrome and Firefox both render PDF internally now.
> Firefox is using PDF.js http://mozilla.github.com/pdf.js/
> I posted about this last year and it finally made it into production. I am
> quite impressed with how fast it is.
> Now we just need XSLFO.js :)
> Yahoo! Groups Links
Senior Solutions Architect, RSI Content Solutions
"Bringing Strategy, Content, and Technology Together"
Book: DITA For Practitioners, from XML Press,
- Actually for several years now RenderX has supported SVG output and XHTML output of the composed page, so I don't quite see the point. You can use RenderX and output SVG as pages in a collection or as XHTML in a collection or a single stream ... and they look exactly like the printed page (assuming as this JS code does that you have the proper fonts around when you do it).
A PDF contains the post-composed set of objects and their placements. The hard work (composition of the actual lines, pages, layout ... with all associated rules) has already taken place. Not to make light of PDF.js, it is great ... but it is not hard, really. A PDF doesn't say inside it anything about a block of text and "OK you decide how to put it down and where to end the lines based on the rules of the document." A PDF says inside it, "Place these letters at this location, and these at those, and these at those ..." and frankly that could be three commands for one kerned word. That is all it is.
It is not even close.
- I think part of the point is that Acrobat reader (and most other plugins) are a lot more prone to security issues such as buffer exploits. In addition, it hasn't always been available on every platform. I tried the firefox example in IE9 and it was a bit slower but it worked. (I suspect it would work in Safari as well.) This gives new users an out of the box PDF reader solution the moment they turn on their new PC/Laptop/Tablet/other device with a js engine.
Also, redistribution of firefox is a lot simpler than acrobat reader. We're starting to put the manuals on our touchscreen enabled medical devices. An FDA requirement is to prove that our customers have the capability to read the manuals. This makes things that much simpler.
--- In firstname.lastname@example.org, kevin@... wrote:
> Actually for several years now RenderX has supported SVG output and XHTML output of the composed page, so I don't quite see the point. You can use RenderX and output SVG as pages in a collection or as XHTML in a collection or a single stream ... and they look exactly like the printed page (assuming as this JS code does that you have the proper fonts around when you do it).