On Sat, Nov 24, 2012 at 04:49:07PM +0000, Tony's unattended mail wrote: [pre-formatted table excluded] > > Now, read this with a variable WIDTH format, still as plain text. Is it > > aligned properly? It has never been right in any cases I've seen.... > > That's a good example of where the meaning of LFs would be significant > in the stance I'm taking. That is, descriptive text before and after > the table would only use LFs (2 of them) to mark paragraph, with the > rest of the text unwrapped, and there would be LFs at the end of each > row of that table, making it perfectly clear to the client software > that the table should be left untouched (and preferably monospaced), > while the paragraphs before and after would be wrapped to the users > preference.
But how will the client decide what to monospace, and what not to?
There is no discerning factor... in both cases you just have lines of
text which are terminated by a newline. And the monospacing is
*required* for the table, in order to keep it tabular... unless you
can build smarts into your application to recognize the many ways that
people represent tabular plain-text data, and do the formatting for
you. Good luck with that.
Now make your terminal 40 characters wide. Using your methodology,
each of the lines of the table will be split on whatever characters
your client thinks are a word boundary, and wrapped into separate
lines. With fixed-width formatting, one of two things will happen,
depending on what type of client you have:
- The text will wrap at the edge of the terminal, but will run to
the end of the line, so that it is fairly clear the line is
continued (terminal app)
- The line will scroll off the edge of the app, and you will need to
scroll to see it. (GUI app)
In both cases though, it's generally fairly plain to the reader that
the lines are continued past the width of the window. With flowed
formatting, that may or may not be clear, depending on the data itself
and how the author decided to format it. The user may need to decide
for themselves to change the size of the window to see if it formats
better, to be able to tell the difference. In the case of the table
used in this example, that's not likely to be true. But this is not
the only way to represent a table, and not all tables contain data
that are as easily distinguished. What if it were simply a 12x12
matrix of floating point numbers? What if, in that table, some rows
could have fewer than the full 12 items? That would be one hard to
read mess, expecially if the client did not correctly decide to use a
fixed width font to display it.
The bottom line: you absolutely need some form of mark-up to get this
right.
The rest of your message, I pretty well agree with. However:
> I got an Android hoping Google would be worthy of at least providing a
> solid kernel. But it's crap, with spyware to boot. The only hope of
> something spyware-free that works, and gives the user an appropriate
> amount of control is the Meego at this point.
If you're willing/able, try using a custom ROM that just builds
"stock" android, like Cyanogen. If your phone is well supported, I
find that it's very stable (and has no spyware, other than the normal
google stuff). The carriers are largely to blame here.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpJi5nABn8f5.pgp
Description: PGP signature
