15 ms·

> Just no. CM font was made for printing. It was last updated in 1992, before PDF was even a thing. CM is not made for screens and it is a horrible idea to use

> Just no. CM font was made for printing. It was last updated in 1992, before PDF was even a thing. CM is not made for screens and it is a horrible idea to use it on the Web. The same can be said about P.D.F. files. I recently found out why so often when copying from them, spaces are either inserted doubly, or removed: the reason is that the format has no understanding of spaces, only of distance between characters and is completely about præsentation, lacking semantics in any way. When copying, the reader simply applies a heuristic of what distance between characters constitutes a space, and is often wrong.

deleted 5y ago
[deleted]
Mediterraneo10 5y ago
It is not the case that treatment of spaces is completely wild and ad hoc. PDF can, and frequently does, contain the text itself along with the display of said text. This is why applications like pdftotext can often give you correct plaintext output. OCR applications are able to make PDFs from scanned images accessible and searchable (and with the right spaces) precisely because they embed their output into that layer of the PDF meant for the text itself, not its presentation.
- aardvark179 5y ago
  Actually what OCR programs do is a very clever hack. PDF is mostly just a way to describe how to render pages, and just like with any rendering frame work that can involve a bitmap, a set of stroke and fill commands, or some text rendering. A scanned document obviously is just a huge bitmap, but if you can identify the text, and can define a font that doesn’t draw anything, then you can add instructions to the PDF to render that text in that font and as long as you can specify character positions everything will line up nicely. If you are generating a PDF with text you can render a string with spaces and let the glyph layout sort it out, or render individual characters, or draw those characters by hand and use the invisible font trick (because your font is not licensed for embedding). It’s not that you’re using different conceptual layers of the PDF, you’re just choosing how to render your content.
klodolph 5y ago
The format understands spaces just fine. The problem is that programs that produce PDFs are often designed just to make the PDF look correct, without any care for semantics. I think there's just a bunch of history here--print is the use case that you really want PDF to get correct, and so you take existing print pipelines which discard semantics and add PDF as a new backend. This is the easy/lazy way to get PDF working, and there are also tons of PDF pipelines are just stapled onto the end of a print pipeline as if PDF were another type of printer. You'll see a night and day difference between one of those pipelines and something more suited to processing a document with semantics, like FrameMaker. FrameMaker seems to be a bit more niche now that print documentation is less mainstream. I can understand why the PDF ecosystem is a bit frustrating, but I still prefer it when I'm reading academic papers explaining some algorithm or mathematical concept.
- selfhoster11 5y ago
  > The problem is that programs that produce PDFs are often designed just to make the PDF look correct, without any care for semantics. When the alternative is that they don't offer a non-proprietary export format at all, I'll take it. Even a poor PDF output is better for data portability than having your data forever trapped in a proprietary platform that can disappear or get discontinued at any time without a migration path.
selfhoster11 5y ago
PDF is simply the lowest common denominator of what counts as "computerized sheaf of paper, with a layout and appearance that won't shift over time, no matter which reader software you use". It has its value, especially with preservation of pre-digital documents. Accepting a potentially inferior machine-readable plaintext when copy and pasting is the price we pay for having something like that available.

deleted 5y ago

[deleted]

Mediterraneo10 5y ago

It is not the case that treatment of spaces is completely wild and ad hoc. PDF can, and frequently does, contain the text itself along with the display of said text. This is why applications like pdftotext can often give you correct plaintext output. OCR applications are able to make PDFs from scanned images accessible and searchable (and with the right spaces) precisely because they embed their output into that layer of the PDF meant for the text itself, not its presentation.

aardvark179 5y ago
Actually what OCR programs do is a very clever hack. PDF is mostly just a way to describe how to render pages, and just like with any rendering frame work that can involve a bitmap, a set of stroke and fill commands, or some text rendering. A scanned document obviously is just a huge bitmap, but if you can identify the text, and can define a font that doesn’t draw anything, then you can add instructions to the PDF to render that text in that font and as long as you can specify character positions everything will line up nicely. If you are generating a PDF with text you can render a string with spaces and let the glyph layout sort it out, or render individual characters, or draw those characters by hand and use the invisible font trick (because your font is not licensed for embedding). It’s not that you’re using different conceptual layers of the PDF, you’re just choosing how to render your content.

klodolph 5y ago

The format understands spaces just fine. The problem is that programs that produce PDFs are often designed just to make the PDF look correct, without any care for semantics. I think there's just a bunch of history here--print is the use case that you really want PDF to get correct, and so you take existing print pipelines which discard semantics and add PDF as a new backend. This is the easy/lazy way to get PDF working, and there are also tons of PDF pipelines are just stapled onto the end of a print pipeline as if PDF were another type of printer. You'll see a night and day difference between one of those pipelines and something more suited to processing a document with semantics, like FrameMaker. FrameMaker seems to be a bit more niche now that print documentation is less mainstream. I can understand why the PDF ecosystem is a bit frustrating, but I still prefer it when I'm reading academic papers explaining some algorithm or mathematical concept.

selfhoster11 5y ago
> The problem is that programs that produce PDFs are often designed just to make the PDF look correct, without any care for semantics. When the alternative is that they don't offer a non-proprietary export format at all, I'll take it. Even a poor PDF output is better for data portability than having your data forever trapped in a proprietary platform that can disappear or get discontinued at any time without a migration path.

selfhoster11 5y ago

PDF is simply the lowest common denominator of what counts as "computerized sheaf of paper, with a layout and appearance that won't shift over time, no matter which reader software you use". It has its value, especially with preservation of pre-digital documents. Accepting a potentially inferior machine-readable plaintext when copy and pasting is the price we pay for having something like that available.