Jens Frank wrote:
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
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