6 ms·

Oh jesus christ. The entire ML thread is bad news. Why on earth would they move away from PDF.js (which is a fantastic project) and then use that move to justi

Oh jesus christ. The entire ML thread is bad news. Why on earth would they move away from PDF.js (which is a fantastic project) and then use that move to justify Mortar? Also, I just learned this from the thread: Why the fuck would they kill Shumway? I'm all for killing Flash, but Shumway is an important tool not just for migration, it's also really important for archival. God damn it Mozilla. I've talked about this before, too: Hearing Mozilla executives, each Mozfest, talk about commitment to the free web. Commitment to open technologies. What commitment, exactly? In a handful of years, Mozilla has managed to severely damage its poster child web browser's reputation by including then subsequently dropping drm, by including then subsequently dropping Hello (a good initiative with a horrible user experience), by completely screwing up the launch of Pocket (which they could only have done by massively misunderstanding their userbase). In that same handful of years, Mozilla took some good initiatives, such as Persona and Firefox OS, completely botched marketing and experience on both, severely underestimated the required efforts on the latter, then dropped both projects. In that same handful of years, Mozilla dropped support for its second poster child, Thunderbird, arguably the last decent FOSS email client. It all screams mismanagement and I haven't even talked about half of the problems. I've been upset about all this for some time but now writing it all out I'm starting to wonder of Mozilla isn't just in a free fall. PS: I 100% understand the concerns and difficulties of allocating development time but this is a pattern I keep seeing with Mozilla: Spin up a project, get it to 80%, give up. You could build a castle with the amount of efforts wasted on projects either doomed from the beginning (FxOs), or dropped near the finish line. This is all absurd.

fdej 10y ago
Anecdotally, PDF.js is slow compared to native viewers and often renders documents incorrectly. And the project is five years old now. It's not bad as a fallback, but considering how important PDF files are, looking for a better solution makes sense.
- eridius 10y ago
  Agreed. As an OS X user, I hate it any time a browser or website uses something like PDF.js instead of the native PDF support. The native PDF support in OS X is fast and excellent.
  - dmix 10y ago
    > instead of the native PDF support You mean instead of just downloading the file? Or does Preview support opening PDF links.
    - eridius 10y ago
      Safari will display PDFs natively without requiring you to download it to disk.
      - hellofunk 10y ago
        And on iOS too!
        taspeotis 10y ago
        Care of QLPreviewController [1], something I wish Android had an equivalent for... [1] https://developer.apple.com/reference/quicklook/qlpreviewcontroller https://developer.apple.com/reference/quicklook/qlpreviewcon...
        om2 10y ago
        And fully sandboxed on both macOS and iOS!
    - the_watcher 10y ago
      Preview does support opening PDF links.
