> > There are four platform types: > > A -- Java but not WebGL (any laptop/desktop; any pre-2010 computer, > probably; any computer using standard MSIE) > B -- WebGL but not Java (iPad? Is that all? Not sure here...) > C -- WebGL and Java (some (all?) post-2009(?) computers using Firefox, > Chrome, Opera, or Safari, but not iPad) > D -- no WebGL, no Java (most mobile devices; iPhone, for example) >
I see no reason why any IOS device (including iPhone) should not end up WebGL enabled? I think that may end up also being true of eg Android 4 and higher? > > It would look like this. Specifically thinking browsers here. (Sounds like > we have eBooks covered one way or another.) > > A (Java/no WebGL) -- Jmol uses applet; ChemDoodle uses Jmol applet as > second-best option > B (WebGL/no Java) -- ChemDoodle uses WebGL; Jmol uses ChemDoodle as > second-best option > C (WebGL+Java) -- Page author decides -- Jmol or ChemDoodle > D (no WebGL/no Java) -- Server-based user event-adaptable images only (Jmol > or ChemDoodle) or static page-author-created PNGJ images (Jmol) > Sounds fine > Say you have a page that would use Jmol if Java is present. The Jmol.js on > that page would ascertain the presence of Java and WebGL and: > -- if Java is present, use it. > -- if only WebGL is present, load the JavaScript for ChemDoodle and > display the model that way. > -- if neither is present, either present a PNGJ image or use server-side > image creation using JmolData.jar on the server. Interactivity only by > link/button/menu/etc. > > Say you have a page that would use ChemDoodle if present. Then > ChemDoodleWeb.js would ascertain the presence of Java and WebGL and: > -- if WebGL is present, use it. > -- if only Java is present, load Jmol.js and display the model using Jmol > -- if neither is present, use server-side image creation using ChemDoodle > (iChemLabs server only) or Jmol > > That's the basic idea. Comment? Discussion? What you describe Bob is nicely fail safe, ie SOMETHING will happen other than a generic message. I put a little thought into the above myself when I composed an HTML5 like scientific article, and submitted it to a journal with the request that they publish "as is" (technically speaking). My start point was that currently all journals produce HTML in effect from author submitted Microsoft Word documents, where by definition one cannot incorporate Java/Chemdoodle components. I argued with the journal that a different start point (in my case hand hand authored HTML, but it could be for example iBooks author) would produce a more valuable result. At any rate, in order to convince them, I tried to make my submission failsafe, and succeeded in doing some of what Bob suggests above. If the above is indeed fully implemented, and tested for robustness (that might be quite a challenge) then Jmol/Chemdoodle might become one essential component of journal publishing. Oh, you might ask how the journal in question responded to my submission. Well, the proposal has "gone to the top", and I am waiting for a response. ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
