Re: Changes to Texinfo DTD

[Robert J. Chassell]

Miles Bader <address@hidden> wrote

    The main question in my mind is whether this would be fast enough
    -- the current info mechanism, though it has its problems, can
    display info pages very quickly.

Yes, you are right.  The goal is to provide an alternative to Info
that is as efficient as Info and as fast.

This will help both those who prefer the markup they see in Web
browsers to what they get in Info, and those who use Web browsers,
such as Mozilla, for reading documentation.  (And as a side effect, it
may inspire people to improve W3 mode or another Web browser for
Emacs.)

Right now, it is impossible for any HTML mechanism to be as efficient
as Info, since (as a practical matter) HTML lacks the concept of `one
document in many files'.  HTML runs via a `one document in one file'
schema.  (I am told that in theory a hypertext link can point to one
document that is spread over several files, but I have never seen
this.)

Moreover, a browser, such as Mozilla 1.0, lacks even a regexp search
mechanism for navigating within one page!

However, HTML does have a great advantage over Info: HTML is designed
for the situation in which the rendering computer is separated from the
server by a slow connection.

Info depends on a fast connection between the rendering machine and
the source of the Info file.  Indeed the Info file is often on a disk
on the rendering machine; if not, it is connected via a fast NFS or
similar link.

Here are the two topologies:

Info:
                      fast      rendering       fast
 terminal/display ---  or  ---  computer  --- connection --- Info source
                      slow                      only
                   connection
                                \________ often one computer __________/



HTML:
                                                    fast
                        fast         rendering       or
 terminal/display --- connection --- computer  ---- slow ---- Web server
                                                  connection
  \____________ often one computer __________/

                                     \______ often two computers ______/
                                             connected over the
                                                 Internet


On my current connection, it takes 17 minutes to download the Emacs
Lisp Reference Manual.  There is no way I would wait that long before
beginning to browse the manual remotely.  For remote use, the manual
needs to be divided into smaller files, as Texinfo files are now when
converted to HTML.

Moreover, even with splitting, a search will take too long, unless the
search regexp is sent to the remote site.

I mention search because `Info-search' is still the most efficient way
to navigate through a GNU manual.  String searches through a complete
document (and indices) are very helpful, but simply not good enough.

Consequently, both to help documentation readers who want the kind of
markup they see in a Web browser, and also to help those who want to
read their documentation over the Internet via a slow connection,
current HTML needs to be improved in two ways:

  1. The Texinfo to HTML conversion process needs to ensure that key
     bindings as well as mouse bindings exist for moving from one node
     to another, for index lookups, etc., for a document that is
     spread over several files. 

     Without keybindings, you have to move the mouse, which is fine
     for novices or those who don't mind spending their time doing so,
     but which is not as efficient as simply pressing the spacebar or
     other key, regardless where point is.

     This can be done by providing the document as one or more HTML
     pages, appropriately chunked and formatted and with Javascript
     for the keybindings.  Nothing need be done to the Web server.

  2. The Web server needs a CGI that enables regular expression
     searches/navigation through a single document split among
     several files.  Info has the wonderful `Info-search' command,
     usually bound to `M-s'.  This feature provides the equivalent.

     Since whole documents are often large -- as I said, the Emacs
     Lisp Reference Manual takes me 17 minutes to download -- and HTML
     works by downloading files that are then rendered, the only way
     to provide quick regular expression search and navigation is by
     sending only a search command, such as an `s', to the Web server,
     and having the Web server run the search itself.

     This feature does require adding a module to the Web server.
     This is difficult, since only some Web masters will provide the
     added convenience.  However, it is easy to install CGI scripts on
     Apache.  If the master of the Web server has not installed the
     CGI script, then the Javascript in the Texinfo HTML file tell the
     user that the Web server to which he or she is connected is
     lacking.  And perhaps, eventually, the people who distribute
     Apache will be persuaded to include this module with the others,
     as part of their standard distribution.

I think the far more difficult issue is learning by people who want to
make use of efficient searches and navigation.  Partly, the difference
is preference; but partly the difference is learning.

The kind of efficiency provided by Info is beyond most people's dreams
-- they do not even imagine that an equivalent of `Info-search' could
be useful.  It does not occur them to learn.  Consquently, for many of
the people who want to take advantage of their computer, fundamental
relearning is required.  (For others it is preference, as I said.
Indeed, some people who use Info do not much use `Info-search'.)

On the other hand, Info was not designed for the kind of network we
now have, in which people have their own rendering machines, but
download files from a Web server over a slow connection.  Info was
designed for a network in which the connection between a display or
terminal and the rendering machine may be over a slow connection, but
the connection between the rendering machine and the disk providing
the Info files is fast.

Put another way, both Info and HTML have deficiencies.  The goal here
is make use of HTML's features and add those needed to match Info.

Next, the problem will be to encourage writers to write for all
potential users, not only those who look at documentation on a high
resolution/fast redisplay screen:  to write for people driving cars or
otherwise blind, to write for those working over a really slow
connection, to write for those using limited equipment.

For example, people are going to listen to documents spoken to them
over a cell phone while they drive a car.

Currently, Texinfo files tend to be written for such people, but I see
more and more use of @image without an alternative for those who do
not want images.

But that is a problem for another day.

-- 
    Robert J. Chassell                         Rattlesnake Enterprises
    http://www.rattlesnake.com                  GnuPG Key ID: 004B4AC8
    http://www.teak.cc                             address@hidden