Could lyx be an an alternative although it is not WYSIWYG it is WYMIWYG (What You Mean Is What You Get) -- Togan Muftuoglu

"Steven T. Hatton" wrote:

On Sunday 25 February 2001 14:07, Togan Muftuoglu wrote:

...

Could lyx be an an alternative although it is not WYSIWYG it is WYMIWYG (What You Mean Is What You Get) Togan,

Outstanding question! LyX didn't provide full SGML/XML docbook support the last time I checked. It does have LDP support, and some other SGML capabilities as well.

from http://www.lyx.org/about/features.php3 Current features are: Graphical User Interface that gives access to all functions via menus and mouse, as well as configurable keybindings Standard word processor operations, like cut/paste, multiple open documents, infinite undo/redo, spellchecking (uses ispell in the background) Different textclasses allow you to type letters, articles, books, movie scripts, LinuxDoc, slides. Also included are some textclasses for scientific societies, such as AMS, APS, IEEE, or specific journals like Astronomy and Astrophysics. Numbered section headings, table of contents (with hypertext functionality), nested lists (aka "outline mode") Interactive WYSIWYG math editor Support for writing documents in most European languages, as well as Right-to-Left languages like Hebrew and Arabic, including multi-lingual documents. Postscript® figures, with rotation, scaling, and captions Interactive WYSIWYG tables Footnotes and margin notes Labels/references and bibliography (including BibTeX support) Access to all LaTeX functionality with plain-latex-style Import LaTeX. Export LaTeX, Postscript®, DVI, ASCII, or send a fax SGML-tools support (both LinuxDoc and DocBook DTDs) Literate programming support, via the "noweb" tool. Menus, error messages, and keybindings are available in many languages Extensive documentation, including a beginner's tutorial. Some docs have been translated from English. Quite fast and no memory hog at all. A lot more... Check it out!

Steve

-- To unsubscribe send e-mail to suse-linux-e-unsubscribe@suse.com For additional commands send e-mail to suse-linux-e-help@suse.com Also check the FAQ at http://www.suse.com/support/faq

-- Togan Muftuoglu

I love LyX, it is one of my favorite software and I've used it for more than a year now. But the version included in SuSE 7.0 is giving me some headache; sometimes it changes the layout between sessions, somtimes it even wipes out a couple of lines of text also in the beginnig of several paragraphs. This can be terribly frustrating and it's made me starting to look for another alternative, but I don't find any. Has anyone else been having these problems with LyX? On Sunday 25 February 2001 22:04, Steven T. Hatton wrote:

Togan,

LyX has many capabilities, and is fairly easy to use once you READ THE TUTORIAL. I'm not sure what DocBook DTD support actually means in the quote above. What most people want, or expect is that they will be able to type in their text, select the tags to indicate the 'meta-meaning' of the text, and then see the text displayed in a way that meaningfully represents that meta-meaning. IIRC, that is not exactly what happens with LyX.

SuSE Linux comes with extremely powerfull desktop publishing capabilities which are, unfortunately, also extremely hard to use. LyX is one of the best tools for utilizing these capabilities. I am glad you brought it up. I would very much like to see it grow. FWIW take a look at this ftp://ftp.kde.org/pub/ . I find it interesting that LyX has such a prominant place in the file structure.

If anybody trys to use LyX and finds it very unintuitive then they probably did not READ THE TUTORIAL.

Steve

-- @~~ EagleIce ~ gnu4u@linux.nu ~~@ @~~ Running GNU/Linux & KDE ~~@

On Sunday 25 February 2001 20:31, Jethro Cramp wrote:

Docbook is something that I was perusing last week in my search for the ultimate document format (still looking).

I came across the following tools which I haven't had time to take a good look at yet but might be worth further investigation:

http://www.alphaworks.ibm.com/tech/xeena

http://www.conglomerate.org/

Most of the projects that I found on Sourceforge or Freshmeat when I searched for "Docbook" were in the very early stages of development. If you search for "XML editor" you get a *lot* of hits.

Conglomerate looks like a very interesting project.

Bye,

Jethro

Jethro, If you already know what I'm about to say, please foregive me my assumption that you are at the stage I was in my second week of researching this subject. The way I see things is DocBook is a markup standard for technical documentation. It's not dissimilar to the traditional conventions used by publishers to markup text for the type setter. I don't fully understand how all these things relate, but, as I understand things, there are markup languages such as XML or SGML(the predecessor of XML) and there are display languages such as DSSSL, FOSI, CSS, and XSL. Ideally the markup language should not dictate any specifics of how the contents of a document should be displayed. The markup language should only indicate the category of the element it tags. For example, a <title>here be the title</title> tag tells the processor that the content of the element "here be the title" is to be treated as a title. It dose not indicate whether titles should be bold, underlined, indented or otherwise specially rendered. Such rendering information is the domain of the style sheet language. In order to convert raw document content into a final product on first needs a markup convention (DocBook) expressed in some markup language (XML.) This markup language convention is then applied to the raw text by some means. Currently that means is, more often than not, manual editing or through the use of 'privative' pick lists. Once the raw document is marked up, it can then be submitted to the rendering tool (XT) which processes the marked up material in accordance with instructions encoded in a style sheet using a style sheet language (XSL). Of course the final product of this is likely in xhtml or postscript which must be further processed before it generates the actual images which hit our retina and are then processed by our brains. (I'll forego that detail for now.) The problem I have encountered is that there seems to be not product which nicely takes one the from beginning to the end of this process. Currently we must either accept the style sheets available or create our own using primatives tools which do not connect the author directly to the results of his or her work. XMetal is on of the better products I have encountered in this regard. Unfortunately it only runs on one operating system. Steve

