GNU TeXmacs and Structured Text Editing 72
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."
How does it compare with Lyx? (Score:2, Interesting)
Re:How does it compare with Lyx? (Score:3, Insightful)
Judging from the screen shots on the web site, TeXmacs is more oriented to mathematical writing while LyX is more for general typesetting. The TeXmacs icons on the tool bar also suggests this.
Re:How does it compare with Lyx? (Score:1)
I am no LyX user. Actually, I tried it once but I found it so ugly that I came right back to AUC-TeX.
TeXmacs on the other hand is a constant aesthetic pleasure. I know that structured documents are not about good looking screens, but I really think that a beautiful tool is WAY more pleasurable to use than a ugly one.
However, I cannot see why you think that TeXmacs is only a tool for maths. if you look at the screenshots [lyx.org] on the LyX site, what will you see? Math formulas.
Just have a look at these documents [texmacs.org] if you want to see how TeXmacs can be be used to typeset source code documentation.
Re:How does it compare with Lyx? (Score:2, Informative)
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.
Re:How does it compare with Lyx? (Score:2, Informative)
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...
Re:How does it compare with Lyx? (Score:1)
Re:How does it compare with Lyx? (Score:2, Insightful)
WYSIWYG
I expect and need LaTeX to handle the
presentation. WYSIWYM is not an "excuse", it's a
definite feature. In LyX, when I'm editing
a document, I see what I need to see and
nothing more. Where page breaks happen, thanks
to LaTeX, is irrelevant for 99% of the editing
I do. I don't want to be distracted by that.
LyX is equally customisable too.
Re:How does it compare with Lyx? (Score:1)
You do not want page breaks? TeXmacs has "papyrus" paper type... Do not want to see the page width? Use "automatic" paper type.
When you need something WYSIWYM, define a stylesheet for editing (that can make markup explicit, for example), which is different than the stylesheet for printing. Still, you can use full WYSIWYG when hunting typos or fine-tuning page breaking. In this kind of work, that is WYSIWYM that gets in the way.
WYSIWYM is a excuse, since you do not have the choice. With TeXmacs you can choose exactly how much you want to see.
Why use LyX since there is TeXmacs?
Re:How does it compare with Lyx? (Score:1)
Lyx also has better import - it can import text as paragraphs or lines for example.
Lyx is faster and works better. One of the first things I noticed with an imported text file in TeXmacs is that getting rid of a line break by backspacing from the start of the next line did not work on the first attempt, but did work eventually. Generally Lyx is the more intuitive despite being less WYSISYG.
Lys is noticably faster and feels more responsive on my 1.2GHz Athlon.
TeXmacs looks prittier. It has better control over appearance from the GUI.
I might find a use for TeXmacs for short documents or where appearence really matters, for long documents LyX wins hands down.
If Lyx has a little more ways of tweaking final appearnce without suing LaTeX, I would have no use for TeXmacs.
(La)TeX has too much layout info (Score:3, Informative)
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) [sunsite.dk].
Re:(La)TeX has too much layout info (Score:3)
layout data in the .sty stylesheet (Score:2)
For DocBook, there is *nothing* layout-related. It is all semantic markup. While you could conceivably add (for example) HTML to a DocBook file, it would have to be in a separate namespace and therefore clearly defined as a separate entity. The same thing for MathML. There is nothing keeping you from embedding MathML in a DocBook document. In fact, it's easy. But you clearly see where the two meet. There is never a blurring of the line.
Please correct me if I'm wrong about LaTeX. It would not be my intention to slam it without just cause.
Re:layout data in the .sty stylesheet (Score:1)
And second of all, the very first line of your
TeX is all about presentation that doesn't change with platform and time.
LaTeX is just macros for TeX that allow you to present information in some given style.
Re:layout data in the .sty stylesheet (Score:2)
All LaTeX commands are "high-level". For example you tell latex that "Introduction" is the name of a section (and your stylesheet defines what a section name looks like). The same for figures, you just tell LaTeX if you prefer them as close as possible to the reference or on top of a page (if applicable).
Re:(La)TeX has too much layout info (Score:1)
\newcommand{\Absolute}[1]{\ensuremath{ {\left| #1 \right|} }}
Then writing \Absolute{x} is clear.
t.
"Structured" TeX? Please, no (Score:4, Insightful)
But TeX enthusiasts seem to be stuck on the idea that Tex is also useful for structured documents. Sorry, it just isn't. If you want to impose structure on a document, you can't use a format designed around layout. Even if you add constructs that describe document structure (as LaTeX does) you can't prevent the user from using non-structure elements "because it looks right". So you end up with a convoluted mixture of structure and layout that's impossible to maintain. That's why HTML is such a mess. That's why maintaining large technical documents with traditional word processors is a nightmare.
If you need to maintain a large structured document, you need to use a format that makes no attempt at all to describe layout. So the writer is forced to think purely in terms of how the document is organized. You keep layout description in a separate thing, a "style sheet". Not only does that end your document maintainence nightmare, but it allows you to deliver the same document in different ways just by providing the appropriate style sheet. You have a single source that's accessible as a set of web page, or as a printed document, or whatever.
What formats am I talking about? Since this is 2002, I'm talking about XML. Not XML in general (most XML apps are data-centric not doc-centric) but specific appropriate XML applications, such as DocBook [docbook.org] or DITA [ibm.com]. For the stylesheets there's Cascading Style Sheets [w3.org] and/or XSL [w3.org]. But these are just the best technologies that happen to available now. The basic idea has been around for a long time: in structured documents you have to separate markup and layout.
Re:"Structured" TeX? Please, no (Score:3, Informative)
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.
Presentations (Score:2)
Re:"Structured" TeX? Please, no (Score:3, Informative)
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.
Re:"Structured" TeX? Please, no (Score:1)
Just so I'm not taken out of context, I was referring to a Docbook-LaTeX template that would generate a LaTeX document that is compliant with the APA Publication Guide. Anyone who has taken a Psych course has probably suffered through that guide...
Can anybody here read? (Score:2)
Re:"Structured" TeX? Please, no (Score:2)
I would love to see an text processor that let me type in structured text (like LyX), then switch to a style mode where I can fiddle with the style (like Word). You get the best of both worlds that way.
The myth of separating presentation and content (Score:3, Informative)
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.
Nonsense (Score:2)
If you want a specific look and feel and don't care if your site is accessible to everybody, go ahead and do that weird clunky stuff. But if you want to do a professional web site that meets accessibility standards, is easy to internationalize, and doesn't break any widely-used browsers, then you have to put a lot of thought into structure.
Sorry, but you know jack about journalism IT. News stories have never been "streams of paragraphs". All publishers, but periodicals in particular, have always had complicated markup and layout conventions. When newspapers started computerizing back in the 70s, they invented very complex file formats to describe these conventions. Which formats turned out to be a real problem when newspapers started having online editions. A classic case of the problems created by not separating structure and layout! When I see psychobabble like "right-brain activity" (which isn't valid neurology, btw) I'm tempted to think that somebody is confusing creativity with intellectual laziness. Well, that's not quite fair. But there is a certain laziness in sweeping statements about exactly what writing is and what goes on in your brain when you're doing it. If you're brainstorming and just trying to get a lot of ideas down before you forget them -- sure it's stupid to worry about structure. Indeed many writers prefer to get as low-tech as they can. Even a simple word processor is too much of a distraction for some -- or even a typewriter. Which is why they still sell so many of those 13" yellow pads...But for any bit of serious writing, be it a technical manual or a novel, there comes a time when you have to start thinking about the structure of the thing. I suppose there are "stream of consciousness" novels that went straight from tape recorder to the printers. But I'm sure not interested in reading them.
Now that's funny. Many years ago, I was a typist for a well-known poet. This guy wrote in a modern style, not a lot of rhyming and assonance. But even so, structure was a big issue. I had to be very careful that my typing did not contradict the subtle expressiveness of his very. Even a carelessly placed page break could be an issue.Poetry is almost the classical markup application [google.com]. The first SGML tutorial I ever read (can't seem to find it now) used an old book of poetry as an example. If you want to bring this book online you have to do a lot of careful thinking. There are obvious tags that express the structure of the poem (<verse>, <line>, etc.) But if you don't know the poet's conventions (is that line break in the middle of a verse or not?) you might get something wrong. So you invent other tags and entities that describe the precise contents of the book.
Wait, am I mixing content and layout? No, because the original layout is not an absolute part of the document -- it's just information you want to preserve. Most users will view the document using a style sheet that ignores the tags that don't describe the basic structure of the poem. Some scholars will be interested in this old information, and will use a style sheet that reproduces the original book. With the right style sheets there's no end to the way you can present the poem. The scope for creativity is enhanced, not limited.
Re:Nonsense (Score:2)
Best regards,
Kevin Holmes
Re:Nonsense (Score:2)
Re:Nonsense (Score:2)
Re:"Structured" TeX? Please, no (Score:2)
Personally, I find MS Word easier from start to finish, with the appropriate use of Styles. The problem with that is its proprietary binary file format, which can get corrupted after a bad enough crash. Binaries don't work too well with revision control systems, so you end up just keeping vast quantities of backup copies.
HTML+CSS does a great job of separating content from presentation IMHO, but that's no good because (1) browsers (by which I mean MSIE of course) don't support it, and (2) it's no good for typesetting.
Where does that leave us? I wish I knew.
Re:"Structured" TeX? Please, no (Score:2)
The one part I'm bothered about is the limited choices in WYSIWYG XML editors. (Not true WYSIWYG, of course -- that's inconsistent with the whole structured document idea. I mean editors that make it easy to visualize your documents in various stylesheets.) There's FrameMaker+SGML, which is very expensive and has all the UI issues of FrameMaker. The're the Arbortext editor (formerly "Adept" now "Epic Editor"), slightly less clunky, also expensive. Both target Unix and Windows, but not Linux. I don't have a lot of experience with either, but it's worth noting that both were designed for SGML, and have minor issues with the deliberate limitations of XML.
SoftQuad's XMetal looks really nice, but only runs on Windows.
The XMLSpy suite now includes a WYSIWYG editor, which I haven't had a chance to look at. Since XMLSpy products are written in Java, this might be Linux's best hope.
I find the response of the Open Source community in this area pretty disappointing. There's a lot of XML expertise, but it's all in XML data, not XML documents. KDE uses XML to maintain its doc base, but everybody seems to be happy using EMACS with a validator plugin -- a reasonable solution if you have the EMACS gene, but not everybody does. Other projects are too caught up in outdated concepts -- Amaya with XHTML and related DTDs, Lyx and TeXmacs with TeX/Metafont, and an endless number of reinvent-the-word-processor projects.
TeXmacs is not stuck with outdated concepts (Score:1)
Dates, concepts (Score:2)
Besides, the specific format is beside the point. You can't manage large structured documents with a format that embeds formatting information. This should be obvious to anybody who's compared the markup approach [stoa.org] with the word-processor approach. Alas, nobody can be bothered to do this.
Why not? (Real life example.) (Score:2)
I've read the other replies here, and I agree with your point about small, naturally unstructured documents. However, I think it's perfectly possible to use (La)TeX to produce a large, highly structured document as well.
To give a concrete example, I have recently been helping my partner to typeset her masters thesis. The subject matter is a combination of English and Hindi literature. The thesis is arranged in sections as one might expect, requires standard extras such as a table of contents and bibliography, footnotes, the occasional picture, and plenty of quotations (some English, some Hindi). On my advice, she chose to use LaTeX to typeset her thesis.
Why did I advise that? Pure flexibility, if nothing else. Aside from generally professional-looking results, it is easy in LaTeX to introduce things like pictures, Hindi text (in a custom font we created ourselves using METAFONT), footnotes, bibliographic citations and cross-references in a structured way. There is always the chance with these things that the paper, or excerpts from it, will be republished in a journal, incorporated as an appendix to a PhD thesis, presented at a conference or otherwise reused. Structure and flexibility in the presentation are of vital importance.
Of course, generality is all very nice, but what really counts this time is how the finished thesis looks. Several experienced researchers have commented on the professional presentation of the finished product, so clearly that did not suffer as a result. The whole document was marked up structurally, but with LaTeX, we were also able to incorporate hints about where page breaks should go, etc. These are not concrete statements -- "Page break HERE!" -- but advice to the typesetting engine. As a result, the finished paper was more elegantly typeset than anything that would have been produced from an XML document with purely structural markup, however smart its stylesheet might have thought it was. Ultimately, good visual design is possible with stylesheets, but great visual design still requires the human touch, and a little effort to get it just right.
On this basis, I claim that LaTeX, at least, is emminently suitable for general structured documents, and not just for scientific papers.
Good example (Score:2)
The writer has personal control over the document file, so she can enforce rules the ensure its maintainability. She has the services of an expert consultant (you) to help her set up those rules, and to tutor her in their proper use. Finally, she only has a single deliverable: a simple hard-copy printout in a standard thesis format.
Now if this fully describes her needs, your partner should certainly ignore my Markup Dogmas and do things the way she's doing them.
But if her document maintenance needs ever broaden, even a little, she's going to regret her initial design choices.
Suppose, for example, some academic publisher reads her thesis and says, "Hey, this is good work! If you expand it a little, it would make a good book!" So now she needs to start collaborating with some editor in another city. It'd be nice if they send revisions to each other electronically. Problem: the publisher doesn't use the same file format. Maybe it's something totally proprietary to the publisher; maybe it's TeX with some special macros they invented themselves. Maybe there's some Hindi word processor that's common in South Asia, but your partner has never heard of. Maybe it's an XML app with a special Hindi back end...
Getting the existing text into the publisher's format will be a nightmare. The cheapest solution might well be to re-enter the entire thesis from scratch.
Scenario 2: Some South Asian web site wants to put the thesis online. Delivering web pages in Hindi [niharonline.com] isn't hard, but you have to translate the thesis into HTML with the appropriate character sets. Another journey into format hell.
Scenario 3: Your partner learns that some of the quotations and statistics in her thesis are incorrect, and need to be updated in a hurry. No time to do it herself, so she hires a typist. You carefully explain the structure rules for editing the document, but the typist is stubborn and/or stupid and does things her own way, leaving you with a document that "looks right" but is full of manual page breaks, raw formatting instructions, and other garbage that renders the document unmaintainable.
Scenario 4: Some time-travelling troublemaker prevents her from even meeting you. She doesn't have the technical skill to do the fancy thesis on her own, and can't afford a consultant. She tries to put it together with the old scissors-and-glue method. She's so disappointed with the results she drops out of grad school and goes into real-estate.
The markup approach addresses each of these scenarios.
Electronic collaboration is much easier when both parties use a XML-based, content-oriented schema. This is true even if they're not the same schema, because XML is very easy to transform.
Speaking of transformation: HTML is hard to maintain and transform. Which is why more and more web sites maintain the content in XML and only deliver it in HTML.
XML is stupidity-proof. Your typist doesn't need to remember all your rules. They just need to use a validating XML editor.
And if you have a validating XML editor and know how to use it (not a common skill, but one that any serious writer should consider acquiring) you don't need a technical expert holding your hand. You just need an appropriate XML schema and back-end software. I don't know what there is mixed Hindi-English documents, but given the number of programmers who come from that part of the world....
Re:Good example (Score:2)
While I take your points, I think (with no disrespect intended) that many of them are either exaggerated or somewhat hypocritical.
For example, given that the LaTeX document is plain text, marked up in a simple, purely structural fashion, translating it into any other format (including XML, if you wish) could be done completely automatically with a trivial program. Speaking as someone familiar with both text processing tools and XSLT, I confidently claim that we could do this just as easily as you could map from one XML schema to another using XSLT. A similar argument goes for translating to a different character set; the standard transliterations into the Roman alphabet are used throughout, and the standard transformations back to a native Hindi character set could be applied automatically as well.
You also mention the possibility of getting a typist to update things, and then further decide that your typist is to be incompetent. An incompetent typist could just as easily mangle an XML-based document if they don't understand the structure being used; even a validating editor can only stop them going wrong, it can't make them get it right. And, of course, if you can teach multiple people your XML schema so they can edit the same document, then to be fair I must be allowed to teach multiple people rudimentary LaTeX for the same purpose.
And finally, if my girlfriend had not had my guidance and help in writing the original stylesheet and such, certainly, she would have had trouble using LaTeX to produce a result without alternative assistance. OTOH, the exact same is true of XML. Do you think she could sit down and write herself a suitable schema, locate and install a validating editor and then write a suitable stylesheet to render the output on her own either? Of course not. She would require at least as much technical assistance with the XML-based solution, and most of it would once again be up-front. You yourself even admit that having and knowing how to use a validating editor is not a common skill and something she would need to learn. I taught her the necessary LaTeX and METAFONT within a few hours at the start of the project, and she's had no trouble making changes on her own ever since. If she had to produce another document (e.g., her PhD thesis), she could use many of the same skills she's learned again, and she'd know where to look to learn the rest.
As far as I can see, none of your objections holds any more for our LaTeX-based solution than it does for an XML one. Both are perfectly acceptable solutions for the general problem, and the LaTeX solution made actually completing the work much easier for other reasons (e.g., the ease of incorporating our own font and pictures, and generating a PostScript output file).
The defence rests, your honour. :-)
LyX (Score:2, Informative)
I found LyX and excellent way to start using LaTeX.
I'd be interested in people's comments who have used both.
Re:LyX (Score:2, Informative)
But TeXmacs [alqua.com] is not a frontend to (La)TeX. TeXmacs learned the typographical lessons from (La)TeX, enhancing some of their widely acclaimed algorithms.
I have used LyX daily for 4 years, typing physics courses in real time with my laptop. I have grown tired of the imperfect layering that LyX/LaTeX/TeX constitutes. Now I believe TeXmacs is the way to go. If it gets some more attention (it is stunning how sometimes excellent programs go unnoticed for years) it will soon be the XML wysiwyg editor we're all waiting for. TeXmacs internal data format is XML ready.
Also, sometimes people ignore the second main goal of TeXmacs: to become an interface for computer algebra systems. It already interfaces with maxima, mupad, pari, qcl, the shell, scheme, and others. Mathematica and Maple support is underway. LyX cannot (currently) send its formulas to any external program.
The last thing to note, in my view, is that TeXmacs makes the attempt to reconcile structured editing with WYSIWYG in an incredibly succesful way. Just unpack the binary and start creating a document to see it in action. It is the kind of behaviour you immediatly recognize as "the right thing"(TM).
There are very nice screen shots at TeXmacs resources. [alqua.com]
Re:LyX (Score:1)
Where's the rest of the document? (Score:2)
Re:Where's the rest of the document? (Score:1)
Conversion TO Latex? (Score:1)
Writing my PhD thesis now... (Score:5, Insightful)
I think this GNU thing suffers from the same problems as LyX, Scientific Workplace, and every other GUI front-end to (La)TeX -- it relies on menus and the mouse.
In the time it takes someone to remove his hand from the keyboard, search through a menu or click a button to make a fraction, and search through another menu or palette to find a gamma, I could have typed \frac{\gamma}{2} ten times.
My experience has been that people look to these things so they don't have to be bothered by knowing all the commands. I think that's a waste of time. After writing one paper using LaTeX, you will have memorized all of the symbols commonly used in your discipline, and you'll soon discover that LaTeX is so much faster than a GUI application.
Spending a couple of hours learning LaTeX is time well spent, and you will certainly be repaid many times over in the long run.
Re:Writing my PhD thesis now... (Score:1)
enter LaTeX commands by first pressing a special key to open a 'enter command' prompt? LyX lets you see that what you entered makes sense, while editing LaTeX in text editor leaves me guessing whether my input was what I meant.
Re:Writing my PhD thesis now... (Score:1)
do you see? (Score:1)
Re:Writing my PhD thesis now... (Score:1)
Re:Writing my PhD thesis now... (Score:1)
I tried using both LyX and TeXmacs, but I couldn't stand the fact that they rely too much on menus and on the mouse, as you pointed out. Pretty much the best frontend to LaTeX that I've found is vim
The best gui frontend I've seen is winedt [winedt.com], available for windows. It's basically a text editor with a lot of nifty functionality that's useful for editing LaTeX code, like macros, a toolbar with commonly used symbols (which just pastes the latex code) and other neat stuff. Converting to pdf,ps,dvi is only a mouse click (or two) away, so I guess that's why I use it. Saves me from writing another makefile to do all the conversions
LyX allows you to to exactly this (Score:2)
Try typing \frac {\gamma}{2} in LyX (first hitting C-m to start math mode, equivalent to typing $ ... $ in LaTeX:
LyX gives you all the power of LaTeX plus the advantages of a GUI and WYSIWYM (not WYSIWYG) display. An extra nicety is that when you select something in the GUI (e.g. click the gamma icon in the math panel), it tells you the keyboard shortcut (\gamma) in the status bar...so it teaches you the relevant TeX as you go, but you always have the GUI as a backup if you forget.
Not that LyX is perfect (I'm required to hack in LaTeX more often than I think should be required), but it is really a step in the right direction. Note that it can output DocBook too.
Re:Writing my PhD thesis now... (Score:1)
Re:Writing my PhD thesis now... (Score:1)
Commenting sources (Score:1)
As seen here Here [alqua.com] TeXmacs behaves well as a code documentation tool. I can imagine why it's being worked into a literate programming environment.
Structured WYSIWYG? It's called FrameMaker. (Score:1)
It rocks--check it out.
Re:Structured WYSIWYG? It's called FrameMaker. (Score:1)
Yes Framemaker is great, but:
Re:Structured WYSIWYG? It's called FrameMaker. (Score:1)
1 - pathetic typographic controls / tools. It can't even baseline shift beyond super/sub script, and its H&J algorithm is basic, brain-dead, one-line at a time, similarly, controlling where it adds space requires manual intervention at _every_ point (no equivalent to
2 - Really, painfully bad equation editor
3 - Bad pre-press, it prefers RGB for colour models, and getting spot colour out of it is a nightmare
4 - no Linux version, they did it in beta, then pulled it leaving testers high and dry.
There's lots more, but I've gotta hurry home to finish up a ~400 page, 2 colour book which is being done in FM 'cause the author insisted on getting
William
on TeXmacs name (Score:1)
and nobody answers me.
Why is it called TeXmacs is it's not based at TeX/LaTeX (as stated in the doc and faq)?
it's a bit misleading.
Yes... there's exporting (not perfefct) to latex.
But that's like saying that since MSWord exports unperfect html, it should be called MSHTMLword
one of the things I value most about TeX/LaTeX is its portability, if you stay away from the most esoteric latex packages, you can compile your docpretty much everywhere, and gots bettter with TeX.
That's why kinds of bugs me the name. But again, TeXmacs lovers always tell me it'0s named after TeX and emacs which doesn't really enlighten me.
Re:on TeXmacs name (Score:1)
Like TeX, TeXmacs is a typesetting system. TeXmacs does not rely on TeX except for MetaFonts and bibtex.
Like emacs, TeXmacs composite keybindings are used, but TeXmacs does not rely in any way has emacs. As a recent user and programmer of TeXmacs, I feel TeXmacs should have a mode to support beginners that drives them gently to power using.
Also , contrary to claims in other threads, TeXmacs supports styles sheet and cleanly supports separation between content and layout. Despite this feat, Joris has a lot of work before him that you both can't do WYSISYGness and "separation between content and layout". Probably some wrong ideas are so entrenched that people don't even bother to check when evidence is a download away.
first try, then FUD (Score:1)
Comparing the M$Word generated HTML to the TeXmacs generated LaTeX only shows that you have never exported to LaTeX from inside TeXmacs
Go give it a try, drini. You can!VI VI Vi (Score:2)
alied itself with EvilMACS >:-/
The Vi(m) community is boycotting all this nonsense;
remaining true to the spirit of Unix, nroff,tbl, eqn, and ed.
Death to the elitist bloat, long live crude, macho, computing.
--
Re:macaulay2 (Score:1)
ascii != structured (Score:2)
This is the main reason why there's a reverse engineering option in many case tools. You have a nice diagram, you generate code (ascii!!!), all the nice info you had in the diagram is lost because it is not part of the syntax of your programming language and after you change the generated code you have an outdated diagram and source code that simply does not contain all the necessary information to reverse engineer it (e.g. any constraints you defined in rose). Why throw away all this information? Because developers want emacs/vi/whatever to edit their code! Don't get me wrong, emacs is a wonderful text editor, so is vi. But they are text editors, not structured information editors. They don't enforce syntactical correctness, they don't allow for new syntactical concepts, they don't store meta information, etc.
That's why in addition to ascii, advanced development tools like rational rose, visual age, togetherJ, intelliJ, netbeans, etc have some sort of internal program database while running. Visual Age doesn't even bother to generate ascii anymore and uses the internal DB for storage and on the fly compilation.
The advantage of this is that you never really lose the design information (unless you export to ascii) and as long as you stay within the tool your fine. That's also why it's easy to implement stuff like refactoring (essentially refactoring is a transformation of the structured data) since you already have a queryable structure. Of course these tools save their data in some format (maybe even ascii), however the data these tools store contains all the relevant data these tools generate so nothing is lost. Netbeans for instance uses program comments to specify non editable parts of code generated by the gui builder and Visual age uses some binary format.
For those interested in the program (Score:1)
There's a very nice Doxygen-generated site with inheritance & composition graphs for the TeXmacs C++ classes and other goodies:
Take me to the TeXmacs source code. [freesurf.fr]
Could someone clue me in ... (Score:2)
Since I know very little about XML, could someone who knows both XML and TeX/LaTeX clue me in?
Re:Could someone clue me in ... (Score:1)
Having used LaTeX a lot, and having programmed a XSLT based publishing tool before discovering TeXmacs, I think I can help.
If you abstract all the prejudice and bigotry, the XML vs LaTeX debate just boils down to a few things:
For SGML/XML folks, the main problem with LaTeX is that it allows the users to throw in just about anything in the document structure (including arcane and unparsable TeX wizardry). On the other hand, using a XML document format with a DTD restrains the user to a specific markup language, which is generally designed to allow only strutural markup. The point is in preventing people from doing the wrong thing in big documentation projects.
By the way, a DTD only define the markup language (the tags, and how they can be nested). In XML, the presentation is defined by a stylesheet, which can be CSS (only add some presentation info), XSL (can perform complex tranformations on the document structure), or something else.
What the XML folks here did not understand (no surprise, since they have not tried TeXmacs before flaming it) is that the user interface is so customizable that you can easily restrain the users to a specified markup language simply by not allowing them to input anything else.
Actually, you can (still) not prevent the user from putting legal structuring elements in illegal struture (invalid nesting) through copy-pasting, but:
- you can design the stylesheet to make illegal structures visually obvious, and
- since the TeXmacs document format is essentially (not exactly) Scheme (XML externalization will come soon), any real programmer can write a Scheme program to perform validation. Or if you know Perl, the document format is much more easily parsable than XML, so you could write validator in one week-end.
By the way, we would welcome such a contribution.Re:Could someone clue me in ... (Score:2)
I am certainly going to try TeXmacs. I am a LaTeX guy at heart and I have always thought the beauty of it is that it does exactly what you tell it to do, and you can really make it stand on its head if you wanted (where the really arcane stuff you'd add with TeX commands); maybe I really don't want either single, double, or 1.5 space lines---I want 0.8 spaced lines dammit!
I always looked at TeX vs WYSIWYG as like C programming vs VisualBasic, where the former isn't cute or restrictive like the latter. I look forward to comparing TeXmacs to LaTeX.