Re: DOCBOOK: new [open]jade problem...

[Arrigo Benedetti <arrigo@vision.caltech.edu>]

Colin Paul Adams <colin@colina.demon.co.uk> writes:

> >>>>> "Arrigo" == Arrigo Benedetti <arrigo@vision.caltech.edu> writes:
> 
>     Arrigo> something that I want to try later today is to have the
>     Arrigo> catalog point to the iso_lat1.ent ISO entity and so on for
>     Arrigo> ISO Latin2 and the other entities which are distributed by
>     Arrigo> Norman Walsh with the XML DTD.  By default under redhat
>     Arrigo> the catalog point to ISOlat which looks quite
>     Arrigo> different. ISOlat1 is for SGML, not XML: this could be the
>     Arrigo> cause of our problems. I'll let you know,
> 
> Well, I tried editing the iso_lat2.ent file to change the line for
> omacr (a Latin-4 character) to be the same as in the ISOlat2 file. The result is quite
> interesting:
> 
> 1) Jade no longer emits the error message.
> 2) The correct character appears in the pdf file
> 3) No character at all appears in the html file, if you view it with
> the UTF-8 character set, and rubbish appears if you view using the
> Latin-1 character set.
> 

I just reproduced your result. I think that this confirms that for some reason
openjade is not parsing the entities file in XML mode. I also get:

openjade:/usr/local/sgml/db154/docbook/print/../common/dbl1ptbr.ent:73:23:E: non SGML character number 65533

What is strange is that onsgmls can parse the XML document just fine:

onsgmls -s /usr/local/sgml/db154/docbook/test/xml/xml.dcl test.xml
[arrigo@cube ~/xml]$ 

I also verified that onsgmls and openjade are linked aginst the same OpenSP library:

[arrigo@cube ~/xml]$ ldd `which onsgmls`
        libosp.so.2 => /usr/local/lib/libosp.so.2 (0x40015000)
[arrigo@cube ~/xml]$ ldd `which openjade`
        libosp.so.2 => /usr/local/lib/libosp.so.2 (0x40333000)

The hunt goes on...

-Arrigo