>> Your CML does not need to contain any newline characters. You can use >> spaces instead. That eliminates the backslash problem. > > But I have no control over newline placement!!! Maybe > I'm not being clear. When I say I don't have control, > I mean that the xslt processor is at liberty to stick > as many or as few newlines into the output as it chooses; > and furthermore that in practice, it will.
OK, I hear you this time :-) > Even if I use your ides of outputting an additional '"+\n"' > every time I encounter a <atom> tag (which is indeed easy to > do) I still can't stop it putting linebreaks in the middle of > tags. Understood. > This is inherent in the nature of xslt in its XML output > mode. Even if I could find a way to force one particular > xslt processor to behave correctly, there's no way I can > work out how to do it for every conceivable xslt processor. > Newline placement in XML is syntactically meaningless, so > xslt offers no guarantees. OK >> Ummm ... now I am a little confused. >> If you are outputting from a *program* then it sure seems to me that you >> have the ability to control the format of the output. >> >> Leave the xslt translation alone. Capture the existing output and run it >> through a filter to clean it up and make it acceptable for JavaScript. >> >> If you are working in Java it should be straightforward. >> >> If you are working in c on a unix box then it will be a little more >> work, >> but you should be able to pipe the xslt output through a filter to dress >> up the CML > > Maybe I should explain better what's going on, and what my > motivation was. > > I have one program (written in Fortran, as it happens), whose output > is entirely in well-formed valid XML. This XML happens to include > various data in which I am interested, and several molecular structures. > > A raw XML document is not the easiest of things to read, so I have > a set of XSLT transforms that massages the output into a mix of > html and cml, which can then be viewed in a web-browser. This allows > one to easily look at the output of calculations with the minimum of > fussing around extracting data. Previously the html & cml were > produced (by the same xslt transform) as separate files, and I ran > the xst transform by hand from the command line every time I wanted > to view an output file. > > The html file produced by the xslt includes several jmol applets for > viewing the cml files produced. This all worked fine. > > What I was trying (and have now succeeded) in doing, was having only > one output file, with the html & cml embedded in a single, > multiple-namespace, xml document. This means that now, the xslt > transform can be performed by an apache module - so I can simply > point my web-browser at the raw output of a calculation, and it > will appear as properly marked-up html with embedded jmol applets, > viewable in my web browser with no further hassle. This makes my > life easier. :-) Good. Glad that you were able to get it worked out using JavaScript. Seems like a shame that you had to jump through so many hoops. Miguel ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
