On Tue, Jun 15, 2004 at 10:51:41AM +0100, Neil Harris
wrote:
Neil Harris wrote:
On the other hand, _this_ Java-based project:
http://jmdraw.sourceforge.net/ _does_ appear to be what we want.
Quote: "The JMDraw/SMILESViewer project was started by Christoph
Steinbeck <http://www.ice.mpg.de/%7Estein> from the ChemoInformatics
group <http://www.ice.mpg.de/departments/ChemInf/> at the
Max-Planck-Institute of Chemical Ecology <http://www.ice.mpg.de> in
Jena. It is an Open Source project, the sources are published under
GNU Lesser General Public License, LGPL
<http://www.gnu.org/copyleft/lesser.html>. " Next question -- can it
be run on an entirely open-source infrastructure?
-- Neil
You can test it online at
http://jmdraw.sourceforge.net/SMILESViewerDemo.html Also, the parser for
the open source project is the SSMILES subset language only.
A bit more Googling has now turned up:
http://structure.sourceforge.net/screenshots.html
(Java again) which is based on
http://octet.sourceforge.net/
This does seem to understand more than just the SSMILES subset of
SMILES, if my reading of the screenshot examples is right.
Personaly, I'd like to avoid using client side Java.
From my impression, Octet only provides an ASCII
output renderer?
jmdraw uses the java.awt Canvas class to draw, which looks like a
client only component to me, but I'm not that familiar with Java.
Regards,
JeLuF
I agree with you completely about not using client-side Java: client
plugins of any sort are a bad idea, in my opinion. As Fennec pointed
out, we should be able to render the rasters server-side, and then treat
it exactly like TeX: we should be able to re-use nearly all the
TeX-integration infrastructure, just replacing the TeX -> .png black box
with a SMILES -> .png black box.
-- Neil