Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Sep 1996 11:50:53 -0500 (EST)
From:      John Fieber <jfieber@indiana.edu>
To:        Sean Kelly <kelly@fsl.noaa.gov>
Cc:        darrend@novell.com, doc@FreeBSD.org
Subject:   Re: What tool to use to generate SGML?  - Reply
Message-ID:  <Pine.BSI.3.95.960920111601.28904M-100000@fallout.campusview.indiana.edu>
In-Reply-To: <199609201502.PAA14743@gatekeeper.fsl.noaa.gov>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 20 Sep 1996, Sean Kelly wrote:

> >>>>> Darren Davis <darrend@novell.com> writes:
> 
> > but was hoping for something a little more like a freeware Frame.
> 
> Frame?  You mean WYSIWYG?  Isn't that against the whole point of
> SGML---separation of content from formatting?

Yes and no.  Generally speaking, WYSIWYG SGML is an oxymoron.
However, there are certainly situations where some approximation
of an output format can be useful.  Something like how
WordPerfect works with a main editing window and a "reveal codes"
window.  Your SGML tags would appear in the "reveal codes" window
if you wanted to see them, and the top display would be driven by
a fairly simple tag->rendinging table (eg "<heading> == [Bold]").
For DTDs such as linuxdoc that are clearly targeted at paper
documentation, this approach would work quite well.  Of course,
you would have to create the mapping for the DTD, but you only
have to do it once per DTD.

The purpose is not necessarly a literal reperesentation of the
final product, but an approximation to make editing easier.
There are good reasons that headings are formatted differently
than running text in printed document: they make identifying the
document structure and reading easier.  Why should this benefit
be extended only to the reader and not the author?

The fundamantal problem I see is that it could make the rather
large mental jump from presentation markup to content markup even
harder.  This is my main beef with HTML editors like Navigator
Gold.  On the one hand, real-time rendering in the editor makes
editing a joy, but I'm irked to no end by how they invariably
hide HTML's descriptive markup behind a procedural markup mask.
Progress goes splat.  (The rotting tag salad that Navigator Gold
and other editors generate is yet another issue). 

I've been incubating ideas for a WYSIWYN (What You See is What
You Need) editor for structured documents (like SGML).  WYSIWYG
is good for formatting tasks, but given the large difference
between screen and print quality, it is counterproductive for
editing content.  Unfortunately, the only choice for people who
don't buy into WYSIWYG for editing is to return to text editors
that are still basically the same as they were when screen
editing was born.  Instead, we need to go the other way, beyond
WYSIWYG.  The first evidence of this is programming editors that
are "language smart" and can highlight and manipulate grammatical
units in whatever language (C, Perl, etc.).  I want to expand
this WYSIWYN notion to broader editing tasks and SGML editing
seems an ideal target.  (There is also the problem of figuring
out how to formulate this into a problem I could use for my
dissertation...)

-john

== jfieber@indiana.edu ===========================================
== http://fallout.campusview.indiana.edu/~jfieber ================




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSI.3.95.960920111601.28904M-100000>