Re: [tlug] The Great Mistake is thinking OOo is different [was: Why Vista Sucks]

["Stephen J. Turnbull" <stephen@example.com>]

SL Baur writes:

 > He's put his professor's hat on and you missed the point.  In the olden days,
 > students had to rehandwrite stuff they found to plagiarize their homework.
 > Nowadays, they just cut & paste web pages they've found (and the instructor
 > can google the text to see where it came from when he gets suspicious of
 > the origin and that's what he's talking about here).

Actually, no, that's not what I'm talking about.  Sure, that is a
problem in some sense, but it's between me and the student.  I've had
to deal with it on several occasions, including being threatened with
a slander action by a frat brat with far more money than brains.  It's
not routine (thank god), but it's definitely covered in great detail
in the faculty handbook.  And, after all, reuse is what open source is
all about -- I'd hardly be consistent if I was complaining about
illegitimate copy-paste that has gone on for ages, and was merely
facilitated by the Internet.

No, I really do mean to take aim at the whole idea of a wordprocessor
as implemented in everything from Wordstar to OOo (and HTML email, for
that matter).  From the point of view of an educator, what I really
want for my students is a pure text editor, a text/* format with a
very few features for indicating content structure (sectioning and
list and table environments) and a few for visual structure[1]
(specifically floats for footnotes, tables, and graphics), a
previewer, and a final hardcopy generator (which might be PDF as well
as paper).  As I've mentioned elsewhere, bonus points for a realtime
previewer.  Interestingly enough, these are basically the same
requirements that Travis mentions as being those of the typical user
not interested in the minutiae of document preparation.

Now, there are a plethora of packages that demonstrate that this can
be implemented in a text/* format.  They can and do generate quite
attractive HTML output with very little CSS, and this could be tweaked
to improve it substantially IMO.  Typically the HTML itself is quite
readable.  The LaTeX output produced by engines such as reST or
html2latex is visually attractive when processed through LaTeX, but to
be honest, I'd call it "binary sludge" as a file format.  It's neither
human readable nor pleasant to munge with a program.

[[Note that it is fair to call LaTeX or HTML a binary format.  Sure,
you can write text-oriented versions of TeX (eg, Omega/Lambda) or HTML
processors (and XML is a text standard because it mandates identifying
the encoding for communication while internal processing is specified
in terms of a text stream), but in fact almost all implementations do
depend on the ASCII values of macros (for TeX) or tags (for HTML).]]

The main point is that these text-processing systems communicate via
text streams, and thus leave choice of presentation system up to the
reader.  A crucial supporting point is that the defaults for these
systems gives quite reasonable results *from the author's POV*
although that is not really a design criterion at all!  It simply
follows from the fact that authors and readers alike are derivatives
of monkey stock, and so have all those monkey preferences in common.

What wordprocessors, and file formats like ODF that are designed to
support them, do is quite different.  They of necessity bundle the
presentation with the content, because the intent is to let *the
author* specify the presentation.  This is *wrong* for almost all
office applications (which is broad enough to include education).
People work on presentation of things they author mostly for ego
reasons, not to make them more intelligible to the reader/listener/
viewer.  It's almost always better to let the receiver choose
presentation mode.  This wouldn't be bad if it were just a bundle, but
AFAIK it's not.  The presentation markup gets mixed in with the
content structure markup, because of the need to provide author
control.

Now, I don't really care if ODF *could* be used sanely, and actually
separate the content out in a text/* form.  As long as any attempt to
save in a non-our-favorite-binary-sludge-format pops up that dastardly
"you may lose some formatting" evil propaganda^W^Wdialog, the intent
is clear.  "Keep your chocolate-eating fingers off my pretty pink
formats, you!"  It will *not* be used sanely by any of the "minimal
needs" users, because they simply don't know enough to realize it's
safe to be sane.  This means that it will be hopeless to try to teach
them to use grep or sed, because there simply are no applications that
justify that kind of investment on their part.  Not only are the
documents that they produce not amenable to command-line processing
using standard utilities, but none of the documents they receive are,
either.

By the way, the resume example is grossly wrong for this context.
Point the First: A resume is an appropriate application for WYSIWYG.
Taking control of presentation of the resume away from the candidate
is like asking him to show up for the interview naked, to be dressed
by the interviewer's assistant.  Point the Second: There is a correct
algorithm for handling candidates who send you letter-size resumes in
an A4 world:

    1.  Subtract N points for being so self-centered.
    2.  Save as PDF.
    3.  Print at scale 96% (IIRC), recentered.
    4.  If this results in any additional unreadability, subtract M
        more points.

N and M are an employer-specific parameters, of course.

Footnotes: 
[1]  The visual structure required for math is a hard problem, and I
don't know how to fit it into this discussion.  But it's a moot point:
even today I don't think there are any word processors that come close
to TeX, despite the fact that TeX's algorithms are public domain and
the code is open source.