Brian McMahon wrote:
> Dear Jmol users
>
> The International Union of Crystallography has been developing a system
> to allow authors to publish interactive figures using Jmol in IUCr
> journals. This system is almost ready to go live as a beta release
> to our authors.
>
> You are invited to preview and comment on the Jmol authoring toolkit
> that will form part of this service. This preview version is available
> at http://sandbox.iucr.org/jtktalpha
>
> Feel free to upload structures in CIF format to test this toolkit.
> You will find that saving your edits will take a very long time;
> the demonstration machine is a very low-powered one and struggles to
> render the saved view (the server that our authors will use is
> much faster). Nevertheless, you may find it interesting to explore
> the way that the interface is intended to work.
>
Brian, I have taken a (rather short) look at the interface and it looks
like a nice piece of work!
Of course I am not a novice user because I have developed a quite
complex Jmol interface myself. So I cannot really judge if it will be
too complicated for non-expert users. (But at least it doesn't seem to
be too complicated.)
A few remarks (Test system: Firefox 2.0.0.10, SuSE Linux 10.2):
1) The text in the tab-like boxes ("general", "crystallography", etc.)
overlaps between several rows. You should try to avoid that.
2) You should also try to avoid that one of these boxes (in my case
"checkbox scripts") is splitted up between 2 rows.
3) These boxes also had a problem with font size changes. After I
increased the font size the boxes were not wrapped correctly. Instead
some of them left the green section into the white area. This looked
really strange.
4) After storing the figure and getting the output a long "button
script" caption text was wrapped. This didn't look very well because the
text in the second row started directly below the button. You could
avoid this for example by using a table for the buttons and their captions.
5) I don't think that the 3-Frame solution for displaying the result
after saving the figure is a very good choice. This makes it very
complicated to get a good impression of the results because you can only
see a small part at once. And you can also not test the applet and the
controls very well because you have to scroll permanently. Why don't you
just put all 3 in a single frame, separated for example by a header
indicating the sections?
> The application will be integrated seamlessly into our submission
> and review system. Authors may create enhanced figures and make them
> accessible to referees as part of normal peer review. After
> acceptance, the enhanced figure is automatically managed within the
> electronic journal workflow. The initial rendering is saved as a TIFF
> image for incorporation in the PDF of the article (this is why I
> have a need to obtain, say, 300 dpi resolution output from jmol).
>
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.
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?
Q: How did you solve the font scaling problem?
Regards,
Rolf
-------------------------------------------------------------------------
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
