5 ms·

It's amazing browsers have so far decided to just not have an HTML archive format that could replace PDF. The majority of what PDF does can be better done in a

It's amazing browsers have so far decided to just not have an HTML archive format that could replace PDF. The majority of what PDF does can be better done in a webpage. Why not just an extension like .phd but is actually a .tar.gz that contains a webpages assets. Present like pdf's are, and done.

saagarjha 8y ago
PDFs are supposed to look the same on every computer. Webpages can’t do that yet.
- devwastaken 8y ago
  I don't know how accurate that is for PDF's, but webpages are supposed to look the same, and given known compatible styling, it should be on any modern browser. Browsers are extremely consistent in content presentation, that's why webpages from early 2000s still look the same.
  - deleted 8y ago
    [deleted]
  - megous 8y ago
    No. Take for example font-family: sans-serif. That can look like anything, can have different widths on different devices, etc. Browser windows can have any size, devices can have various pixel densities, users can work at different zoom levels, etc. The previous big thing was responsive design.
    - arianvanp 8y ago
      Same counts for PDFs. If the font isn't shipped inside the bundle, the PDF will look like shit.
      - megous 8y ago
        Good point. I noticed that too. At least web pages are made so that the content is re-flown [seems like the whole point], so it doesn't look like shit. It seems like [many?] PDFs place each character separately so if the actually used font is different from the one used during creation, the result will look very messy.
  - bjelkeman-again 8y ago
    Web page rendering is far from similar on different browsers. I agreed that an alternative to PDF would be a good thing, but it probably would be more like a lightweight PDF than what HTML is today.
  - pwg 8y ago
    > I don't know how accurate that is for PDF's, but webpages are supposed to look the same, One of Adobe's early talking points for the value of PDF's was that they would "look the same on all systems". Of course some context is necessary. PDF first appeared in 1993. In 1993, while the internet did exist, most individuals who were not associated with a university, research lab, or govt. agency, had no access to 'the internet'. As well, the computing world was much more diverse. One had Dos, early Windows, and various MacOS variants all coexisting, one had numerous different variants of Unix on the numerous different RISC workstations in existence. And, here was the big deal, 'documents' created on each of these systems were to a large extent incompatible with each other. In this context, 'document' should be thought of as "a file used to create paper printouts" as opposed to what we think of a 'document' now in 2018. There was some compatibility, in that Windows systems would, sometimes, read 'documents' produced by Dos based word processors, and of course the lowest common denominator, plain text file, was 'almost' compatible (line ending differences was the biggest incompatibility). But for anything more complicated, if person X created a 'document' on Dos, and they wanted person Y, using SunOS, to see a version that "looked the same", their best bet was to print their document to paper and give Y the printer output. Because if they could send the electronic file to Y somehow, chances were that Y would be unable to open it, and even if they could, there was a good chance that it did not 'look the same' (from a 'looks like the same paper printout' level of same). PDF came about in this world where paper was still king, and Adobe's marketing of "looks the same" was really meant to be "produces the same paper printout for the receiver Y as it does for creator X". That is why, today, in 2018, that viewing a PDF still looks like one is viewing WYSIWYG of a paper printout. PDF is, quite intimately, tied to the concept that there are discrete sheets of paper that it is formatting data onto. Yes some viewers do provide an 'almost' HTML continuous scroll look, but that is done 100% in the viewer, the underlying PDF format is very paper page oriented at its core. So, when comparing PDF intent to web page intent, the phrase "looks the same" has different meanings. For PDF, it was designed such that "looks the same" means that a paper printout looks identical to the original. And that the designer/creator has full control over the look, while the viewer has no control over the look. For web pages, "looks the same" is far less strict, and is really not the same meaning, because the web was always intended to allow the viewer much freedom in deciding how to display the HTML content, taking away the designers ability to strictly determine look and presentation. With the result that HTML data was never meant to "look the same" with the same strictness intended by PDF.
  - omaranto 8y ago
    What? Lot's of webpages look different after simply resizing the window! The fact that this is on purpose, doesn't mean it doesn't happen (quite the opposite!).
    - devwastaken 8y ago
      That's because they're designed that way. You can do styling in a way that is not effected by browser window sizing, typically with specified document dimensions, or absolute positioning.
- Already__Taken 8y ago
  moreso, webpages were never meant to, by design. It is not print media without the print.
- fulafel 8y ago
  Not with text markup, but you could just use canvas or svg.
