[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A new online publishing tool for Texinfo documents.

From: Juri Linkov
Subject: Re: A new online publishing tool for Texinfo documents.
Date: Mon, 24 Nov 2003 09:57:59 +0200
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

Nic Ferrier <address@hidden> writes:
> address@hidden (Karl Berry) writes:
>> At that time, I stated (and still believe) that starting with the
>> makeinfo XML output would be much better and easier than turning Info
>> format into some kind of ersatz XML/HTML.  So I'm very happy to see this
>> proposal :).
> I think that's true as well. I'm considering some work to make
> libxml2 (which provides xsltproc) available as part of Emacs. This
> would make using it very simple indeed.

Making some XML library available as part of Emacs might be useful.
Current XML parsing implemented in Emacs Lisp is too slow on large
XML files.  But maybe building a DOM tree from makeinfo XML output
is not needed at all.  This might be needed for XML transformation,
e.g. for reordering the Info nodes.  But for simple text formatting
a simple sequential SAX-like processor should be enough.  It could
provide, for instance, the following hooks:

(defun xml-start-element (name atts))

(defun xml-characters (str)
  (insert str))

(defun xml-end-element (name from to)
  ;; this could be used to format the inserted text
  (cond ((equal name "para"))
         (fill-region-as-paragraph from to)))

>> Here are other comments.
>>     alter makeinfo --xml so that it splits the XML by Texinfo
>> I am no xml expert, but I'm not sure that is necessary or desirable,
>> since the only thing that will read the XML is other scripts.  It is the
>> specialized HTML that needs to be split.  And even then, split nodes are
>> just one possible outcome.  There are xref issues here, which Patrice
>> Dumas and I have hashed over at some length.  Anyway, all that is a
>> technical detail.
> It's not necessary because you can easily chunk XML with
> XSLT. However, I think it's desirable because it's what one might
> expect...
> But this could certainly warrant further discussion. I'm not going to
> do it straight away, I'll be using XSLT to do my chunking initially.

It's better not to split a XML file, because splitting it to many files
will complicate the processing of XML structure as a whole.

>> JavaScript is the only standard way to do browser-side programming that
>> I know of.  It may turn out that only a small subset of JavaScript is
>> actually needed for the job, that wouldn't be as painful to add to Emacs
>> and Lynx as the whole huge mess.
> Whatever, as you say, because Emacs is so adaptable we can achieve
> something. It's just "what thing" which is important.

JavaScript is mostly useful for web applications supposed to run in
mainstream browsers.  But for such browsers HTML files is already
good enough solution.  What is rather needed is to improve Emacs
Info browser.  Currently I see at least three ways to do it:

1. continue to hack existing info.el to overcome existing limitations
   of Info format;
2. extend existing Web browser implemented in Emacs for better support
   of Info HTML navigation;
3. try to use an additional XML format in Emacs;


reply via email to

[Prev in Thread] Current Thread [Next in Thread]