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

Re: [dita-users] ANN: Firefox (version 19) now has an internal PDF renderer

Expand Messages
  • 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 1 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 2 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 3 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.