[Top][All Lists]

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

[help-texinfo] Re: texinfo.xsl not working

From: R. Mattes
Subject: [help-texinfo] Re: texinfo.xsl not working
Date: Thu, 02 Jun 2005 17:02:04 +0200
User-agent: Pan/ (As She Crawled Across the Table (Debian GNU/Linux))

On Thu, 02 Jun 2005 09:46:52 +0200, Torsten Bronger wrote:

> Hallöchen!
> "R. Mattes" <address@hidden> writes:
>> [...]
>> Well, as i said: footnote handling would be a good first candidate.
>> Indexing and crossreferences as well.
> Now we are talking about XSL formatting? 

Transformation, not formatting.

>  To be honest, I don't
> consider it a significant backend yet.  We still lack a good free
> XSL processor, and last time I checked, development was very slow.

??? Where did you look? LibXSLT comes with a _very_ good xslt processor
(and has been arround for quite some time now). Not to mention the java
ones ...

>> I usually prefer "chunked" output so larger manuals don't kill my
>> browser.
> Now we are talking about HTML output of makeinfo?

No, all of my mail refers to the transformation of makeinfo's XML
output by means of the xsl stylesheet in the texinfo distribution.
>> I'm not too happy with the xml current output: i'd expect an
>> encoding attribute in the xml declaration (or, even better, a
>> commandline switch to configure the encoding attribute). I really
>> don't think there's a place for all theses special entities that
>> duplicate characters easily available in ISO-8859-1 and Unicode.
> All this is not necessary in my opinion, because UTF-8 is the
> default with makeinfo's ASCII being a real subset.  

What are you talking about? Makeinfo unfortunately does not enforce any
restrictions on the character encoding. Any 8bit character in the
textinfo source gets passed ito the XML output as is. 
> Besides, the XML
> output is not intended for human eyes and XML parsers don't care at all.

So they say. As i already wrote the use of character entities (besides the
ones defined in the XML standard) requires parsers to be able to read (and
find!) the defining DTD. Given that all except two (sic!) entities are
just named characters entites that looks like extreme overkill. Almost
looks like someone got carried away by this feature :-)
Note: this is _not_ HTML 1.0 that inherited from SGML the requirement to
be 7bit clean in certain environments. 

 Argh, i just had a look at the texinfo.dtd:


 <!ENTITY ellipsis   ""> 
 <!ENTITY lt         ""> 
 <!ENTITY gt         "">
 <!ENTITY bullet     "">
 <!ENTITY copyright  "">
 <!ENTITY registered "">
 <!ENTITY minus      "">
 <!ENTITY linebreak  "">
 <!ENTITY space      "">
 <!ENTITY dots       "">
 <!ENTITY enddots    "">
 <!ENTITY amp        "">
 <!ENTITY ldquo      "">
 <!ENTITY rdquo      "">
 <!ENTITY mdash      "">
 <!ENTITY ndash      "">
 <!ENTITY period     "">
 <!ENTITY eosperiod  "">

VERY smart, indeed!
So, instead of taking advantage of the fact that Unicode has codepoints
for almost(?) all these characters they just got removed from the XML

> [...] What i really need to find out is whether the XML output
>> looses information that's present in the original texinfo file.
> Karl mentioned missing tags; there are a few, but they are minor. This
> behaviour is not intended, however, the following is (it has been
> discussed here, though):
> Conditionals (@iftex etc) are lost if they didn't match.  This is a
> problem because XML output can be used for any medium, so the filtering
> should take place while processing the XML, not earlier.
> Some text is generated by makeinfo ("See ...") although it doesn't
> appear in the Texinfo source.  If you want to have a different text
> (e.g. "Have a look at ...") you have to do *very* awkward things, and it
> may break.
> Some Texinfo tag groups (e.g. definition tags and cross reference tags)
> lead to the same XML element, and any information about the original is
> lost.

I'll have a look at the makeinfo sources later, i first concentrate on a
working XSLT sheet (and fix those broken entities ..)

Cheers Ralf Mattes

> Tschö,
> Torsten.

reply via email to

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