Announcement

Collapse
No announcement yet.

Firefox 19 Release Today Brings The PDF Viewer

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

  • Thaodan
    replied
    Originally posted by hajj_3 View Post
    They want it in javascript so they can use it on any device such as firefox os, set top boxes etc which only support html5 and javascript. Writing in javascript is the best way, it just needs improving, have patience.
    Boxes that support Firefox, support poppler too. I don't see why do everything in Javascript even if its not wise.

    Leave a comment:


  • hajj_3
    replied
    Originally posted by Linuxhippy View Post
    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.
    They want it in javascript so they can use it on any device such as firefox os, set top boxes etc which only support html5 and javascript. Writing in javascript is the best way, it just needs improving, have patience.

    Leave a comment:


  • Linuxhippy
    replied
    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; 02-20-2013, 02:04 PM.

    Leave a comment:


  • locovaca
    replied
    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*.

    Leave a comment:


  • hajj_3
    replied
    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.

    Leave a comment:


  • Linuxhippy
    replied
    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:

    https://bugzilla.mozilla.org/show_bug.cgi?id=843166
    https://bugzilla.mozilla.org/show_bug.cgi?id=843184

    Regards

    Leave a comment:


  • madbiologist
    replied
    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?

    Leave a comment:


  • Linuxhippy
    replied
    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.

    Leave a comment:


  • locovaca
    replied
    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.

    Leave a comment:


  • smitty3268
    replied
    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.

    Leave a comment:

Working...
X