Hi Rolf Thanks for your encouraging remarks. The overlaps and wrapping behaviour of the tab interface are the first gremlins that people notice, and I've passed that on to my JavaScript/CSS guru to see what can be done. Likewise, the frames approach to displaying the static and dynamic pages has been criticised, and I'll look again at that. A more elegant solution might be to just provide a JavaScript toggle to display one or the other. There's probably no need to see them both simultaneously.
> I am not sure if this is some sort of request for high resolution > output, but it is no problem to get this with the Jmol application. At > least I had no problems generating large images, e.g.: 2500x3500 pixel. The problem is - as you go on to point out - with scaling of fonts and other objects, such as unit cell axis widths, where the size is specified in pixels. From the same script I want to create both the online image (at about 100 pixels per inch) and a higher-resolution TIFF (~ 300 ppi). If I simply scale the output width and height to get the TIFF, my fonts are 1/3 the desired size. > Q: How did you solve the font scaling problem? It's not a solved problem. I was hoping Bob would say "Oh, it's just a half-hour's work to provide an export option that will scale all dimensions (in pixels) by a factor of n" :-) Failing that, we will look into post-processing the script to find any size-setting commands and scale them individually; and also to determine default sizes for fonts etc. and scale those defaults globally. > I am especially interested in your image export function. > > Currently we have only client-sided image generation integrated in our > Jmol interface (e.g.: http://www.fli-leibniz.de/3d_mapping.pl?CODE=1deh > ). In our snapshot function the applet generates a base64 encoded JPEG > image that is send with javascript to our server and bounced back to a > new browser window. But this method has two disadvantages. The first is > that there seems to be a size limit for the transfer between the applet > and Javascript. If the image size exceeds a limit, it occurs a security > error. The second disadvantage is that a larger applet size in > combination with antialiasing for the image export might lead to a Java > memory error. > > So maybe your solution of sending the state script to the server and > generating the image at the server side might be an alternative. But > besides the need for extensive testing of the state saving and restoring > there might also be some issues with this solution. Although the state > scripts are coded very efficiently they might also get into the range of > several megabytes for large structures and also lead to a security > error. Another problem of scaling up the image at the server side is the > font size scaling. Since font sizes are not scaled automatically by Jmol > it would be necessary to correct this somehow. > > Q: Did you observe any state script size problems? Not as yet, but our testing has been relatively limited. We're looking forward to this beta test stage to determine exactly how much our authors will be able to get out of this approach. If they can't do something that they would like to, at least they're no worse off than before, when they didn't even have an opportunity to try! Best wishes Brian _________________________________________________________________________ Brian McMahon tel: +44 1244 342878 Research and Development Officer fax: +44 1244 314888 International Union of Crystallography e-mail: [EMAIL PROTECTED] 5 Abbey Square, Chester CH1 2HU, England ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jmol-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-users