- bluedino 10y ago
  While convienent, I can't see how anyone would want to use a browser-based PDF viewer over a native one.
  - scrollaway 10y ago
    Convenience is exactly it. Have to admit I find it pretty damn useful myself, even though I believe PDFs to be completely out of scope of a web browser. I really wish the format would disappear. Everybody says it's useful at being a "perfect digital representation of what things look like on paper", which is certainly super useful for printing. But I cannot understand how so much information that should simply be distributed in either HTML (forms), epub (ebooks) or jpg/png (scans and digital images) is distributed over PDF, a pain-in-the-arse, overengineered format whose readers are always extremely slow and riddled with security issues and from which it's extremely hard to extract source data.
    - Sanddancer 10y ago
      There are a number of places where PDF has advantages that HTML, etc can't match. For forms, the PDF spec has electronic signatures, which means that you can sign legal documents without having to find a fax machine, or mail things back and forth. For print documents, it can do things like multiple column text in a sensible manner, across page breaks. As a general document format, it allows you to actually describe paper sizes, etc, so you can email someone a document that looks like it will when it's finalized. For archival, it means you can, without a bunch of hacks, create searchable documents of old, scanned in content. So things like electronics datasheets are searchable, and still retain the formatting of the originals. PDF continues to exist because there are so very many places that the alternatives are an even bigger pain in the ass, fix those, and then you can start to get rid of pdf.
      - scrollaway 10y ago
        All sensible uses of PDF (except your first one; electronic signatures are ridiculous, but let's not get into that). I'm talking about where pdf is used and shouldn't be.
- agumonkey 10y ago
  PDF.js sole purpose is to be non native. I don't want to rely on native existence of a safe enough, fast enough PDF renderer. PDF.js provides just that.
- jahewson 10y ago
  Then they should make PDF.js faster! The way it uses a canvas could be significantly improved. I guess the point is that they don't want to invest the engineering resources to do that, which is a shame but I understand the reasoning.
- euske 10y ago
  My work machine is now completely Adobe-free. thanks to PDF.js. I hope they keep this project afloat.
qwertyuiop924 10y ago
Yeah, Shumway shouldn't have been dropped. And It is annoying. And stupid. OTOH, this probably means more work gets done on Gecko, Servo, the *Monkeys, and Rust. Which is pretty good.
- scrollaway 10y ago
  > this probably means more work gets done on Gecko, Servo, the Monkeys, and Rust Well, does it? Are they moving devs from PDF.js to the Rust ecosystem? It seems more likely to me that they would either lay them off, or move them to the PDFium stuff. Same applies to Shumway. What a backwards step either way. As for Servo, how's it doing these days? Is it anywhere near done? What terrifies me is Mozilla would drop Servo when it's 80% done, just like it did with all its other projects, because "well, we already have Gecko, and it works, and it's too much work to finish Servo". Aside from Rust and some Firefox tech, I haven't seen anything concrete come out of Mozilla in a long, long time. Rust, FWIU, has its own organization and is no longer handled by Mozilla alone (thank god); everything else gets killed off like a westerosi wedding.
  - pcwalton 10y ago
    > As for Servo, how's it doing these days? Is it anywhere near done? Steady progress as always! You can follow along with This Week in Servo at https://blog.servo.org/ https://blog.servo.org/ :) Recently we just added flexbox support and the Fetch API, just to name two of many.
    - scrollaway 10y ago
      Thanks! Good to see a blog. I'm very excited about Servo; like I was saying, I just really hope it won't get killed off before it reaches the finish line and replaces Gecko. Patterns are scary.
      - qwertyuiop924 10y ago
        I don't think they'll kill Servo. They need to modernize Gecko, and there's so much potential in Servo to do so that it would be a waste throw the code out.
thowaway2 10y ago
Shipping Shumway has some problems due to patent claims by Adobe, as I understand. It was thought that things could be worked out, but apparently that fell through. So the options are to either keep developing Shumway but not ship it, or stop developing it and not ship it. The latter is a bit more attractive if resources are limited.
- petecox 10y ago
  I have previously installed shumway but it never seemed to work on the websites I wanted to load. :( So perhaps the remaining effort to get it working was too much.
bzbarsky 10y ago
I'm not sure what the "including then subsequently dropping drm" thing you're talking about is...
bad_user 10y ago
Thunderbird is still my email client and it's still getting updates. Not sure where it will be in a couple of years, but for now it's still very much decent. And I liked the idea behind PDF.js very much, have been a big fan, but it's still rendering documents incorrectly and doesn't do forms. Mozilla is an organization that needs to be careful about allocating their resources. These projects are open-source and with enough interest they can continue. If Mozilla's Persona died, that's because it never had a future in the first place and killing it was the right call ;-) And on Hello and Pocket, I really don't understand the drama. I think the Internet is making some of us way too pissy.
Manishearth 10y ago
They're not killing PDF.js, just taking a step in a direction that might eventually lead to it dying. This is explicitly mentioned in the ML thread. Shumway hasn't been worked on in a while. No idea why, but I would guess that it has something to do with how large the Flash feature set is. Long tail and all that. The reasoning here is probably like so (speculating here): - We want to deprecate most plugin APIs - We still want to support flash - Shumway isn't there yet, let's use pepper flash - Flash and PDF probably need very similar feature sets as far as the API is concerned - Supporting the subset of PPAPI needed for Flash is probably going to let us include PDFium too, which is already supported by Google. As long as we're going down this path, let's try to include PDFium too. - In case PDFium turns out to work, we can decide if pdf.js needs to be replaced I personally hope that pdf.js isn't replaced; since a JS thingy is far better than a vulnerability-ridden C program. At the same time, this depends on how much the demand for a full pdf feature set is.

fdej 10y ago

Anecdotally, PDF.js is slow compared to native viewers and often renders documents incorrectly. And the project is five years old now. It's not bad as a fallback, but considering how important PDF files are, looking for a better solution makes sense.

eridius 10y ago
Agreed. As an OS X user, I hate it any time a browser or website uses something like PDF.js instead of the native PDF support. The native PDF support in OS X is fast and excellent.
- dmix 10y ago
  > instead of the native PDF support You mean instead of just downloading the file? Or does Preview support opening PDF links.
  - eridius 10y ago
    Safari will display PDFs natively without requiring you to download it to disk.
    - hellofunk 10y ago
      And on iOS too!
      - taspeotis 10y ago
        Care of QLPreviewController [1], something I wish Android had an equivalent for... [1] https://developer.apple.com/reference/quicklook/qlpreviewcontroller https://developer.apple.com/reference/quicklook/qlpreviewcon...
      - om2 10y ago
        And fully sandboxed on both macOS and iOS!
  - the_watcher 10y ago
    Preview does support opening PDF links.
bluedino 10y ago
While convienent, I can't see how anyone would want to use a browser-based PDF viewer over a native one.
- scrollaway 10y ago
  Convenience is exactly it. Have to admit I find it pretty damn useful myself, even though I believe PDFs to be completely out of scope of a web browser. I really wish the format would disappear. Everybody says it's useful at being a "perfect digital representation of what things look like on paper", which is certainly super useful for printing. But I cannot understand how so much information that should simply be distributed in either HTML (forms), epub (ebooks) or jpg/png (scans and digital images) is distributed over PDF, a pain-in-the-arse, overengineered format whose readers are always extremely slow and riddled with security issues and from which it's extremely hard to extract source data.
  - Sanddancer 10y ago
    There are a number of places where PDF has advantages that HTML, etc can't match. For forms, the PDF spec has electronic signatures, which means that you can sign legal documents without having to find a fax machine, or mail things back and forth. For print documents, it can do things like multiple column text in a sensible manner, across page breaks. As a general document format, it allows you to actually describe paper sizes, etc, so you can email someone a document that looks like it will when it's finalized. For archival, it means you can, without a bunch of hacks, create searchable documents of old, scanned in content. So things like electronics datasheets are searchable, and still retain the formatting of the originals. PDF continues to exist because there are so very many places that the alternatives are an even bigger pain in the ass, fix those, and then you can start to get rid of pdf.
    - scrollaway 10y ago
      All sensible uses of PDF (except your first one; electronic signatures are ridiculous, but let's not get into that). I'm talking about where pdf is used and shouldn't be.
agumonkey 10y ago
PDF.js sole purpose is to be non native. I don't want to rely on native existence of a safe enough, fast enough PDF renderer. PDF.js provides just that.
jahewson 10y ago
Then they should make PDF.js faster! The way it uses a canvas could be significantly improved. I guess the point is that they don't want to invest the engineering resources to do that, which is a shame but I understand the reasoning.
euske 10y ago
My work machine is now completely Adobe-free. thanks to PDF.js. I hope they keep this project afloat.

qwertyuiop924 10y ago

Yeah, Shumway shouldn't have been dropped. And It is annoying. And stupid. OTOH, this probably means more work gets done on Gecko, Servo, the *Monkeys, and Rust. Which is pretty good.

scrollaway 10y ago
> this probably means more work gets done on Gecko, Servo, the Monkeys, and Rust Well, does it? Are they moving devs from PDF.js to the Rust ecosystem? It seems more likely to me that they would either lay them off, or move them to the PDFium stuff. Same applies to Shumway. What a backwards step either way. As for Servo, how's it doing these days? Is it anywhere near done? What terrifies me is Mozilla would drop Servo when it's 80% done, just like it did with all its other projects, because "well, we already have Gecko, and it works, and it's too much work to finish Servo". Aside from Rust and some Firefox tech, I haven't seen anything concrete come out of Mozilla in a long, long time. Rust, FWIU, has its own organization and is no longer handled by Mozilla alone (thank god); everything else gets killed off like a westerosi wedding.
- pcwalton 10y ago
  > As for Servo, how's it doing these days? Is it anywhere near done? Steady progress as always! You can follow along with This Week in Servo at https://blog.servo.org/ https://blog.servo.org/ :) Recently we just added flexbox support and the Fetch API, just to name two of many.
  - scrollaway 10y ago
    Thanks! Good to see a blog. I'm very excited about Servo; like I was saying, I just really hope it won't get killed off before it reaches the finish line and replaces Gecko. Patterns are scary.
    - qwertyuiop924 10y ago
      I don't think they'll kill Servo. They need to modernize Gecko, and there's so much potential in Servo to do so that it would be a waste throw the code out.

thowaway2 10y ago

Shipping Shumway has some problems due to patent claims by Adobe, as I understand. It was thought that things could be worked out, but apparently that fell through. So the options are to either keep developing Shumway but not ship it, or stop developing it and not ship it. The latter is a bit more attractive if resources are limited.

petecox 10y ago
I have previously installed shumway but it never seemed to work on the websites I wanted to load. :( So perhaps the remaining effort to get it working was too much.

bzbarsky 10y ago

I'm not sure what the "including then subsequently dropping drm" thing you're talking about is...

bad_user 10y ago

Thunderbird is still my email client and it's still getting updates. Not sure where it will be in a couple of years, but for now it's still very much decent. And I liked the idea behind PDF.js very much, have been a big fan, but it's still rendering documents incorrectly and doesn't do forms. Mozilla is an organization that needs to be careful about allocating their resources. These projects are open-source and with enough interest they can continue. If Mozilla's Persona died, that's because it never had a future in the first place and killing it was the right call ;-) And on Hello and Pocket, I really don't understand the drama. I think the Internet is making some of us way too pissy.

Manishearth 10y ago

They're not killing PDF.js, just taking a step in a direction that might eventually lead to it dying. This is explicitly mentioned in the ML thread. Shumway hasn't been worked on in a while. No idea why, but I would guess that it has something to do with how large the Flash feature set is. Long tail and all that. The reasoning here is probably like so (speculating here): - We want to deprecate most plugin APIs - We still want to support flash - Shumway isn't there yet, let's use pepper flash - Flash and PDF probably need very similar feature sets as far as the API is concerned - Supporting the subset of PPAPI needed for Flash is probably going to let us include PDFium too, which is already supported by Google. As long as we're going down this path, let's try to include PDFium too. - In case PDFium turns out to work, we can decide if pdf.js needs to be replaced I personally hope that pdf.js isn't replaced; since a JS thingy is far better than a vulnerability-ridden C program. At the same time, this depends on how much the demand for a full pdf feature set is.