Loading ...
Sorry, an error occurred while loading the content.

ANN: Firefox (version 19) now has an internal PDF renderer

Expand Messages
  • matt_kaatman
    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
    Message 1 of 4 , Feb 19, 2013
    • 0 Attachment
      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 :)
    • Eliot Kimber
      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
      Message 2 of 4 , Feb 19, 2013
      • 0 Attachment
        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
        deliver.

        Cheers,

        E.

        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
        >
        >
        >

        --
        Eliot Kimber
        Senior Solutions Architect, RSI Content Solutions
        "Bringing Strategy, Content, and Technology Together"
        Main: 512.554.9368
        www.rsicms.com
        www.rsuitecms.com
        Book: DITA For Practitioners, from XML Press,
        http://xmlpress.net/publications/dita/practitioners-1/
      • renderxxep
        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
        Message 3 of 4 , Feb 19, 2013
        • 0 Attachment
          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.

          To get that original PDF, you have to compose the page and figure out everything. This is exactly the same as composing to SVG or XHTML (all three of which you can do with RenderX software). "XSLFO.js" would by definition be a complete composition engine written in Javascript. Something as simple as HTML ... OK, something as complex as kerning, line ending decisions, keeps, floats and repositioning, .... and much more will not happen in JS or a browser anytime soon.

          You can certainly take a simple XSL and convert XSL FO to HTML and get a decent result, but thinking that XSL FO composition to pages in javascript is close to a format conversion of PDF objects to a screen is a big stretch.

          It is not even close.

          Kevin Brown
          RenderX
        • matt_kaatman
          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
          Message 4 of 4 , Feb 20, 2013
          • 0 Attachment
            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 dita-users@yahoogroups.com, 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).
          Your message has been successfully submitted and would be delivered to recipients shortly.