ryacko 8y ago
90% of PDFs could be replaced using a background PNG/JPEG file and a visible/invisible text overlay. Instead of forms embedded in the “.phd”, one could just use HTML forms and and then use javaScript to export it as a “.phd” document, covering 99% of PDF use cases.
joshschreuder 8y ago
Isn't that sort of what MHTML is? https://en.wikipedia.org/wiki/MHTML https://en.wikipedia.org/wiki/MHTML I remember saving .mht files with IE as a kid when working on assignments so I could disconnect the dialup and give my parents their phone line back :)
- Already__Taken 8y ago
  With service workers we're almost a save-as shim away from being back to this.
- devwastaken 8y ago
  Sort of, but mhtml isn't a good format. It was a hacky way of taking what emails did. It's embedding all content in a single file, not as an archive. Rather it should be you can open up the HTML archive like an actual archive and see the individual files.
  - acqq 8y ago
    Opera 12 (the original one, before the managers decided that it should be based on Chromium) had the .zip files support built in; that means that if the URL was somepath/archive.zip/index.html and index.html refers to other files, they would be read from the same zip, even if they are only inside of the zip. I used it a lot for the local archives of the bigger content, it is amazingly convenient, and I'm sad that the same approach was not used anywhere else. It's not trivial to get it right, in the security aspects (the zip implementation has to be robust, the url handling too) but it's doable and it would be very practical to have it. Tangentially, the good thing of the zip format is that it has so called "central directory" which means that you don't even have to load the whole archive if not all data is needed, just the last part of the file, and from there you get the offset and the location of the needed file. So the Zip files could work beautifully with the https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ra... when they are huge(1). The small ones are most effective to be downloaded at once, of course. 1) I've actually done such a sequence by hand a few times when I had a slow internet and knew that I don't need the whole zip file, but just to see that all files are inside: I've made the range request for the end of the file which would be enough for the estimated number of files inside, and so I've had the list of all the files in the archive without needed to download the whole archive: I've reconstructed the same file size but left the rest of it be zeroes, and some of the zip tools I've used treated the archive directory exactly as I needed it.
occamrazor 8y ago
.chm (windows help files format) is almost exactly that. It had its fair share of security vulnerabilities.
jabl 8y ago
IIRC the epub format used for e-books is essentially a container with html.
aidos 8y ago
You can take a PDF and plot it, print it, display it on screen and it will always look the same. SVG is a closer to PDF than html is - and svg gets a lot of grief for having an overly complicated spec too.
deleted 8y ago
[deleted]

saagarjha 8y ago

PDFs are supposed to look the same on every computer. Webpages can’t do that yet.

devwastaken 8y ago
I don't know how accurate that is for PDF's, but webpages are supposed to look the same, and given known compatible styling, it should be on any modern browser. Browsers are extremely consistent in content presentation, that's why webpages from early 2000s still look the same.
- deleted 8y ago
  [deleted]
- megous 8y ago
  No. Take for example font-family: sans-serif. That can look like anything, can have different widths on different devices, etc. Browser windows can have any size, devices can have various pixel densities, users can work at different zoom levels, etc. The previous big thing was responsive design.
  - arianvanp 8y ago
    Same counts for PDFs. If the font isn't shipped inside the bundle, the PDF will look like shit.
    - megous 8y ago
      Good point. I noticed that too. At least web pages are made so that the content is re-flown [seems like the whole point], so it doesn't look like shit. It seems like [many?] PDFs place each character separately so if the actually used font is different from the one used during creation, the result will look very messy.
- bjelkeman-again 8y ago
  Web page rendering is far from similar on different browsers. I agreed that an alternative to PDF would be a good thing, but it probably would be more like a lightweight PDF than what HTML is today.
