Announcement

Collapse
No announcement yet.

Firefox 19 Release Today Brings The PDF Viewer

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Rexilion View Post
    Thanks! It would not accept my 9MB PDF, but I did upload a .ppt -> .pdf slideshow. Very smooth experience. Only many letters/numbers are garbled. SoMEtHiNg LIke ThIS. Looks promising though.
    Yeah, I have similar experiences with the handful of PDFs I tried.

    Originally posted by Rexilion View Post
    I can see the benefits of reinventing the wheel just to be able to do this in a browser without plugins. I can see the benefit, it's a shame they have to do it all over again while we have great library's like popper already.
    Well, Mozilla does not accept pure copyleft code (in Poppler's case GPL-only). The JavaScript approach also has the benefit that it should work everywhere without porting anything. Just a decent browser engine has to be present to get a PDF viewer on platforms that didn't have one.

    Comment


    • #22
      Originally posted by Rexilion View Post
      Thanks! It would not accept my 9MB PDF, but I did upload a .ppt -> .pdf slideshow. Very smooth experience. Only many letters/numbers are garbled. SoMEtHiNg LIke ThIS. Looks promising though.

      I can see the benefits of reinventing the wheel just to be able to do this in a browser without plugins. I can see the benefit, it's a shame they have to do it all over again while we have great library's like popper already.
      I opened a 110MB pdf (an NIST realtime linux paper). Pretty slow, but displays properly. Text search didn't work, however.
      Using FF18 with pdf.js plugin.
      I was also compiling a kernel.
      Using FF nightly while also compiling a kernel resulted in MUCH faster rendering times for the same pdf, but still text search didn't work.

      Comment


      • #23
        Originally posted by locovaca View Post
        No, I actually won't share the link to my W-2. It's a rather personal financial document. It is not a "form" in that it has data input, however.

        Here's a sample of a different doc, it doesn't peg my CPU, but Firefox' memory usage shoots up about 300 megabytes to render and scroll the form.

        http://www.irs.gov/pub/irs-pdf/fw2.pdf
        LOL, i thought maybe it was a blank one, such as the one you did link there.

        I only asked, because i have noticed the memory issue for sure, and CPU is pretty bad while it's initially loading/scrolling the pdf, but i hadn't noticed any documents that kept pegging the cpu for a long time.

        Comment


        • #24
          Originally posted by smitty3268 View Post
          LOL, i thought maybe it was a blank one, such as the one you did link there.

          I only asked, because i have noticed the memory issue for sure, and CPU is pretty bad while it's initially loading/scrolling the pdf, but i hadn't noticed any documents that kept pegging the cpu for a long time.
          Yeah, I tried to find a blank one provided by the vendor my employer uses but couldn't. It's (the wonderful) Paychex Systems.

          Comment


          • #25
            Wow - I didn't think they really use it by default in FF19. It is:
            - Slow
            - Resource-intensice (nrowsing in a pdf made firefox consume 1.4gb of ram)
            - Incompatible (I've seen more PDFs which cause issues than pdfs which are rendered completely fine)
            - Buggy (beside the rendering errors, I found quite a few other annoying issues)

            Already filed 3 bug-reports against pdf.js - pdf.js is really a nice tech-demo but integrating it into production-software in its current status is just plain stupid.

            Comment


            • #26
              Originally posted by Linuxhippy View Post
              Already filed 3 bug-reports against pdf.js...
              Bug numbers?

              I've just tested some PDF's and found the following problems.

              https://launchpadlibrarian.net/82936611/NM_dimer_He.pdf - This renders with the right-hand part of the chart data missing, which used to occur in Evince with poppler and cairo but is fixed in Ubuntu 12.10 "Quantal Quetzal" with Evince 3.6.0-0ubuntu2, libpoppler26 0.20.1-1ubuntu1 and libcairo2 1.12.2-1ubuntu2.1. The axis labels are also displayed in what appears to possibly be Greek, which is a problem which never occurred in Evince with poppler and cairo.

              https://launchpadlibrarian.net/45372...3%89PLIANT.pdf - Some of the text boxes are white instead of blue, and others are black instead of blue. In Adobe reader it looks like this - http://launchpadlibrarian.net/45524055/acroread.png - The document uses blend modes, which used to produce the same artifacts in Evince but was fixed in cairo >= 1.9.4.

              https://launchpadlibrarian.net/79260069/pixart.pdf - The red watermark is barely visible. Evince in Ubuntu 12.04 "Precise Pangolin" renders it more brightly/heavily.

              https://bugs.launchpad.net/poppler/+...s/seminar1.pdf - This renders with horizontal lines accross the blue background. This problem also occurs on Ubuntu 12.10 "Quantal Quetzal" with Evince 3.6.0-0ubuntu2, libpoppler26 0.20.1-1ubuntu1 and libcairo2 1.12.2-1ubuntu2.2.

              I dont have a Mozilla bugzilla (did they do that on purpose?) account and am reluctant to open one. Perhaps someone could file the above bugs on my/our behalf and report the bug numbers here?

              Comment


              • #27
                Originally posted by madbiologist View Post
                I dont have a Mozilla bugzilla (did they do that on purpose?) account and am reluctant to open one. Perhaps someone could file the above bugs on my/our behalf and report the bug numbers here?
                I created two reports for issues I was able reproduce, but I really suggest to create your own account:




                Regards

                Comment


                • #28
                  firefox 19 does indeed use 300mb for the pdf you linked but once you close it then it goes back to normal memory usage in about 20 seconds for me. Firefox will update the pdf.js with each new version so you will notice faster speeds, lower memory consumption and less rendering problems with each new version of firefox. I've been using since v17 i think and it works on nearly all my pdf's, most of them are just text with some jpgs. You can still use a 3rd party reader so it isn't a big deal if it doesn't work fully for you. I'd rather use this open source one than an insecure pdf reader like adobe's and have backdoors built in so governments can spy on you.

                  Comment


                  • #29
                    Originally posted by hajj_3 View Post
                    firefox 19 does indeed use 300mb for the pdf you linked but once you close it then it goes back to normal memory usage in about 20 seconds for me. Firefox will update the pdf.js with each new version so you will notice faster speeds, lower memory consumption and less rendering problems with each new version of firefox. I've been using since v17 i think and it works on nearly all my pdf's, most of them are just text with some jpgs. You can still use a 3rd party reader so it isn't a big deal if it doesn't work fully for you. I'd rather use this open source one than an insecure pdf reader like adobe's and have backdoors built in so governments can spy on you.
                    I'm all for browsers doing their own pdf decoding, but the memory usage is pretty awful. It's a 10 page document with relatively simple graphics (a couple of small embedded images and otherwise just text and boxes with borders. Chrome renders it in 30 megs. Just because it releases the memory when it garbage collects doesn't make it acceptable as a production released, defaulted option.

                    *Insert snark about javascript here*.

                    Comment


                    • #30
                      Firefox will update the pdf.js with each new version so you will notice faster speeds, lower memory consumption and less rendering problems with each new version of firefox. I've been using since v17 i think and it works on nearly all my pdf's, most of them are just text with some jpgs.
                      So I think we can agree pdf.js is not ready for now. What in god's name has been the relationale behind enabling it as default option?

                      Originally posted by hajj_3 View Post
                      Firefox will update the pdf.js with each new version so you will notice faster speeds, lower memory consumption and less rendering problems with each new version of firefox.
                      What I don't understand: pdf.js is a mozilla sponsored project. They have *paid* developers working on implementing stuff which is known to be really hard to do, and which is already available as open-source for a long time (e.g. with poppler).
                      This leads to less staff/resources left working on the browser core, which requires quite a lot of work to keep pace with google and it's chrome browser. (I am not saying chrome is better/worse, only that google pushes chrome quite agressivly)

                      I'd rather use this open source one than an insecure pdf reader like adobe's and have backdoors built in so governments can spy on you.
                      Poppler is a quite capable pdf renderer/interpreter which is open-source too and is *fast* and *mature*.
                      The only valid argument in favour of pdf.js is security.
                      Last edited by Linuxhippy; 20 February 2013, 02:04 PM.

                      Comment

                      Working...
                      X