3 ms·

I have the opposite experience. To me, opening a PDF puts me on edge. My computer is likely to slow to a crawl. It never renders correctly - sometimes it will s

I have the opposite experience. To me, opening a PDF puts me on edge. My computer is likely to slow to a crawl. It never renders correctly - sometimes it will slowly render each page, one at a time, flashing the screen as it goes. Or maybe the PDF is using some features that my reader doesn't support so it renders incomplete and incorrectly. Links are often hard to pick out. What is a link and what isn't? What happens when I click on something, is it going to stay in the PDF or open a browser or something? Don't get me started on moving around in PDFs. There are always 2 sets of page numbers, one for the PDF and one of the document. Extremely confusing. Searching. Ugh, searching a PDF is a nightmare I don't want to even think about right now. Ctrl+F is broken 99% of the time. Or at least, that's my experience over the last 20 years. Sure, it's gotten better recently, but, not enough to make my mind 'at ease' exactly. Very stressful to open a PDF still, usually.

chmod775 6y ago
> To me, opening a PDF puts me on edge. My computer is likely to slow to a crawl. It never renders correctly - sometimes it will slowly render each page, one at a time, flashing the screen as it goes. That probably isn't the fault of the PDF, but the PDF reader you're using. > Searching. Ugh, searching a PDF is a nightmare I don't want to even think about right now. Ctrl+F is broken 99% of the time. Now this is actually the fault of PDF and how it does positioning of stuff within it - but about 50% of the blame lies with whichever software generated a shit PDF.
- LordDragonfang 6y ago
  >Now this is actually the fault of PDF and how it does positioning of stuff within it - but about 50% of the blame lies with whichever software generated a shit PDF. Arguably, it's still the fault of the horribly overcomplicated pdf spec -- html manages to do it just fine, with a plain text format, to boot
  - kaba0 6y ago
    Well, it’s an interesting competition, but I believe HTML(+CSS to be fair) would win the complexity of the spec price hands down.
  - cycomanic 6y ago
    Shoe me the html document where I can search through a 60 page text. That's actually the thing. Html is fine if you only read text that would be maximal 2 pages on print. But if you read longer documents you want pagination which destroys the ability to search (unless the author implements a separate search or you use Google)
    - LordDragonfang 6y ago
      >Shoe me the html document where I can search through a 60 page text. epub. >An EPUB file is an archive that contains, in effect, a website. It includes HTML files, images, CSS style sheets, and other assets. Search works just fine on ereaders. The flexibility of html is that you can render it however you want, for whatever viewport or feature. If you want pagination, just render it differently. >But if you read longer documents you want pagination For long form works, I do actually prefer having them on my kindle, but that's because I don't want to read long-form text by staring at a screen, and I want a lower line width. PDFs tend to be worst case scenario there, because they often render with the assumption that you're trying to read it on standard letter paper. Also, we've had "pagination" for text files for decades. It's called "less".
- ericbarrett 6y ago
  > That probably isn't the fault of the PDF, but the PDF reader you're using. Completely agree. Try something that isn't Adobe Reader!