- pwg 8y ago
  > I don't know how accurate that is for PDF's, but webpages are supposed to look the same, One of Adobe's early talking points for the value of PDF's was that they would "look the same on all systems". Of course some context is necessary. PDF first appeared in 1993. In 1993, while the internet did exist, most individuals who were not associated with a university, research lab, or govt. agency, had no access to 'the internet'. As well, the computing world was much more diverse. One had Dos, early Windows, and various MacOS variants all coexisting, one had numerous different variants of Unix on the numerous different RISC workstations in existence. And, here was the big deal, 'documents' created on each of these systems were to a large extent incompatible with each other. In this context, 'document' should be thought of as "a file used to create paper printouts" as opposed to what we think of a 'document' now in 2018. There was some compatibility, in that Windows systems would, sometimes, read 'documents' produced by Dos based word processors, and of course the lowest common denominator, plain text file, was 'almost' compatible (line ending differences was the biggest incompatibility). But for anything more complicated, if person X created a 'document' on Dos, and they wanted person Y, using SunOS, to see a version that "looked the same", their best bet was to print their document to paper and give Y the printer output. Because if they could send the electronic file to Y somehow, chances were that Y would be unable to open it, and even if they could, there was a good chance that it did not 'look the same' (from a 'looks like the same paper printout' level of same). PDF came about in this world where paper was still king, and Adobe's marketing of "looks the same" was really meant to be "produces the same paper printout for the receiver Y as it does for creator X". That is why, today, in 2018, that viewing a PDF still looks like one is viewing WYSIWYG of a paper printout. PDF is, quite intimately, tied to the concept that there are discrete sheets of paper that it is formatting data onto. Yes some viewers do provide an 'almost' HTML continuous scroll look, but that is done 100% in the viewer, the underlying PDF format is very paper page oriented at its core. So, when comparing PDF intent to web page intent, the phrase "looks the same" has different meanings. For PDF, it was designed such that "looks the same" means that a paper printout looks identical to the original. And that the designer/creator has full control over the look, while the viewer has no control over the look. For web pages, "looks the same" is far less strict, and is really not the same meaning, because the web was always intended to allow the viewer much freedom in deciding how to display the HTML content, taking away the designers ability to strictly determine look and presentation. With the result that HTML data was never meant to "look the same" with the same strictness intended by PDF.
- omaranto 8y ago
  What? Lot's of webpages look different after simply resizing the window! The fact that this is on purpose, doesn't mean it doesn't happen (quite the opposite!).
  - devwastaken 8y ago
    That's because they're designed that way. You can do styling in a way that is not effected by browser window sizing, typically with specified document dimensions, or absolute positioning.
Already__Taken 8y ago
moreso, webpages were never meant to, by design. It is not print media without the print.
fulafel 8y ago
Not with text markup, but you could just use canvas or svg.

ryacko 8y ago

90% of PDFs could be replaced using a background PNG/JPEG file and a visible/invisible text overlay. Instead of forms embedded in the “.phd”, one could just use HTML forms and and then use javaScript to export it as a “.phd” document, covering 99% of PDF use cases.

joshschreuder 8y ago

Isn't that sort of what MHTML is? https://en.wikipedia.org/wiki/MHTML https://en.wikipedia.org/wiki/MHTML I remember saving .mht files with IE as a kid when working on assignments so I could disconnect the dialup and give my parents their phone line back :)

Already__Taken 8y ago
With service workers we're almost a save-as shim away from being back to this.
devwastaken 8y ago
Sort of, but mhtml isn't a good format. It was a hacky way of taking what emails did. It's embedding all content in a single file, not as an archive. Rather it should be you can open up the HTML archive like an actual archive and see the individual files.
- acqq 8y ago
  Opera 12 (the original one, before the managers decided that it should be based on Chromium) had the .zip files support built in; that means that if the URL was somepath/archive.zip/index.html and index.html refers to other files, they would be read from the same zip, even if they are only inside of the zip. I used it a lot for the local archives of the bigger content, it is amazingly convenient, and I'm sad that the same approach was not used anywhere else. It's not trivial to get it right, in the security aspects (the zip implementation has to be robust, the url handling too) but it's doable and it would be very practical to have it. Tangentially, the good thing of the zip format is that it has so called "central directory" which means that you don't even have to load the whole archive if not all data is needed, just the last part of the file, and from there you get the offset and the location of the needed file. So the Zip files could work beautifully with the https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ra... when they are huge(1). The small ones are most effective to be downloaded at once, of course. 1) I've actually done such a sequence by hand a few times when I had a slow internet and knew that I don't need the whole zip file, but just to see that all files are inside: I've made the range request for the end of the file which would be enough for the estimated number of files inside, and so I've had the list of all the files in the archive without needed to download the whole archive: I've reconstructed the same file size but left the rest of it be zeroes, and some of the zip tools I've used treated the archive directory exactly as I needed it.

occamrazor 8y ago

.chm (windows help files format) is almost exactly that. It had its fair share of security vulnerabilities.

jabl 8y ago

IIRC the epub format used for e-books is essentially a container with html.

aidos 8y ago

You can take a PDF and plot it, print it, display it on screen and it will always look the same. SVG is a closer to PDF than html is - and svg gets a lot of grief for having an overly complicated spec too.

deleted 8y ago

[deleted]