Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix

GNU TeXmacs and Structured Text Editing 72

Posted by michael from the gui-goodness dept.
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."
This discussion has been archived. No new comments can be posted.

GNU TeXmacs and Structured Text Editing More

GNU TeXmacs and Structured Text Editing

Comments Filter:
  • How does it compare with Lyx [lyx.org]?
    • Good question. LyX is great. I wrote a book typeset directly from LyX-LaTeX-PDF.

      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.

      • 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.



    • 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 .DVI output in real time, but in a separate window which is not editable (you always have to return to the TeX source code to make changes.) And Textures is not available for Linux :)

      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 ... say a nice GUI to the functionality of a traditional TeX package like PSTricks which uses Postscript commands to draw on top of TeX output.

      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 ... in particular ability to cut and paste between CAS output and input prompts cleanly and consistently

      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...

      • You miss the fact that more often that not,
        WYSIWYG /gets in the way/. I'm writing content,
        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.
        • So, what?

          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?
    • Lyx has more output formats. One thingI ahve found useful is that I can produce HTML and PDF versions of the same document easilly.

      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)

    by ttfkam ( 37064 ) on Wednesday March 20, 2002 @02:31PM (#3195250) Homepage Journal
    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) [sunsite.dk].
    • It all depends on how you write LaTeX. Normally, you should put all layout data in the .sty stylesheet.
      • Here my knowledge of LaTeX is admittedly lacking. Is LaTeX style data separate and distinct from its structural info? If memory serves, it was not. This leaves it no better than HTML once again. Yes, someone can write relatively clean HTML and have all layout info in a separate stylesheet file (CSS), but the language is intimately tied to how it is displayed and there is nothing but "good taste" keeping things neat.

        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.
        • First of all TeXmacs is not LaTeX

          And second of all, the very first line of your .tex file contains a reference to your document class or style. It's like the header includes in a C file.

          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.
        • You can always write bad LaTeX, but it's harder than to do it correctly. For example, most conferences provide a LaTeX stylesheet for the papers. You can write your whoole article without this stylesheet (which is usually what I do) and then at the last minute link to it in your .tex file and it looks exactly like it's supposed to look.

          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).
    • Latex is like C, you can write a program with everything in main(). Or you can do logical math markup using the \newcommand operator. Or more complicated,

      \newcommand{\Absolute}[1]{\ensuremath{ {\left| #1 \right|} }}

      Then writing \Absolute{x} is clear.

      t.

  • "Structured" TeX? Please, no (Score:4, Insightful)

    by fm6 ( 162816 ) on Wednesday March 20, 2002 @02:44PM (#3195358) Homepage Journal
    I'm no TeX hater. It's a great achievement, it is unsurpassed for describing complicated layouts. (Even some proprietary-format word processors use TeX for equations.) Using TeX for basic word processing makes perfect sense. Not all documents are complicated enough to bring in markup technology.

    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.

    • 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.

      • I did point out that TeX works well when you're doing small documents where structure and maintainability isn't important. A presentation certainly seems to fall in that category. Indeed, TeX strikes me as particularly well suited as a file format for a Powerpoint replacement.

    • 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.
      • Yes, you can write an Docbook-LaTeX template that will handle everything...

        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...
      • This is the second "rebuttal" to my post that simply repeats what I said in the first paragraph. I said it myself -- structure isn't always important. But when you design a "structured" editor, you're obviously targeting documents where it is
      • So use a stylesheet. That's what stylesheets are for. Structure your document with DocBook and present it with CSS, XSL or DSSSL.

        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.
    • But, in the end, it is the layout that matters, is it not?

      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 .net</a></div>

      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.
      • As your document increases in complexity, you shouldn't need to define new markup to make the document truly structured and portable.
        You don't. You find a document DTD or app that fits your needs and use it. XML makes it easier to re-invent the wheel. But that doesn't mean that everybody should do that re-invention. It just means that off-the-shelf wheels are more varied and useable.
        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.
        I'm getting tired of saying this: yes, not all documents need to be structured. If I'm putting together a short memo or a simple presentation, I don't give a shit about structure.
        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:
        Well now, that's ironic. You've just described the reason there are so many web pages out there that are difficult to access. Somebody hacks out some HTML, tests it in their own day-to-day browser, and pushes it out when they're satisfied with the way it looks. But then they get complaints: the page doesn't work on another browser, at another resolution, at another color depth. I've even seen pages that only work if the user's monitor has a specific alpha-channel setting!

        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.

        Newspaper columns and magazine articles are really just a sequence of paragraphs written after each other.
        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!
        Writing, inevitably, is a right-brain activity and is fundamentally unstructured.
        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.

        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.
        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.

        • Sir, I would like to respond to your post seriously, since you do make some points. But I don't think it would do any good. Your harsh response seems to show contempt for any responses that you disagree with. And I won't continue a thread with you if are unwilling to make any concessions. There's really no point in that.

          Best regards,
          Kevin Holmes
          • That's a cop out. You made some poorly-considered, ill-informed statements and I called you on it. My personality defects (guilty!) are beside the point. If you have a response, respond. Otherwise, spare us your childish attempts to get in the last word.
    • Right on, brother. I used LaTeX for my thesis, and was disappointed. The idea of "programming" a document appeals to me greatly---I even did most of my thesis diagrams using nothing but hand-written PostScript---but I found that LaTeX is just not what it's cracked up to be.

      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.
      • Personally, I find MS Word easier from start to finish, with the appropriate use of Styles.
        Well, that works if you're solely responsible for your document base, or you can enforce proper use of styles on all your writers. But in any big doc project, you have writers using raw formatting when they should use styles. The design of Word actually encourages this.
        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.
        I see XML+(appropriate DTD or schema)+(stylesheets in CSS and/or XSL) as the answer. There is browser support for this (pretty good in Mozilla, half-assed in IE6), but I think the right approach is to do the stylesheet transformations before you deliver your document to the user. That way you can leverage the strenghs and work around the weaknesses of each browser. And also deliver in other formats, such as PDF. Which solves the typesetting issue, since most print shops are PDF-capable -- the ones my company uses actually prefer it.

        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 can use other fonts technologies than Metafont.
          • TeXmacs is not dependent nor does it use TeX.
          • Please try TeXmacs and see by yourself. I think the TeXmacs team will be interested in speeding up the XML/XSLT processing engine with your help.
          • Well, I admit I was too quick to assume that TeXmacs uses TeX as its native format. Still, you have to admit the project name rather encourages that assumption!

            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.

    • 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.

      • You cite a good example, one where specific conditions (not the ones I asserted, fallible me, but still very specific) apply. Let's look at those conditions.

        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....

        • 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)

    by Red_Winestain ( 243346 )
    LyX [lyx.org] is also a nice front to LaTeX and works on a variety of platforms. It is available under a slightly modified GPL (the exception is that you are allowed to link LyX to the XForms library).

    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)

      by Anonymous Coward

      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)

      by xyle ( 567842 )
      • TeXmacs is not a frontend to LaTeX. As the previous poster explained, it has its brand-new typesetter (with some improvements).
      • It's available under the GPL
      • You can use most LaTeX macros by preceding them by a backslash. They're automatically evaluated.
      • You have some neat constructs, like "->"forms an arrow (or you can use \rightarrow, if you like to type a lot like the vim guy below), @x is an x inside a circle (sometimes used for the tensor product), >= is \geq, etc etc. TeXmacs does not help learning LaTeX, but it helps LaTeXers migrate smoothly by mimifying widely used macros.
      • TeXmacs exports to LaTeX (e.g. for article submission
      • With TeXmacs you see all math symbols on screen. With LyX you have lots of red (LaTeX) code around.
      • TeXmacs has dynamic, contextual menus.
      • TeXmacs imports html.
      • TeXmacs talks to maxima, mupad...
      • TeXmacs has an extension language
      • TeXmacs has a very dynamic documentation site at TeXmacs resources [alqua.com].
  • It [texmacs.org] starts on page 39. Where's pages 1-38?

  • I know they mention it converts to Latex, and according to the GNU site there is no real problem with that? The problems seem to be converting from LaTeX/TeX into their XML format? So, I'm not clear on this. Anyone have any experience using this stuff and how well it will convert TO Tex, etc.? That would seem to be the main concern..... By the same token, I don't like the idea of having to drop vim.

  • Writing my PhD thesis now... (Score:5, Insightful)

    by PoiBoy ( 525770 ) <brian.poiholdings@com> on Wednesday March 20, 2002 @04:18PM (#3195943) Homepage
    Right now I am writing the third and final chapter of my thesis (in economics), and I must say that LaTeX is a godsend.

    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.

    • I haven't used Lyx much yet, but couldn't what you desire be accomplished by just allowing the user to
      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.
      • I've got a small bash script that every 10 seconds automatically reruns latex on my file and sends a signal to xdvi to update. Whenever I want to see what I just wrote, I just press ctrl-o to save the text file (I use pico), and in the window just to the left of my xterm, I see the actual document. Email me if you want my script.
    • Instead of thinking about what TeXmacs might suffer from, you should rather try the program. In this way you will find out that "ESC F ALT-g DOWN 2" would have sufficed to type \frac{\gamma}{2}. In other words, 6 keystrokes instead of 16. And moreover, you see what you are typing...
    • Amen.

      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 :)
    • You obviously haven't used LyX much. You can type LaTeX macros directly into its equations, instead of using the GUI panel.

      Try typing \frac {\gamma}{2} in LyX (first hitting C-m to start math mode, equivalent to typing $ ... $ in LaTeX:

      1. Type \frac: notice that the \ switches you into TeX mode, and the text is in red. Hit the spacebar to exit TeX mode: boom, you have a graphical fraction with two empty boxes for numerator and denominator.
      2. Type \gamma, space, and boom: you have a Greek gamma.
      3. arrow down to the denominator (no need to type {}), and type 2. You're done.

      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.

    • I agree with you about LaTeX being irreplaceable... My PhD dissertation was written in LaTeX, too. But the time taken to put in the document structure elements detracts from the time you're saving by just typing everything. This is where LyX really shines, I believe. You can map any LyX command to a key-binding, and in fact it comes with an "emacs mode" of sorts. Using this, you get the benefit of LyX handling the document structure for you, the almost wysiwyg environment, and being able to type straight LaTeX whenever necessary, plus the emacs key-bindings you're already used to. To be honest, I didn't use plain LyX for the whole dissertation. Things like title page, TOC, TOF, etc. and special pages I prefered to use raw LaTeX for, but here again LyX helped. You can switch to LaTeX mode (using a key-binding, if desired), and either type the code you need, or just \input another file. Once I got into the swing of it (and you know we're talking on the order of a year's worth of writing), I ended up barely using any menus in LyX. Even saving the document and quiting was C-x C-c y :)
    • Try an IBM Stealth TrackPoint Keyboard [ibm.com]. You can keep your fingers on the keyboard. It's great for keyboard-unfriendly environments like MacOS, Windows, web browsers, and certain Linux programs. It's also compact and has a nice feel to it, and if you want, you can still use a regular mouse in addition to it (say, for games). There are also PS/2 versions.

  • 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.

  • Frame (bought by Adobe years ago) already built a good WYSIWYG structured content system called FrameMaker [adobe.com].

    It rocks--check it out.

    • Yes Framemaker is great, but:

      1. Framemaker is not really WYSIWYG since it uses one view for the structured data and a different view for the typeset data. At least it worked that way last time I saw someone using it, two years ago. You can do that kind of thing using two views with different stylesheets in TeXmacs, but you are not forced to.
      2. I would be very surprised to learn that FrameMaker provides the typesetting quality of TeXmacs (which, I recall, is better than TeX).
      3. Once TeXmacs supports document transformations (give us 6 monthes), it will kick the ass off FrameMaker.
      4. FrameMaker is an expensive piece of software (799$) coming from a Adode (remember Skyarlov?), while TeXmacs is GNU software coming with freedom.
    • FrameMaker has a _lot_ of problems.

      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 /vskip 36pt +1fil), fakes small caps, no automatic ligatures beyond fi and fl, etc.

      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 .fm files back. :(

      William
  • this has been bugging me for a while
    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.
    • Your are right, the TeXmacs name is very misleading. Indeed. I suppose Joris named its tool TeXmacs because TeX and emacs were conceptual starting point that he improved and merged. But because TeXmacs it is neither TeX or emacs, people have wrong expectations leading to disapointment and they miss the major point: we got at last a scriptable WYSISYG typesetting tool with separates content and layout.
      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.

    • 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!
  • Another milestone in scientific computing has
    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.

    --
  • In order to do something (anything) with structured text stored in ascii one has to parse it. If the structured information is somehow more than the syntactical structure parsed by your parser, you lose that information when you save (because your parser does not know how to parse it).

    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.

  • 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]

  • I see a lot of comments about how XML is much better than TeX/LaTeX because you only need to write the text and all the formatting is handled in the DTD; if you want a different layout, you find a different DTD. Or that TeX/LaTeX is as horrible as HTML because you have to explicitly put in all the formatting. Neither is my experience with TeX/LaTeX. When I wrote my dissertation I never worried one bit about any formatting because I used the university-supplied LaTeX style format. I just wrote the text, ran it through LaTeX and out came the beautiful format. Also many professional societies and journals provide a LaTeX style file so the author doesn't have to worry about figuring out how to get the document layout correct. Also, if I want to throw together a quick document without thinking about it, I use the default article style. It is all platform independent too. And you can also define your own tags, so to speak, very easily.

    Since I know very little about XML, could someone who knows both XML and TeX/LaTeX clue me in?

    • 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:

      • XML can be validated. That means that you can automatically process a XML document to be sure it contains only a specified set of structuring elements (they call them tags in XML, you call them commands and environments in LaTeX).
      • The XML document structure is much more easy (generally) to parse and process automatically than the LaTeX document structure.

      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.
      • Thank you for the very detailed response. I hope the moderator gods smile favorable on you. :)

        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.

Slashdot Top Deals

Somebody ought to cross ball point pens with coat hangers so that the pens will multiply instead of disappear.

Close