The StartX Files: Learning the Ways of LyX

By: Brian Proffitt
Tuesday, October 30, 2001 02:45:09 AM EST
URL: http://www.linuxplanet.com/linuxplanet/reviews/3871/1/

Lessons in the Circle of Life

It is 1992 and I am in New York City, with Neo-Nazis protesting outside.

I am in the City because I have just started a new job for the Institute of Electrical and Electronic Engineers working as an assistant editor in the IEEE's Transactions department. There are neo-Nazis outside because at that time, the IEEE's Transactions department was just across the street from the United Nations. Because of this, demonstrations were almost a daily occurrence outside of my office building.

The neo-Nazis were always loud, but they were never any trouble or the least bit frightening, even if you happened to be something other than Caucasian. New York's Finest certainly saw to that. The scariest thing that ever happened to me in New York, actually, was walking in parallel to Richard Simmons on Sixth Avenue on the way to the PATH station. Now that was scary.

In 1992, I am sitting in front of my new computer, trying to learn the intricacies of this Solaris operating system before me, which is what the IEEE used to compose its Transactions. The publishing software loaded on this Sun Workstation was something called Arbortext Publisher and at this time was ticking me off.

Arbortext Publisher used these newfangled doohickies called SGML and TeX (at least, new to me) to put together a document instead using a straight WYSIWYG system like the Ventura Publisher application I was used to. For the first few days, I was in Hell, using these stupid SGML tag whatchamacallits to format the text of the articles being sent in by learned professors from around the world. Being engineering articles, many of them were loaded with math equations, which precipitated the use of TeX with a Math Editor tool to build the equations sent in from those same learned professors.

But I should not complain too much about working with an SGML-based document editor. After becoming proficient in that markup language, it was a cinch to use HTML later, with its finite number of elements and properties. This was the beginning of my Web experience, as it turned out.

Also along the way, I learned how to use this powerful typesetting language called TeX--and even bought myself a copy of Donald Knuth's TeXbook, which I still have to this day. I found that yes, it is not something for the everyday worker-bee to use. But when you want your documents to be typeset as hyper-accurately as possible, then by golly, I can think of few better tools.

Today, that spiral-bound TeXbook is sitting on my desk in front of me, as I try to refresh my memory while I use LATeX with this week's word processor,LyX. There are no neo-Nazis outside, just Girl Scouts selling cookies. But the memories are all rushing back to me as I delve into the world of document processing.

Word Processors vs. Document Processors

If you approach LyX from the standpoint of including it in with all of the other word processors, you would be a bit mistaken. It is more of a document processor--less focused on the words than the structure of the document itself.. Applications within this family include the old Arbortext Publisher of my misbegotten youth, Docbook, and Interleaf, to name a very few.

For those of you who are not clear what a document processor is, I'll try to give you the nickel tour. When you put a document together in a word processor, like KOffice or OpenOffice, you will typically type in the text and then go back and add attributes to that text as you need them, like making emphasized words italic or first-level headings 18-pt Helvetica in blue. When all is said and done, the document will look very close to how it will look on the printed page.

When you put a document together inLyX, then you will typically type in the text and then go back and assign styles to that text as you need them, like giving emphasized words an Emphasis style or first-level headings a Heading 1 style. The Emphasis style could be italic and the Heading 1 style 18-pt blue Helvetica and when all is said and done, the document will look very close to how it will look on the printed page.

So, you may ask, what's the difference?

The difference is this: in word processor documents, there is no meaning attached to the attributes that are assigned. Meaning is inferred by the human reader. In document processor documents, meaning is directly assigned to text by style elements, not matter what the physical attributes of those styles may be.

Take italics, for instance. Italics is one of the more frequently used text attributes (in English), since we use it for emphasis and to denote titles of books, movies, etc. I have already used this attribute for multiple reasons in this column. You, as the reader, knew why I was applying this attribute when I did. Or, at least I hope you did.

But the text editor I used to type this column had no way of assigning meaning to the italicized phrases used here. In HTML or a "regular" document, the text is just italic. Nothing more, nothing less. This would be the case if I were using a word processor, too.

In a document processor, the situation is different. I can apply an Emphasis element to sections of text that I want to emphasize. I can apply a BookTitle element to sections of text that form the title of a book. I can also design a document template that says, okay, the Emphasis element will make text appear to be italic, and so will the BookTitle element. But no matter how I make them look, the Emphasis element will always signal the emphasized text, the title of a book will always be within BookTitle.

The advantages to this leap out at you right off the bat: first, formatting becomes much easier because you can always point the document to a new template and every element's physical attributes will immediately change to that of the template (emphasis as bold, for example). No finding and replacing, just a smooth transition to the new stylesheet.

A lot of this may sound like working with HTML and CSS technology, and there are parallel advantages. But the second major advantage to having a document structured in this manner goes beyond the look of the document. It derives from the content of the document itself. By tagging individual elements of the document, you give an enormous amount of power to those who must index and maintain such documents. Not only is text saved, but the text's meaning is recorded too. So, you can very easily create a search tool that will give you all instances of articles with Brian Proffitt as the author but ignore all of the articles where Brian Proffitt is mentioned a a blithering idiot.

Not that there are all that many of the latter, mind you.

This is the kind of ability LyX and LaTeX will give you when you use it. But how does the application itself run?

Playing Some Mean LyX