diarrhea 6y ago
> Don't get me started on moving around in PDFs. There are always 2 sets of page numbers, one for the PDF and one of the document. Extremely confusing. It's only a tiny subset of all PDFs in circulation, but the LaTeX PDFs I produce using appropriate settings (mainly KOMAScript class) always nail this. The current page number always corresponds to what is printed in the PDF. This can be alphanumerical (e.g. page "a" / 300, where 300 is the total number of all pages) or roman, for the frontmatter. The PDF viewer will then literally show e.g. "Page XII / 300". So in that sense, it's in the hands of the party producing the PDF to get this right, not an inherent limitation in the standard. But now, new problems arise. If you're on the printed page XII but your viewer displays "Page 22 / 300", you know where you are in total. "Page XII / 300" is "correcter" but can be anything. > Searching. Ugh, searching a PDF is a nightmare I don't want to even think about right now. Ctrl+F is broken 99% of the time. Don't share this experience. It's a the same level as in browsers, where CTRL+F is also quite limited (I'd give a kidney to have regex available everywhere---ripgrep-all gets close on the desktop). The only different thing in PDFs is if hyphenation occurs, which is arguably less common in browsers (simply because of poorer typographical standards/people care more in proper PDFs). Your search term will indeed be invisible to CTRL+F. The only other time it breaks down in PDFs if the PDF is corrupt/poorly produced/bad OCR.
- necovek 6y ago
  PDFs can be produced by mapping completely unrelated characters to glyphs that appear as actual characters (basically, they'd embed a "compacted" font that only has the glyphs required for the document, and then map them to ASCII or something). This was quite common with pdftex documents not using ASCII characters in the past, thus making text unsearchable (and even more so when going the ps2pdf route). For example, you'd have a Cyrillic document in which when you selected text in, highlighted text would be some jumbled ASCII characters. The fact is that PDF can display one thing and have underlying semantic text be something else entirely (frequently used for OCRing: you show actual scanned images of text, and put the invisible OCRed text as searchable ). It works in the other direction too: you could solve the hyphenation problem in the same way by having PDF include invisible non-hyphenated word in place of the hyphenated one for searching. Still, PDF is mostly a laying-out format, and while tools have evolved to provide some "meaning" to rendered content, it is never going to be semantic in the sense markup languages can be (i.e. there is no "emphasis", "quote" or "header" command for PDF, instead, it just uses a different font). To put things into perspective, TeX files can be semantic (if a semantic TeX .fmt like LaTeX is used) like HTML/ePub, but PDF is an output format, just like DVI is.

chmod775 6y ago

> To me, opening a PDF puts me on edge. My computer is likely to slow to a crawl. It never renders correctly - sometimes it will slowly render each page, one at a time, flashing the screen as it goes. That probably isn't the fault of the PDF, but the PDF reader you're using. > Searching. Ugh, searching a PDF is a nightmare I don't want to even think about right now. Ctrl+F is broken 99% of the time. Now this is actually the fault of PDF and how it does positioning of stuff within it - but about 50% of the blame lies with whichever software generated a shit PDF.

LordDragonfang 6y ago
>Now this is actually the fault of PDF and how it does positioning of stuff within it - but about 50% of the blame lies with whichever software generated a shit PDF. Arguably, it's still the fault of the horribly overcomplicated pdf spec -- html manages to do it just fine, with a plain text format, to boot
- kaba0 6y ago
  Well, it’s an interesting competition, but I believe HTML(+CSS to be fair) would win the complexity of the spec price hands down.
- cycomanic 6y ago
  Shoe me the html document where I can search through a 60 page text. That's actually the thing. Html is fine if you only read text that would be maximal 2 pages on print. But if you read longer documents you want pagination which destroys the ability to search (unless the author implements a separate search or you use Google)
  - LordDragonfang 6y ago
    >Shoe me the html document where I can search through a 60 page text. epub. >An EPUB file is an archive that contains, in effect, a website. It includes HTML files, images, CSS style sheets, and other assets. Search works just fine on ereaders. The flexibility of html is that you can render it however you want, for whatever viewport or feature. If you want pagination, just render it differently. >But if you read longer documents you want pagination For long form works, I do actually prefer having them on my kindle, but that's because I don't want to read long-form text by staring at a screen, and I want a lower line width. PDFs tend to be worst case scenario there, because they often render with the assumption that you're trying to read it on standard letter paper. Also, we've had "pagination" for text files for decades. It's called "less".
ericbarrett 6y ago
> That probably isn't the fault of the PDF, but the PDF reader you're using. Completely agree. Try something that isn't Adobe Reader!

diarrhea 6y ago

> Don't get me started on moving around in PDFs. There are always 2 sets of page numbers, one for the PDF and one of the document. Extremely confusing. It's only a tiny subset of all PDFs in circulation, but the LaTeX PDFs I produce using appropriate settings (mainly KOMAScript class) always nail this. The current page number always corresponds to what is printed in the PDF. This can be alphanumerical (e.g. page "a" / 300, where 300 is the total number of all pages) or roman, for the frontmatter. The PDF viewer will then literally show e.g. "Page XII / 300". So in that sense, it's in the hands of the party producing the PDF to get this right, not an inherent limitation in the standard. But now, new problems arise. If you're on the printed page XII but your viewer displays "Page 22 / 300", you know where you are in total. "Page XII / 300" is "correcter" but can be anything. > Searching. Ugh, searching a PDF is a nightmare I don't want to even think about right now. Ctrl+F is broken 99% of the time. Don't share this experience. It's a the same level as in browsers, where CTRL+F is also quite limited (I'd give a kidney to have regex available everywhere---ripgrep-all gets close on the desktop). The only different thing in PDFs is if hyphenation occurs, which is arguably less common in browsers (simply because of poorer typographical standards/people care more in proper PDFs). Your search term will indeed be invisible to CTRL+F. The only other time it breaks down in PDFs if the PDF is corrupt/poorly produced/bad OCR.

necovek 6y ago
PDFs can be produced by mapping completely unrelated characters to glyphs that appear as actual characters (basically, they'd embed a "compacted" font that only has the glyphs required for the document, and then map them to ASCII or something). This was quite common with pdftex documents not using ASCII characters in the past, thus making text unsearchable (and even more so when going the ps2pdf route). For example, you'd have a Cyrillic document in which when you selected text in, highlighted text would be some jumbled ASCII characters. The fact is that PDF can display one thing and have underlying semantic text be something else entirely (frequently used for OCRing: you show actual scanned images of text, and put the invisible OCRed text as searchable ). It works in the other direction too: you could solve the hyphenation problem in the same way by having PDF include invisible non-hyphenated word in place of the hyphenated one for searching. Still, PDF is mostly a laying-out format, and while tools have evolved to provide some "meaning" to rendered content, it is never going to be semantic in the sense markup languages can be (i.e. there is no "emphasis", "quote" or "header" command for PDF, instead, it just uses a different font). To put things into perspective, TeX files can be semantic (if a semantic TeX .fmt like LaTeX is used) like HTML/ePub, but PDF is an output format, just like DVI is.