5 ms·

> Pdf support should also be removed from all browsers. Why? Instead of opening a PDF like any other webpage, or image, or video, etc. Which is instant and doe

> Pdf support should also be removed from all browsers. Why? Instead of opening a PDF like any other webpage, or image, or video, etc. Which is instant and doesn't require any mental focus shifting, I should instead download the PDF, and use a PDF viewer instead? For something so ubiquitous it seems kind of silly. Browsers are for browsing and consuming content, if a specific type of content has widespread usage, I see no reason not to include it.

delfinom 7y ago
One problem is browsers have incomplete PDF implementations. PDFs with 3d models is big in the engineering industry as dumb as it is and Chrome completely fails there and results in numerous less engineering user complaints :/
- jjohansson 7y ago
  PDFium and PDF.js have only implemented a small subset of the spec. Other features they don’t support include certain image compression formats or colour management. It’s really only suitable for the simplest of PDFs...
jolmg 7y ago
> Which is instant and doesn't require any mental focus shifting Opening URLs from the browser to native apps specialized for their format shouldn't be non-instant or require any mental focus shifting. > Browsers are for browsing and consuming content "Browser" is short of "Web Browser". They're meant primarily for HTML pages. General "browsing and consuming content" is too broad. You're including file managers and multimedia players in that. There's no reason to concentrate everything into a single program. Shifting between specialized applications should be seamless. If it's not, the window manager / desktop environment is lacking configuration / features. > if a specific type of content has widespread usage, I see no reason not to include it. Because you end up with a bloated mess. The modern web browser is an OS inside an OS.
- derefr 7y ago
  > "Browser" is short of "Web Browser". They're meant primarily for HTML pages. I don't see how you get from the first of these statements to the second. Web browsers browse the web—an interlinked set of hypertext documents. A "hypertext document" being anything that embeds URLs you can tell the browser to navigate to, usually by clicking. A PDF is a "hypertext document." > There's no reason to concentrate everything into a single program. An ePub is also a hypertext document, though. And one that is made out of HTML and CSS files! Would you suggest that a web browser shouldn't be able to open an MHTML archive? Because an ePub is almost exactly the same format, just with a different base CSS style + media selector. (There are some restrictions on scriptability, but from what I recall those are ePub UA restrictions, not restrictions in the standard.) > Shifting between specialized applications should be seamless. What if you could shift between specialized applications... inside other applications? Remember OLE? That's how web browsers have traditionally displayed most formats. The whole need for special plugins for QuickTime, Flash, ActiveX, Java, etc. was just to allow those formats to be embedded in HTML pages. But if you're just opening a URL in the web browser and handing the viewport over to a COM component to render—browsers (and many other types of applications) do that just fine, without any need for "concentrating everything into a single program."
jjohansson 7y ago
PDF is a really complex format that Google and Mozilla don’t want to spend a lot of time maintaining. PDFium is an an acceptable rendering engine for simpler PDF files, but doesn’t handle complex files very well (resulting in crashes or rendering inaccuracies). Same with PDF.js. Unless the browsers step up, these issues will continue to get worse.

delfinom 7y ago

One problem is browsers have incomplete PDF implementations. PDFs with 3d models is big in the engineering industry as dumb as it is and Chrome completely fails there and results in numerous less engineering user complaints :/

jjohansson 7y ago
PDFium and PDF.js have only implemented a small subset of the spec. Other features they don’t support include certain image compression formats or colour management. It’s really only suitable for the simplest of PDFs...

jolmg 7y ago

> Which is instant and doesn't require any mental focus shifting Opening URLs from the browser to native apps specialized for their format shouldn't be non-instant or require any mental focus shifting. > Browsers are for browsing and consuming content "Browser" is short of "Web Browser". They're meant primarily for HTML pages. General "browsing and consuming content" is too broad. You're including file managers and multimedia players in that. There's no reason to concentrate everything into a single program. Shifting between specialized applications should be seamless. If it's not, the window manager / desktop environment is lacking configuration / features. > if a specific type of content has widespread usage, I see no reason not to include it. Because you end up with a bloated mess. The modern web browser is an OS inside an OS.

derefr 7y ago
> "Browser" is short of "Web Browser". They're meant primarily for HTML pages. I don't see how you get from the first of these statements to the second. Web browsers browse the web—an interlinked set of hypertext documents. A "hypertext document" being anything that embeds URLs you can tell the browser to navigate to, usually by clicking. A PDF is a "hypertext document." > There's no reason to concentrate everything into a single program. An ePub is also a hypertext document, though. And one that is made out of HTML and CSS files! Would you suggest that a web browser shouldn't be able to open an MHTML archive? Because an ePub is almost exactly the same format, just with a different base CSS style + media selector. (There are some restrictions on scriptability, but from what I recall those are ePub UA restrictions, not restrictions in the standard.) > Shifting between specialized applications should be seamless. What if you could shift between specialized applications... inside other applications? Remember OLE? That's how web browsers have traditionally displayed most formats. The whole need for special plugins for QuickTime, Flash, ActiveX, Java, etc. was just to allow those formats to be embedded in HTML pages. But if you're just opening a URL in the web browser and handing the viewport over to a COM component to render—browsers (and many other types of applications) do that just fine, without any need for "concentrating everything into a single program."

jjohansson 7y ago

PDF is a really complex format that Google and Mozilla don’t want to spend a lot of time maintaining. PDFium is an an acceptable rendering engine for simpler PDF files, but doesn’t handle complex files very well (resulting in crashes or rendering inaccuracies). Same with PDF.js. Unless the browsers step up, these issues will continue to get worse.