LyX is pretty easy to get a hold of, when you want it. You can point your FTP client to the LyX FTP site and grab tarballs and RPMs of the binaries and source of the latest version in a snap. The RPM I downloaded forLyX 1.1.6fix3, which is the latest stable version, came in at a easy to swallow 3.8 Mb, so it's not a monster to download at all.

Once you get LyX up and running, you will be pleasantly welcomed by an application with a clean interface and smart layout. In a few minutes, however, you may be scratching your head and wondering what the heck to do next.

Even for someone who's had exposure to this type of application, the simple LyX interface will initially offer few clues on how to put a document together. Pure word-processing mavens may completely choke on it and label the application as unusable.

That's because this application uses a completely different method of setting documents up than a word processor. If you try to hold it to the same standards as a word processor, yes, you will be disappointed. So, you need to throw out all of your preconceptions right at the get-go and start treating LyX as something different.

The best way to begin with LyX is to read its well put-together documentation that comes with the application. Notice I did not say review, nor peruse. I said read, and I meant it. It is not a situation where LyX is overly complicated. On the contrary, once you adapt to the LyX Way, the application is pretty simple to use. It's just that you will need to know the LyX approach to doing things.

One big, big change for word-processor users is going to be the complete separation of what's in the document and how the document will look. The main workscreen of LyX is where you enter the content and frame the styles for the text. If you want to see how the document will look, you have to call up a separate display window, which will show the document in the native DVI format, PostScript, HTML, or PDF. This takes a bit of getting used to, since many of us are so used to instant gratification with font style applications. In LyX, you have to wait for a while for the document to be displayed as it will appear in the final format.

How long depends on the target format. I displayed a test document in DVI and it took a very long time to initially open the display window. Once the document was displayed, however, then any changes I made in the content window would be instantly shown in the display window--after I clicked the Update button in the display window. This manual updating is something else that takes getting used to.

I do not point these features out as criticisms of LyX. Rather, they are meant to be realistic guidelines for what LyX will and will not do. With all of these different paradigms, would I recommend LyX to a word-processor junkie? Probably not. But would I recommend it to an IT staff that needed to do some serious documentation work for their company? You bet your sweet bippy, I would!

As far as interoperability is concerned, LyX is available both on Linux and Win32 systems, and can produce documents within the PDF and HTML formats. There is a Word import feature in LyX, but it did not work on my Linux machine.

LyX will never be the ultimate replacement for a word processor, although its got some of the same tools, like spell checking. But for superior document creation, LyX moves way beyond word processing, with excellent figure and table management (though table creation is not for the faint of heart). Not to mention very powerful table of contents and indexing tools. LyX is designed to create professional documents, and that's the area in which it will certainly excel.

Beyond its innate abilities, Bjønnes has one more interesting feature for Linux users: the ability to present the same interface no matter what desktop environment is running. Known as GUI Independence (GUII), this feature will enable LyX to be right at home on KDE, GNOME, or whatever. And GUII is one of the main focuses of the LyX developers, with whom I conversed earlier this week.

Interview with the LyX Gang

Normally when I conduct an interview about a certain product, I get a hold of one or two of the main developers, who politely answer my questions via e-mail, phone, or ICQ. In this case, I tendered my request to Lars Gullik Bjønnes for an interview. Bjønnes, being swamped, kindly forwarded me on to the LyX developer's mailing list.

The LyX setup is pretty typical for an open source development project. There are around five core developers, with anywhere from 10-20 people working on the periphery of the project. Beyond that, according to GUII developer John Levon, there are "lots of other people with occasional fixes and, crucially, bug reports."

Working with the GUII is Levon's focus, particularly with the Qt2 front-end. Levon sees the project's primary strategy as "flexibly supporting the internal interfaces, with the minimum of duplicated code, and maximum ease of implementation for the UI coders," he explained.

"For example," Levon continued, "the dialog GUII code is currently in a very nice state--I can implement and test a dialog very quickly for Qt2, as I don't have to
concern myself much with LyX internals. The architecture is such that it enables me to concentrate more on the interface design than tedious interface code"

Other developers on the project agree that GUII is a main focus of LYX for now. The project has been some part of LyX even before KLyX, the proposed shift of LyX to the KDE environment.

"GUII makes you think beyond the limits of your favorite toolkit. It makes you think beyond a simple port to an alternate toolkit, which is what happened with KLyX and what several people wanted to do for a GNOME/GTK+ port. GUII is a very large step toward platform/system independence," said Allan Rae, who has been a LyX core developer since 1997.

Many of the developers agree that the dialog boxes within LyX are in good shape as far as GUI independence, and I would definitely concur. Retired LyX core developer Asger Alstrup outlined the remaining tasks for the GUII project: "The next task for GUII is the main window. This window is composed of a menu, a toolbar, the work-area and the status bar. The main challenge at this point is the work-area. Some work has been done in this area, such as implementing an abstract painter, but the task of handling user interaction has yet to be tackled."

Beyond GUII, the LyX developers are clearly not letting the rest of the program's features languish. Features from better read-only document handling to a thesaurus in the upcoming version 1.2.0. The developers are also looking at adding some features, such as character styles, which would give LyX better compatibility with Docbook.

LyX is something that you will want to look at if you have a real need to start managing your documentation in a highly structured way.

Available from: http://www.lyx.org/
Versions reviewed: LyX 1.1.6fix3 for Linux
License: "Quasi-GPL"
Cost: Free