On Monday 26 February 2001 03:32, Jethro Cramp wrote:

On Monday, February 26th Steven T. Hatton wrote:

...

If you already know what I'm about to say, please foregive me my assumption that you are at the stage I was in my second week of researching this subject.

No need to be so polite <smile>.

Jethro, I am a bit to tired to think hard about this, but I do have a few thoughts on this.

a) Store the document data separate from the presentation (so that it could be parsed using python for other processes) but not in a relational database. b) Take the document data and display it in a number of formats (HTML, PDF). Have you looked at http://xml.apache.org or http://www.enhydra.org ?

Mark up languages and the display mechanisms (DSSSL, FOSI, CSS and XSL) should solve this problem. However these technologies come with their own set of problems:

1) Complexity. 2) Standards and tools are not yet very mature. There are some nice tools at http://www.extensibility.com/ I found the XML Instance and XML Authority to be usefull. Cannon may also be of interest to you.

What of course we are all looking for is a tool that is going to hide all the complexity from us and produce perfectly formatted documents in the right format at the right time.

Dude, that's called a secratery! Oh well, I guess I should start picking out a grave stone after that statement?

There are as you pointed out 2 parts to this process, the creation of the document and the viewing of it. As you also pointed out the options on Linux are very limited. I haven't used XMetal on Windows but I would guess that it is able to do the round trip: take a XML specification, write a document, apply a formatting document to it and then view the output.

IIRC you can read in the DTD get the picklist one would expect, and get a fairly WYSIWYG interface. That is, after you create the DocBook or other CSS. I believe it will produce the html as well. It was not capable of directly converting to well formatted hardcopy. I'm not sure of the state of this product or what it may truly be capable of: http://activestate.com/Products/Komodo/index.html I looked at it months ago on NT and it was very crash happy. I see they now have a Linux alpha. It looked very promising. It's founded on Mozilla a fact which I really like.

In document creation people are used to the WYSIWYG approach of modern wordprocessors. It's very hard and not necessarily desireable to implement markup documents in a WYSIWYG format. However if you can't see what your document looks like when you're creating it how do you know if you are achieving the affect you want? That comes down to how well designed the formatting template is and how well integrated it is to the markup template. This is fine for big projects and books but the time required to create and debug a markup template and its' formatting template for small projects make the process inconvenient.

This is very true. I have resolved myself to the fact that I simply have to toughen up and deal with the awkwardness of editing in markup a bit, run it through the renderer and then view it. It really isn't *that* bad. The effort I put into avoiding doing this was not worth the return. One tool, http://xml.apache.org/cocoon/index.html seemed to hold a lot of promise. It had a rudamentary DockBook XSL style sheet which was as impressive as it was incomplete.

On the Conglomerate site they have a couple of articles that are worth reading:

http://www.conglomerate.org/docs/death_of_wysiwyg.html http://www.conglomerate.org/intro.html

I'll have to look at this when I wake up. If I'm alive.

The first is their view on WYSIWYG documents versus marked up documents. The second is an intro to what they are trying to do about the problem

At the moment I think that the best strategy on Linux at the moment is:

1. Find an editor which accepts an XML template (Docbook template) and has a convenient 'pick-list' for tags and validates your document as you write it. As you pointed out this is not ideal, but it is a step up from coding by hand. Also you have to be familiar with the Docbook spec.

(X)Emacs can do this, but I found it quite challenging to learn. The Extensibility products can also support this. In particular the XML Instance supports XML validation. But it is not the greatest UI. All of these products seem to originate, to some, extent from these guys: http://cseng.aw.com/book/0,3828,0201485435,00.html I got a good laugh out of the fact that the correct output of their first example was nothing. I do believe there was intended humor in that.

2. To view the document in your chosen format use sgml-tools Lite which is a set of utilities, coded in python, for taking a docbook document and outputting to HTML (2 styles), JadeTeX, DVI, RTF, PS, PDF, plain text, and PalmOS iSilo formats. (The homepage is: http://sgmltools-lite.sourceforge.net)

Something tells me there is some kind of interference between sgmltools-lit and something in the SuSE distribution. I can't think of it right now. I seem to remember installing sgmltools-lite and regretting it.

I can't think of any superior way of writing documents at the moment. A Docbook / XML plug-in for KWord would be a cool project. I guess it is something that will probably get done in the future.

All the documentation in the KDE2.x, AFAIK, is DocBook based. Their sites may be well worth exploring if you haven't already. LyX does support the DocBook/LinuxDoc subset.

My requirements are slightly easier - I'm (trying) to build an application using ZOPE and the users (my clients) fill in some forms (inquiries and orders) and then my program automatically creates documents using a markup language and then depending on where the client needs to see the information (either on the web in HTML or by e-mail in which case a pdf file) the correct output is presented to them.

Thanks for your mail.

Jethro

Well I've probably given you many more distractions than you really needed. I found myself continually find a product that seemed to be great and then hitting a limitation I was not expecting. For example, the last I checked, psgml in (X)Emacs did not support XML name spaces. Please forgive any misspelling. My KDE2.1 current build is not supporting spell checking tonight, and my brain never has. Steve