6 ms·

Or, please do? I use PDF's so I can send them to my iPad to read offline, highlight them, annotate them, and then send them back to my filesystem with highligh

Or, please do? I use PDF's so I can send them to my iPad to read offline, highlight them, annotate them, and then send them back to my filesystem with highlights and annotations intact. I sure can't do that with any "nice formats" like HTML or TXT or EPUB or MOBI.

mr_mitm 1y ago
You could, though. What you are describing are features of an editor, not a file format. I can imagine a browser addon performing the same tasks.
- deleted 1y ago
  [deleted]
- whenc 1y ago
  PDF annotations sit within the file.
  - mr_mitm 1y ago
    I know, even though that depends on the editor. Okular for example places them in an extra file, last I checked. That's not unique to PDFs. HTML files are modifiable. There is nothing preventing an editor to put annotations in it as well.
    - crazygringo 1y ago
      PDF is designed for annotations in the file format. You annotate in one editor, you can change the annotations in another. You can always distinguish between original content and annotations. I see no indication that Okular stores highlights or annotations in a separate file, that would be bizarre. There is no mechanism for annotations in HTML or the other formats I listed. An editor would just be editing the original content in its own non-standardized, non-portable way, which is not desirable for a number of reasons. So when you say: > What you are describing are features of an editor, not a file format. That is incorrect. It is an intentionally designed and standardized feature of the file format.
      - mr_mitm 1y ago
        It definitely used to be bizarre then: https://superuser.com/questions/333378/where-does-okular-store-the-pdf-annotations/333520#333520 https://superuser.com/questions/333378/where-does-okular-sto...
        ratelimitsteve 1y ago
        turns out the default for okular is to save to an external file but there's a setting that can be changed to use the format correctly and store annotations within the file, which is universally compatible with other PDF readers. You can't really blame the format for someone using it wrong on purpose, and if you can then I'll just abuse HTML and the fact that I use it wrong will be evidence that it is, in itself, wrong
      - cxr 1y ago
        The W3C standardized HTML annotations years ago. There's a difference between a standard not existing versus people pretending it doesn't exist because it's not implemented by Chrome.
        crazygringo 1y ago
        That's different. Those are a data structure defining annotations that are meant to be stored externally. They're not part of an HTML file like PDF annotations are. They're meant more for live collaborative commenting within a shared online space, not for making private portable annotations like PDF does. And it's not a Chrome thing. I don't think any browsers support it, do they? It's not really clear there's a need for it, when collaborative editors already handle document annotations in their own ways.
        cxr 1y ago
        So is there a need for it or isn't there? > That's different. Those are a data structure defining annotations that are meant to be stored externally. The protocol is a separate standard. The format is JSON-LD. Putting JSON-LD into HTML isn't a question mark. (There's info at W3C.org about how to do that, too. Not that it's necessary. You can guess what it says.)
- circuit10 1y ago
  But in this case the flexibility of HTML is a negative because any layout shift would mess up the positions of the annotations, so fixing the layout (and making sure it’s non-interactive) is helpful here
nine_k 1y ago
PDF is literally digital paper. HTML has logical structure, it can adapt to different displays, etc. Sometimes you want one, sometimes, the other.
- ratelimitsteve 1y ago
  >Sometimes you want one, sometimes, the other. This is the part that the top commenter missed. Instead they decided that one format is "nice" and the other, by implication, isn't. I find PDFs a lot easier to keep organized en masse, I like that I can use them on any of my devices and it's easy for me to use them when I'm doing in-depth reading such as an ebook. Doubly so because my ereader also does text to speech and syncs across devices so I can read on my tablet while I'm on the exercise bike and then switch to listening to the same book on my phone with minimal seams and without losing my place. It is, in a word, nice.
  - Aachen 1y ago
    None of that sounds related to the format? - A text to speech engine should work better with the original html structure where it sees bold tags, headings, and full sentences ra- ther than broken-off ones - Keeping PDFs organised, how would that differ from keeping any other filetype organised? I don't understand what difference you, "by implication", attribute to a file ending in .html or .pdf for being able to handle them en masse. If anything, searching across them will be vastly easier for software (self-written or third-party) and more reliable because it's all plain text - Text and audio rendering syncing, I have no experience with but that doesn't sound like it ought to fundamentally work for a display format and not for the source text format. Of course, the software has to have support for this format (and otherwise it's trivial to pdfify a html but vice versa is nearly impossible)
    - user3939382 1y ago
      HTML could do everything PDF does in theory but it doesn’t in practice because the tooling doesn’t exist.

