Toby wrote: > Yes ... but XSLT works best if the output target format > is some form of XML. So it's quite easy to get it > to produce CML, but (quite reasonably) it gives you > no control over meaningless syntactical details like > newline placement.
OK > It's enormously more difficult to get it to produce CML > where every newline is accompanied by a backslash to > allow for Javascript string literals. Your CML does not need to contain any newline characters. You can use spaces instead. That eliminates the backslash problem. > I'd have to tell > the XSLT to output in plaintext format, and > build up the entire output character by character, > without any notion of XML well-formedness in the XSLT, > which makes it much more difficult to ensure that the > output is valid. How about this ... Get everything to work with the CML as a single character string on one line with no newline characters. Jmol will not have any problems reading the entire CML as a single unbroken string with no newline chars. You can confirm this by outputting an intermediate file with no JavaScript itself does not have any limitations on string length The place where I would be wary/cautious is with the JavaScript parser. It *might* get upset if a string literal that is really long. But you certainly can have lines of a few thousand chars without any problem. So, at the beginning work with a relatively small molecule of, a few dozen atoms. Once that is working, try with one of your largest molecules. If the JavaScript lexical parser dies on a large atom with a single string literal of 100K chars then try the following ... You do not need to use the backslash technique. Try using separate quoted string that are concatenated together. "beginning string" + "many middle strings" + "the end" Just break up the string constants when you get to atom elements. Every time you see an 'atom' element or a 'bond' element just close the previous string literal and start a new one by outputting: " + " or, even better " +\n" I have never used xslt, but it seems impossible to me that it would not allow you to output a user-controlled text string when it encounters an element of a specific type. >> Taking a step back ... why aren't you just reading the CML file out of >> your database rather than trying to stick it inline? > > Erm - no database involved. This is from the output > of some computer simulations. 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 >> So, just do both ... stick it inline for your application but let Jmol >> read it out of your database through a separate URL reference. > > Firstly, I don't like having duplicated information > if I can at all avoid it. Secondly, I have it working > at the moment using an external reference; but for > various reasons, my life would be much easier if I > only had to deal with a single file. > > But thanks for your help anyway. I'll see what I can do > with Javascript rewriting. Good luck! 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
