Frank da Cruz wrote:
>
> > Why are you specifying font characteristics for plain text?
> >
> Only for purposes of getting across the idea that "long line = paragraph,
> break where you please" should not be considered well-formed plain text.
> Or, to look at it the other way, that plain text must allow for hard line
> breaks, and there should be a convention as to how long we might reasonably
> expect lines to be. "Columns" are the only measurement that makes sense
> (surely not picas, inches, millimeters, pixels, ...) and this presupposes
> fixed spacing.
See below for comments on maximum line length. When considering why other
measurements were inappropriate I realized it is because "preformatted"
plain text has no control over font size and thus cannot do position
based formatting as someone would do on a sheet of paper. The cell
model allows people to position text without recourse to a markup system
but at the sacrafice of which scripts can be properly rendered. It
happens that many of the commercially significant languages can cope
with the cell model which is part of the reason it has survived so long.
Unfortunately it just helps keep the hard writing systems in the ghetto
because it isn't nearly as profitable and requires dealing with many
cans of worms when trying to fit them to a system that depends on
implicit positioning.
> The fact that monospaced fonts have fallen out of fashion should not cloud
> our judgement. Naturally they present some difficulties for multilingual
> text, but they also provide numerous benefits. They let me compose a text
> document that anybody can read in -- barring "rendering engine" interference
> -- the same form in which I composed it. Tables line up, columns of numbers
> add up, comments in my C program are aligned, etc. All this without our
> having to agree in advance on which rendering engine or markup language to
> use.
Presumably the markup language specifies the semantics well enough to be
rendering engine independent - if the rendering engine is capable of
displaying the text as described. For text that is being sent without
any markup, then monospace for the bulk of the text is probably what
the reader should use (at least if they believe the text to have
horizontal structure.) I just don't think that it should be enforced.
As for the concerns about the ephemeral nature of markup languages,
hopefully we will someday reach some stability for systems that
don't require a proprietary encoder, do not require extensive
computer training to grok and do not have flavour of the week
problems. These difficulties are not inherent in the design of
markup languages but an artifact of the political and economic
forces driving them.
> You might be right about specifying a maximum line length. And yet,
> if there is to be such a thing as preformatted plain text, and none of us
> can deny that there already is such a thing since this is how we commicate,
> should there not be some form of guideline as to what is a safe default
> line-length, in the absence of any prior agreement to set a different one?
> That's what we do now, implicitly. Why not make it explicit? So how should
> the guideline be expressed?
Because if it is made explicit, software writers will feel free to take
such a limit as a hard one and do silly things for text that exceeds it.
Right now most software will handle long lines albeit sometimes awkwardly.
If someone preformats their text for 200 columns, then that is what they
should get if the output device can cope. If it cannot, they need to
consider why they think it has to be 200 columns. In the case of Usenet
and public mailing lists people have to curtail their lines if they don't
want them mangled.
> Let's assume you are composing some plain text, and you don't care how it's
> rendered. Then don't include Line Separators and let the viewer "flow" the
> text. That's fine for ordinary prose, but it assumes a viewer that knows
> how to flow text, and I'm not sure that a text-flowing viewer should be
> assumed or required. As somebody mentioned earlier, most printers will
> truncate long lines, as will many terminals and other display devices.
>
> If you do care how the text is rendered, include Line Separators.
I agree with this.
Geoffrey
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:20:48 EDT