mr_mitm 1y ago

You could, though. What you are describing are features of an editor, not a file format. I can imagine a browser addon performing the same tasks.

deleted 1y ago
[deleted]
whenc 1y ago
PDF annotations sit within the file.
- mr_mitm 1y ago
  I know, even though that depends on the editor. Okular for example places them in an extra file, last I checked. That's not unique to PDFs. HTML files are modifiable. There is nothing preventing an editor to put annotations in it as well.
  - crazygringo 1y ago
    PDF is designed for annotations in the file format. You annotate in one editor, you can change the annotations in another. You can always distinguish between original content and annotations. I see no indication that Okular stores highlights or annotations in a separate file, that would be bizarre. There is no mechanism for annotations in HTML or the other formats I listed. An editor would just be editing the original content in its own non-standardized, non-portable way, which is not desirable for a number of reasons. So when you say: > What you are describing are features of an editor, not a file format. That is incorrect. It is an intentionally designed and standardized feature of the file format.
    - mr_mitm 1y ago
      It definitely used to be bizarre then: https://superuser.com/questions/333378/where-does-okular-store-the-pdf-annotations/333520#333520 https://superuser.com/questions/333378/where-does-okular-sto...
      - ratelimitsteve 1y ago
        turns out the default for okular is to save to an external file but there's a setting that can be changed to use the format correctly and store annotations within the file, which is universally compatible with other PDF readers. You can't really blame the format for someone using it wrong on purpose, and if you can then I'll just abuse HTML and the fact that I use it wrong will be evidence that it is, in itself, wrong
    - cxr 1y ago
      The W3C standardized HTML annotations years ago. There's a difference between a standard not existing versus people pretending it doesn't exist because it's not implemented by Chrome.
      - crazygringo 1y ago
        That's different. Those are a data structure defining annotations that are meant to be stored externally. They're not part of an HTML file like PDF annotations are. They're meant more for live collaborative commenting within a shared online space, not for making private portable annotations like PDF does. And it's not a Chrome thing. I don't think any browsers support it, do they? It's not really clear there's a need for it, when collaborative editors already handle document annotations in their own ways.
        cxr 1y ago
        So is there a need for it or isn't there? > That's different. Those are a data structure defining annotations that are meant to be stored externally. The protocol is a separate standard. The format is JSON-LD. Putting JSON-LD into HTML isn't a question mark. (There's info at W3C.org about how to do that, too. Not that it's necessary. You can guess what it says.)
circuit10 1y ago
But in this case the flexibility of HTML is a negative because any layout shift would mess up the positions of the annotations, so fixing the layout (and making sure it’s non-interactive) is helpful here

nine_k 1y ago

PDF is literally digital paper. HTML has logical structure, it can adapt to different displays, etc. Sometimes you want one, sometimes, the other.

ratelimitsteve 1y ago
>Sometimes you want one, sometimes, the other. This is the part that the top commenter missed. Instead they decided that one format is "nice" and the other, by implication, isn't. I find PDFs a lot easier to keep organized en masse, I like that I can use them on any of my devices and it's easy for me to use them when I'm doing in-depth reading such as an ebook. Doubly so because my ereader also does text to speech and syncs across devices so I can read on my tablet while I'm on the exercise bike and then switch to listening to the same book on my phone with minimal seams and without losing my place. It is, in a word, nice.
- Aachen 1y ago
  None of that sounds related to the format? - A text to speech engine should work better with the original html structure where it sees bold tags, headings, and full sentences ra- ther than broken-off ones - Keeping PDFs organised, how would that differ from keeping any other filetype organised? I don't understand what difference you, "by implication", attribute to a file ending in .html or .pdf for being able to handle them en masse. If anything, searching across them will be vastly easier for software (self-written or third-party) and more reliable because it's all plain text - Text and audio rendering syncing, I have no experience with but that doesn't sound like it ought to fundamentally work for a display format and not for the source text format. Of course, the software has to have support for this format (and otherwise it's trivial to pdfify a html but vice versa is nearly impossible)
  - user3939382 1y ago
    HTML could do everything PDF does in theory but it doesn’t in practice because the tooling doesn’t exist.