From: <ghaverla
> Huh? It's been a while since I did a DocBook/SVG thing, so maybe > my memory isn't so good. But, as far as DocBook/MathML goes, if > any given page contains math, then the page needs to be presented > to the browser as XML as near as I can tell. I misunderstood the nature of your problem. Yes, you want to return XHTML with proper namespaces to the client if you expect the client to invoke MathML handling. > Are you talking about changing the equations and images that > MathML and SVG describe into bitmaps, and then presenting a HTML > document which includes images? Some inline, some not. If I had to build one today and I needed to hit machines and browsers > 18 months old, I would, but I am shy of plug-ins in general. > Maybe I > am just too old, but how I interpret things is that neither MathML > or SVG should be understood by a HTML browser. That the browser > must be an XML browser (or a browser which thinks the source > document is XML, including XHTML). Yet in all likelihood the client environment for the foreseeable future is HTML based with plugged support for specialized rendering tasks. > The makefile is using xsltproc to generate HTML4 from XML using > stylesheets. You can make xsltproc produce XHTML directly: http://supportweb.cs.bham.ac.uk/documentation/tutorials/docsystem/build/tutorials/docbooksys/segmentedhtml/ch05s03.html You may need to modify the docbook XSL to honor the mathML namespace. You would redefine the default template for match="*" to directly pass-through any markup in that NS. > ;-) Statistical > mechanics seems much easier than a lot of this XML stuff. Some folks do like to make it seem harder than it is. XML is for users. There's my acronym for today: XIFU. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
