Live data from Hacker News

The Art of Plain Text (2015)

netmeister.org

81–88 of 88 posts

Re: The Art of Plain Text (2015)

#81
post #67

Author is NetBSD developer. It is still favourite OS of mine when it comes to command line, text-only computer use. No one ever seems to acknowledge that plain text is the easiest to convert to any other format, while that is generally not the case for other formats. Maybe this is what is meant by "lowest common denominator". Perhaps a term like "most interchangeable format" would put plain text in a better light.

> easiest to convert to any other format I heard that a lot, but I feel like there are some very narrow assumptions involved. Could you give me some examples so I can better understand what people even mean by that? I am not even sure which other formats people think about in that context.

The most common cases I run into are:

PDF by a mile. Copy / paste is usually an option, but not always. Sometimes I see embedded font tricks to prevent this. The copy goes well, but the paste is garbage due to the glyphs being indexed differently in the embedded font. For anything more than a trivial copy paste, the pasted text will include various extras that require some additional massage before the whole thing could be considered plain text.

Text contained in images. Early in computing I had a neighbor who would use low bit depth bitmaps to communicate with their family living in Asia. That solved all the common encoding problems from that time nicely. Thought it was clever.

These days, scanned documents and or people using images for more control over presentation are two common sources for plain text that just isn't.

For that matter, text on paper comes up a lot too. One has to run a program on it to recognize the text optically, or just type it in again.

These cases generally happen on a GUI too. Command line may be possible, but considerable skill and experience are required to make it happen without also investing more time and effort than the task seems worth.

All that said, my two preferred "general purpose" formats are plain text, like we are using here, and simple bitmap images.

Markdown is a format that can transport via plain text and that's great, but can get in the way depending. Same goes for CSV and the like. Normally, those are high value however. It all more or less survives a trip through, say Notepad or vi.

Same goes for the bitmaps making it through something like paint and it all being useful and displayable in a human readable form on most devices.

The moment it ends up in some application, the use value in that context may go way up because more things can be done and or done more quickly. The requirement for other parties to have the same software can and often does end up being a reason to render whatever it is into these two things.

For me, it boils down to whether it's read only, reference material, or if there is a need to extract parts of it, or process any of it in some fashion.

Re: The Art of Plain Text (2015)

#82
post #29

Earlier quoted context omitted.

It's not bad, but I prefer netmeister's. > Wrapping everything in a pre block isn't necessary. I'm not saying it has to be all or nothing... but I don't see the point in not wrapping in a pre block or equivalent, having a mix is fine, i.e using an anchor or some and tags if you want sure, but if you are going to insert a bunch of LFs in there anyway for your column width, why not also use them for paragraphs separati…

You can use without cluttering. Put on its own line and at a different indentation level. I saw someone do this recently, and the plain HTML read just as well as any plaintext doc I ever saw while also rendering perfectly on the phone (which this article doesn’t do thanks to its use of pre).

what exactly is happening on phones with pre?

Re: The Art of Plain Text (2015)

#83

>Use only plain ASCII text. You don't know how the text will be processed or what systems will be used to display it. The lowest common denominator -- i.e. ASCII -- will do just fine. Use a simple text editor. What if I speak Chinese?

The way I interpreted it was, “if ASCII will suffice, then use that.” In other words, use --- instead of —, " instead of “/”, and so forth. If you’re writing in a different language then obviously (at least to me) this advice doesn’t apply.

Re: The Art of Plain Text (2015)

#84
post #81
post #67

Earlier quoted context omitted.

> easiest to convert to any other format I heard that a lot, but I feel like there are some very narrow assumptions involved. Could you give me some examples so I can better understand what people even mean by that? I am not even sure which other formats people think about in that context.

The most common cases I run into are: PDF by a mile. Copy / paste is usually an option, but not always. Sometimes I see embedded font tricks to prevent this. The copy goes well, but the paste is garbage due to the glyphs being indexed differently in the embedded font. For anything more than a trivial copy paste, the pasted text will include various extras that require some additional massage before the whole thing co…

Thank you, those are good examples to put the expression in context!

I personally like well structured data over plain text, but plain text is preferable over extracting information from a pdf.

Re: The Art of Plain Text (2015)

#85
post #84
post #81

Earlier quoted context omitted.

The most common cases I run into are: PDF by a mile. Copy / paste is usually an option, but not always. Sometimes I see embedded font tricks to prevent this. The copy goes well, but the paste is garbage due to the glyphs being indexed differently in the embedded font. For anything more than a trivial copy paste, the pasted text will include various extras that require some additional massage before the whole thing co…

Thank you, those are good examples to put the expression in context! I personally like well structured data over plain text, but plain text is preferable over extracting information from a pdf.

Yes, having structure is good for me too. I did not make that clear.

Re: The Art of Plain Text (2015)

#86
post #56

Earlier quoted context omitted.

It's because the article isn't plain text; it's pre-formatted text. Real plain text is great because your browser can re-flow it. Here the author has added hard linebreaks to disable this useful feature. I can't think of any good reason to do this.

Counterpoint from Linus Torvalds regarding wrapping text for git commit messages: [0] > Word-wrapping is a property of the text . And the tool you use to visualize things cannot know. End result: you do word-wrapping at the only stage where you can do it, namely when writing it. Not when showing it. > Some things should not be word-wrapped. They may be some kind of quoted text - long compiler error messages, oops rep…

>They may be some kind of quoted text - long compiler error messages, oops reports, whatever. Things that have a certain specific format.

In the contexts where it matters, the display software can mark each linebreak it inserts with a special symbol that's not found in plain text (possible even in terminal apps, e.g. by using inverted color) to indicate it wasn't found in the original text. Unlike pre-formatting text, this does not lose information.

Re: The Art of Plain Text (2015)

#87
post #86

Earlier quoted context omitted.

Counterpoint from Linus Torvalds regarding wrapping text for git commit messages: [0] > Word-wrapping is a property of the text . And the tool you use to visualize things cannot know. End result: you do word-wrapping at the only stage where you can do it, namely when writing it. Not when showing it. > Some things should not be word-wrapped. They may be some kind of quoted text - long compiler error messages, oops rep…

>They may be some kind of quoted text - long compiler error messages, oops reports, whatever. Things that have a certain specific format. In the contexts where it matters, the display software can mark each linebreak it inserts with a special symbol that's not found in plain text (possible even in terminal apps, e.g. by using inverted color) to indicate it wasn't found in the original text. Unlike pre-formatting text…

What you've described isn't plain text.

Re: The Art of Plain Text (2015)

#88
post #86

Earlier quoted context omitted.

>They may be some kind of quoted text - long compiler error messages, oops reports, whatever. Things that have a certain specific format. In the contexts where it matters, the display software can mark each linebreak it inserts with a special symbol that's not found in plain text (possible even in terminal apps, e.g. by using inverted color) to indicate it wasn't found in the original text. Unlike pre-formatting text…

What you've described isn't plain text.

It's a method of displaying plain text that distinguishes between original linebreaks and linebreaks inserted by the display software. The text itself is 100% plain.
Post reply on HN