Re: ANNOUCE: gTrouble - New project [summary]

[Warren Young <tangent cyberport com>]

Tom Gilbert wrote:
> 
> So would it be helpful for us to create an xml syntax/dtd for
> interactive help, which other programs/environments to use, and create
> an interface to it in the new help-browser?
> Is there an existing syntax we can use without restricting
> flexibility. (Don't forget my previous example was most basic).
> 
> Or should we create a library for the rendering of the xml, and the
> running of built-in tests, and allow other environments to use this?
> How far do we go? Is this worthwhile?
> (I really want to supply a library of tests for guide-writers, its much
> easier to check the existance of a file / query an rpm  automatically
> than ask user to go looking for it. Others may think this is not a
> necessary feature.)

I think the main thing about XML from a documentation standpoint would
be the ability to change the layout by redefining the meaning of the
various tags, a la HTML/CSS.

I think the main problem with the current GNOME help browser is that
it's not as powerful as a web browser, and not interoperable.  I think
we should use Netscape's free Gecko rendering engine as the core of a
new help browser.

Now I hear the complaints already: HTML as currently implemented by
Everybody (tm) implies a particular layout.  Well, not really.  The
source documentation could be in a format like SGML/DocBook or XML, and
then translated into HTML/CSS for display, based on some rule set.  

Example: I want top-level headings to be 18-point bold red serif text,
second-level headings to be blue bold italic 14-point serif text
indented by 5 points, and the body text to be black 12-point Roman serif
text, indented 40 points from the left margin with 10 points of leading
between it and the nearest header.

This is all accomplishable with Gecko and suitable translation tools. 
Best of all, it lets us put the same docs on the GNOME.org pages as we
display in the desktop environment.

It seems to me that everyone talks about XML, but no one's using it for
display.  I think it's more of a middleware technology: a way to move
data in a presentation-independent way.  When you need to present it in
a specific way, you translate it into another format, rather than use it
directly.

That brings me to another point: the translation step from XML could be
deferred until display time.  The docs could remain in XML until they're
viewed, when they're translated to HTML based on rules the _user_
chooses via the help viewer's configuration dialogs.  

Think Unix man pages here: format at the last minute, possibly caching
the result.  If the display settings change (I want top level headings
green now, not red), the cache is flushed, causing docs to be
re-rendered with the new settings.

The main thing is that this should be fairly easy to string together,
because it's based on existing tools, for the most part.  It's all glue
work.

Am I volunteering?  Sorry, no: I've got other free projects going right
now...
-- 
= Warren Young: www.cyberport.com/~tangent |   Yesterday it worked.
= ICBM Address: 36.8274040N, 108.0204086W, | Today it is not working.
=               alt. 1714m                 |   Windows is like that.