Robert Bradshaw wrote: > On Dec 29, 2007, at 9:15 PM, Robert Hanson wrote: > >> I'm a bit lost on this thread, but I wanted to respond to the >> binary/multiple file issue. >> >> First, it's a fine idea to create a binary Pmesh file format. If we do >> that, though, let's not rush into it and just "create a binary >> equivalent >> of a Pmesh file." If this is really useful, then let's create a >> format that >> >> >> 1) allows for multiple pmesh objects > > > Sure, though if the zip file thing is working I think it is fine to > have one object per file too (as we also want to specify color, etc. > and will probably have spheres, labels, etc. too, so we'll be dealing > with multiple files anyway and it probably isn't worth trying to > figure out a way to encode this as scripts work so nice).
Take some time to think about all the sorts of objects you will want. We already have spheres and ellipses, planes, lines, curves, arrows, and labels. These are not pmesh objects, and there is absolutely no reason to encode them as such. It's quite possible that the current inline scripting of pmesh will suit your purpose quite well for surface data and Jmol scripting would allow you to deliver other objects such as these just fine. > >> 2) includes a header that clearly distiguishes the file format >> within the >> first 4 bytes -- the "magic number" idea. > > > Yes, this is a good idea. One or two non-ascii bytes maybe (so other > readers can detect that it's binary data). Perhaps a flag that > specifies floats vs. doubles. Java already stores things in a endian- > consistant way, so we don't need to deal with that. If possible, I would prefer all floats -- it is going to be converted to floats anyway, as Jmol does not deal in doubles at all. > >> 3) allows for a simpler polygon definition -- for example, there >> should not >> be the need to redundantly specify the first vertex twice, as is >> part of >> the pmesh file format. > > > Certainly. Other than that the format is very simple to implement, > and I can't think of any changes that need to be made. > >> >> I recently added ZIP (JAR) file reading capability to Jmol -- no >> need for >> gzip here -- we can now read a zip file directory directly if we >> wanted to >> -- but that seems to me to be an unnecessary complication in this >> case. All >> we really need is a new binary pmesh format. > > > I often have more than just pmeshes that I want to include, and > presentation stuff (color, wireframe or not, etc.) is nicely kept > separate from the data in an easy-to-read ascii file. > this sounds very much like a simple set of Jmol script + associated files. In fact, just recently I expanded the zip file reading to ANY file of any sort read by Jmol. For example, right now in Jmol 11.3.65 you can give the command: script "spt.zip|ta.spt" which runs the script "ta.spt" found in the zip file "spt.zip". >> Note that Jmol must be able to distinguish the file type from the >> initial >> few bytes of data, not the file extension. That's the role of the >> header. >> >> I'd be very happy to write this reader; but before we do so, let's >> brainstorm a bit on what would be optimal. > > > This would be great. > >> >> >> On Fri, 28 Dec 2007 14:27:05 -0500 (EST), "Miguel" <[EMAIL PROTECTED]> >> wrote: >> >>> >>> zip (jar) would be better for sets of files ... although Jmol >>> currently >>> doesn't have any mechanism to deal with a directory of files. That >>> is, it >>> wouldn't know which of the files you wanted to *open* and what you >>> would >>> want to do with the other files. >>> >> >> Jmol 11.3.65 can and does read ZIP files and their directories, and for >> model files, if the ZIP file contains a "manifest" then specific >> files can >> be read or skipped, then the directory contents may be investigated >> prior >> to model loading. This capability is iterative, so zip files >> contained in >> zip files contained in zip files.... can be read. > > > This sounds perfect--where is this documented? > That reminds me, it isn't yet. It is demonstrated at http://chemapps.stolaf.edu/jmol/docs/examples-11/new.htm#topic61 The manifest capability only applies to loading models, not pmesh objects. Let's keep thinking about this. We need to make sure that 1) the mechanism is efficient 2) we use as much already-present Jmol functionality as possible, not duplicating that 3) it provides what you really need, not an approximation --Bob -- Robert M. Hanson Professor of Chemistry St. Olaf College Northfield, MN http://www.stolaf.edu/people/hansonr If nature does not answer first what we want, it is better to take what answer we get. -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900 --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
