Slashdot Mirror
GNU TeXmacs and Structured Text Editing
Joris van der Hoeven writes "It is a common belief that structured texts are best conceived using ASCII-based text editors like Emacs or VI. It is true that word processors like MS-Word have done a bad job on this issue. But does this mean that wysiwyg structured text editing would be impossible? We firmly believe the contrary and
argue
that such editors are both technically conceivable and desirable. Judge for yourself by taking a look at the GNU TeXmacs
program, whose version 1.0 has just been released."
It suffers from the same ailment (although far less so) as HTML; The layout is intimately linked with the content. As long as font size information, background color, text alignment, etc. are part of the document and mixed with section, paragraph, bibliography, etc. there will be trouble.
This is precisely why things like DocBook came into being. It contains absolutely no layout information. It is all about structured content. Layout is handled later by a separate processor. This does not necessarily mean that input must be so sterile. In fact, I believe that a WYSIWYG DocBook editor would be a godsend in providing a "way out" for all of those Word authors but still applying content structure. Perhaps a variation on the Mozilla Composer concept?
And for those who will let go of their emacs when you pry it from their cold, dead fingers, there is at least one XML editor that takes DTDs for input to aid in tag creation and allows for hooks into XSLT processors for "pretty" previews. It called XAE (XML Authoring Environment for Emacs).
- I don't need to go outside, my CRT tan'll do me just fine.
I found LyX and excellent way to start using LaTeX.
I'd be interested in people's comments who have used both.
Separation of a document's structure and layout is fine in theory, but I always find it difficult in practice.
If you're writing mostly text with even a few graphics images or equations, that model will stand up pretty well.
Where it begins to break down for me, anyway, is where your "document" moves into the realm of a choreographed presentation.
I've seen TeX styles for producing slides, but again, they don't give one direct control over page breaks, etc, particularly if you're adhering to the rigour of "structure must be separate from content".
So much of what I try to convey in a presentation depends almost as much on coordinated details of layout design as it does on what could fit into structured content. I want both SVG plots on the same page. I would like one to come in after the first. I'd like an arrow pointing to a feature on the plot and a small mathematical equation to pop up to make a point. Etc. Spatial layout is important and temporal layout is growing rapidly in importance for conveying a message.
I love the idea of DocBook and would like to see the back end processors for MathML and SVG provide the same quality as LaTeX to PDF. However, it's hard for me to seen any hope for XML tags to conveniently abstract away my layout decisions into a structure for presentations that make extensive use of multi-media more than just plain text.
"Provided by the management for your protection."
Perfectly abstract systems like Docbook are perfect in theory. In practice, and in day to day work, physical layout is a very important part of a document.
That's why people use Word Processors like Word and Wordperfect, and spend 30 minutes per document fucking around with the layout -- because layout matters.
Sure, with Docbook, you don't have to worry about it -- not because it does it Right, but because you can't worry about it by design. The result of using a perfectly abstract system like that, is that you just take what comes out, regardless of whether or not it's what you want. Changing the layout that Docbook generates is exceedingly painful -- and the tradeoff you make when you go to a perfect structural definition like that, is a cleaner document in exchange for a layout that is signifigantly harder to alter.
The tradeoff is simply not worth it for alot of things. For documents whose existance matters more than thier presentation (Docbook is ideal for maintaining documentation -- because it hardly ever matters how documentation is presented, as long as it's there), a perfectly structural layout system is great.
But for writing an APA-publication-guide-compliant paper for a Psychology course, anything that doesn't give you precise physical control over the document is exceedingly painful. (Yes, you can write an Docbook-LaTeX template that will handle everything -- but one doesn't exist, and it would be exceedingly painful to do for 99.9% of the population. And a long weekend project for the other 0.1%. And there's that tradeoff -- you give up easy physical control in exchange for perfect structural definition).
LaTeX is far from perfect, I'll grant you that. But it's a hell of alot more useful for writing everyday documents than anything which abstracts the layout out of the equation.
IMHO, TeXmacs is a superior piece of software in every regard.
Most importantly, it is truly What-You-See-Is-What-You-Get, where as Lyx is only What-You-See-Is-What-You-Mean. *Both* screen and paper output from TeXmacs is based on the highly-respected Metafont font rasterization engine.
TeXmacs improves on traditional TeX typesetting not just in providing a real-time rendering engine but also in some more subtle ways, like how it handles various typesetting issues (including font-switching) semantically. Traditional TeX never provided an easy interface for users to switch fonts, although LaTeX eventually improved the situation considerably.
TeXmacs even surpasses commerical offerings like BlueSky's Textures, which renders the
I think that TeXmacs provides a nice counterpoint to development efforts like OpenOffice and KWord, which appear to want to clone Microsoft Word as closely as possible. TeXmacs on the other hand is a real innovation for technical word processing, and I think deserves at least as much attention from the development and user community as the other more office-oriented suites. (In particular, I'd suggest folks working on KFormula to abandon their efforts and see if they can integrate TeXmacs as KPart into KOffice !!!)
Congrats to Slashdot for recognizing the hardwork of the TeXmacs team to produce the 1.0 release.
Future additions to TeXmacs that I hope really come to pass (and to which I might even lend my own efforts time permitting) include:
1. integrated sketching facility based on SVG
2. sub-pixel anti-aliasing for LCD screens
3. adoption of a more standard toolkit like GTK or Qt
4. better documentation of the source since an important project like this needs all the developers it can get (David Allouche's efforts in this regard are a great start)
5. better integration with computer algebra software
TeXmacs is one of the most exciting pieces of open-source software I've seen in a long time.
Do not fail to at least give it a spin if technical typesetting is at all a part of your workday.
LyX is a front end to LaTeX, TeXmacs implements its own typesetting algorithms, by reusing the best algorithms in TeX, and improving where TeX was not good enough.
For example TeXmacs has a global page breaking algorithm, and properly stacks lines with boxes which are taller than the base line height (while TeX puts too much interline space and require manual tweaking). And there is more.
LyX take a "What You See Is What You Mean" approach as an excuse for being unable to be truly WYSIWYG. They then go at great lengths to try to convince people that it is the RIGHT approach. On the other hand, TeXmacs is absolutely WYSIWYG, since the editor screen is drawn by the typesetting system using PostScript compatible primitives.
Also, TeXmacs is flabbergastingly extensible and customizable. All the user interface and keyboard bindings can be customized (on the fly or in the startup file) in Scheme, and you can very easily (much more easily than with LaTeX) define new styles (new packages in LaTeX parlance).
I could also mention that TeXmacs is already used as a user interface for several CAS, that developpers are working on a XSL compatible transformation system, on a Literate Programming system, on a collaborative (Wiki-like) web publishing tool, or I could speak of the high quality and modularity of the implementation, but I think that all this stuff is not really relevant to the casual user...
But, in the end, it is the layout that matters, is it not?
.net</a></div>
Don't worry, I was like you too once. I beleived that it was possible to define a document format so that I could separate the "look" of the document with the actual information that I was trying to convey. But it turns out that this only works with simple documents. As your document increases in complexity, you shouldn't need to define new markup to make the document truly structured and portable. So what has to happen, and it does happen all the time, is that the document author goes beyond the markup and considers the presentation of the document.
You don't believe me? Take a simple example, I'm rewriting my homepage. On the first page, I want to put my email address and I want it to be set apart from the rest of the page. This is what I have in html:
<div><b>Email:</b> <a href="mailto:kholmes@sedona.net">kholmes@sedona
Div is a generic tag used for block elements. Why did I use it? Its definitely against the structured document approach. Otherwise I could simply use div tags for the entire document. Well, the above is certainly not a paragraph. Even if I was defining my own markup language for XML, there is no word to describe it. I could create a specific tag <email-heading>, but again this goes against the structured document approach. Specific tags are not generally useful.
The problem is that for structured documents to work, you need to *write* in a structured fashion. You have to keep track of what the semantics of each part of the document is called and be sure to limit yourself to these semantics.
Any writer would know that this would be far too limiting. Writing, inevitably, is a right-brain activity and is fundamentally unstructured. Technical documentation has to more structured than most since it needs to be easily referenced but inevitably the technical writer is plagued with the same problems that what is natural to write is not structured well to markup.
Then, when you leave the arena of technical documentation structured writing becomes almost pointless. Newspaper columns and magazine articles are really just a sequence of paragraphs written after each other. There is really no need for markup at all. Markup is barely useful for writing fiction since it comes in so many forms. And if the author chooses a new form you can't say "Wait now, we need to write markup for that." When in the end, the author is writing to a reader and not to a computer. Presentation is important. And if you intend on using a structured editor for typesetting poetry, I think even the most stringent holdouts would agree that this is a hopeless cause.
When you define a markup with a DTD or XML schema, you are saying that these are the only things you may write. To write new semantics, the writer must in his head determine the presentation.
Presentation can not be separate from content.