Thanks for this Angel
My task was to effectively "crop" the model so that a static image
could be created that was as large as possible with respect to the
model, but also exactly reflected what would be seen in the applet -
i.e. the static image could be used in e.g. a PDF but scaled to a
'thumbnail' size, but still had minimal margins and still represented
what the associated applet would show.
Anyway, a script such as:
zoom {visible} 0;
rotate best;
refresh;
margin=15;
c=0;
while ({visible}.sx.all.max < _width-margin && {visible}.sx.all.min >
margin && {visible}.sy.all.max < _height-margin &&
{visible}.sy.all.min > margin ) {
zm=100+c;
zoom {visible} @zm;
refresh;
c=c+1;
if (c>100) {break;}
}
echo @c;
achieves this nicely and shows that in many cases there is room for a
zoom of 130+ percent.
Unfortunately, however, the script requires calling 'refresh' in order
to update
the screen coordinates of the model (.sx, .sy), which it seems is not
possible when running the script from the command line to generate a
static image (i.e. running the jmol application with -ionx and the
script contained in an spt file) - which is essential to my task,
which involves automated production of print content and html content
without user intervention.
So at the moment I'm left with having to 'crop' the static images for
print use and reproducing the 'crop' effect in the html versions - not
a major problem, but it would have been nice to have just had the one
image with the load script embedded, etc., which could then be used
for print and html...
Anyway, if anyone has any suggestions regarding running the jmol
application 'headless' with scripts that appear to require an 'event
loop' I'd be very grateful...
Cheers
Simon
Quoting Angel Herráez <angel.herr...@uah.es>:
> Simon,
>
> although you seem to have the solution, I'd like to give my view
>
> As I understand it, "zoom 100" will fit the model in spacefill into
> the window,
> at any rotation angle; maybe yor perception is due to your having a single
> "best" orientation, for which there may be empty margin left.
> I do not think the bounding box has any influence.
> As Eric pointed out, the state of "zoomlarge" is relevant if the Jmol is not
> square.
>
> That said, I am not familiar with your "zoom 0" as it is --although
> it may well
> be correct. This is what I would do:
>
> zoomto 0.01 {visible} 0;
>
> zoomto 0.01 {visible} 0 *1.1; //for a slightly larger model
> zoomto 0.01 {visible} 0 *0.9; //for a slightly smaller model
>
> Those should fit the model to the Jmol window in all cases, for any rotation.
> 0.01 is a time in seconds, which may be reduced to zero
>
> Please see http://chemapps.stolaf.edu/jmol/docs/#zoomto
>
>
> ------------------------------------------------------------------------------
> Go from Idea to Many App Stores Faster with Intel(R) XDK
> Give your users amazing mobile app experiences with Intel(R) XDK.
> Use one codebase in this all-in-one HTML5 development environment.
> Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
> http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
> _______________________________________________
> Jmol-users mailing list
> Jmol-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-users
>
------------------------------------------------------------------------------
Go from Idea to Many App Stores Faster with Intel(R) XDK
Give your users amazing mobile app experiences with Intel(R) XDK.
Use one codebase in this all-in-one HTML5 development environment.
Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs.
http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140
_______________________________________________
Jmol-users mailing list
Jmol-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-users
