RE: Serving XHTML as XML

> I believe Duxbury are working towards Unicode support,

This may  help with embossing none-western languages, and I believe there is a Unicode page set for Braille, but I don't see how Unicode helps DBT overcome its current weakness with translating HTML.

> This need not be a huge problem; if we have a true (well-formed) XHTML 
> document, we can always feed it through an XSLT translation to convert 
> it into something that Duxbury can handle.  If Duxbury has limitations, 
> these could also be catered for.

If an end user has the ability to code XSLT translation to cater to DBT limitations, they are probably perfectly capable of implementing Braille translation rules on the source document!  Duxbury is actually fairly extensible, I just don't think writing translation tables should be expected of the average customer for something as mainstream as HTML!

> and as you say, XSLT will take any XML through to Duxbury styles,
> using the SGML import feature,
> so XML is probably less of a problem than weak html.

Have either of you tried feeding Duxbury non-trivial but well formed HTML (or XHTML)?  Data tables cells are all run together.  Ordered lists get a similar treatment (but UL is processed correctly).  Strong and EM are ignored while B is handled.  I don't have a comprehensive list because it makes me irrational.  The recommend work-around is to open the HTML document in Word, save as a .doc file, and import that into DBT.  Frightenly enough, this works reasonably well!  How do the open standards advocates feel about that?

Received on Friday, 25 February 2005 14:06:06 UTC