From: Vitaly O. <vy...@vz...> - 2003-07-02 11:04:12
|
On Wed, 2 Jul 2003 17:51:21 +0800 James Devenish <j-d...@us...> wrote: > In message <m3a...@wi...> > on Tue, Jul 01, 2003 at 03:57:53PM +0200, Torsten Bronger > wrote: > > Do you mean something like > > <http://xml.coverpages.org/unicodeRahtz19981008.xml>? > > If anyone knows how to use this and would like to write notes > about how it can be used with DB2LaTeX, feel free ;-) 1. License of this file and terms of using. 2. Transform this file to form like latex.mapping.xml (replace unicode numbers by their entities). Easy. 3. Include result of transform in latex.mapping.xml and use it with other replacements of special LaTeX symbols. > In message <200...@vz...> > on Tue, Jul 01, 2003 at 04:45:13PM +0400, Vitaly Ostanin wrote: > > What you think about creating xml file for symbols and > > replacements? Such xml will easy contributed and maintained > > for generating xslt from it. > [...] > > I already fix normalize-scape.mod.xml for using > > latex.mapping.xml and it worked. > > I, too, would like to have had this. But DocBook XSL > stylesheets, in general, are slow enough already. The problem > with using a recursive template is that it can easily increase > processing time by a factor of five. You right, modified style is slow, but XSLT is not for speed. > Yet it only benefits developers. So I dropped the idea. > > However, thanks to your prompting, perhaps we can come to a > compromise: we will still use the long, monolithic "scape" > template but it will be generated from a mapping file (not > hand-coded). I'm not sure, that is the right way. > > LaTeX doesn't support unicode characters by their numbers, > > so each character need to be translated into valid latex. > > I haven't found that to be possible (but I'm not an XSLT > expert). It's easily doing with characters mapping, without any extensions. And base for it already exists: http://xml.coverpages.org/unicodeRahtz19981008.xml > If you have any idea how to do this portably in XSLT > without using extensions, I would really love to know. If you > have a method that relies on commonly-available extensions, we > could include that as an option. Our current approach is to say > "we can't do this with XSLT, so we'll do it with LaTeX". It's not right. <skipped/> -- Regards, Vyt mailto: vy...@vz... JID: vy...@vz... |