Hello Greg,

Thanks for your responses and time on this.

I've tried to look into this a load more, but searching the docs for examples 
has not turned much round, and the API doc doesn't give examples.  I appreciate 
you have a massive doc task to do.
But in the manual, I see 
 and this doesn't even mention MolDraw2DSVG.
When I google MolDraw2DSVG the second hit after the API is 
<http://rdkit.blogspot.co.uk/2015/02/new-drawing-code.html> which describes a 
better-than-original-pure-python drawing capability, but is not MolDraw2DSVG.  
I presume that is also deprecated.  A bit confusing.  Where is the best place 
to look to see examples of MolDraw2DSVG in action?

Re the below, I actually mean white bonds not black bonds, as the images will 
be presented on a dark background, but I will use string manipulation to cover 
the output files no probs.  Thanks for that.
I will check out molecule rotation code, and thanks also for confirming 
python-only coding. 

Re InchI, I was looking at SMILES, as I would like to get as accurate as 
possible while still presenting posh graphics, but reading a bit looks like 
SMILES suffers geometrically where InchI does not, hence movement away from 
SMILES.  In your experience, which is the best *commonly used* format for 
accuracy?  I use pubchem for pretty much all source data, and write to SVG, and 
so after SMILES, InchI (not InchIKey) appeared to be a good balance between 
conformation, use and functionality.  Any comment in the regard massively 
appreciated;  I'm only recently back in (bio)chem after a hiatus for 12 years.


Mark Lewis

> On 18 Oct 2017, at 13:53, Greg Landrum <greg.land...@gmail.com> wrote:
> On Wed, Oct 18, 2017 at 10:12 AM, mark <em...@ej73.com 
> <mailto:em...@ej73.com>> wrote:
> Thanks Greg - it's nice of you to even be willing to support the old drawing 
> methods in terms of documenting them.
> I did have a search for Cairo docs but my quick goog ran aground.  I had been 
> expecting to roll something to process obabel svg output, I thought I'd get 
> more of the control done from the source conversion of InchI to SVG and 
> that's still the case - I'll look further into the rdkit code. Could I ask:
> 1) Which of MolDraw2DSVG and MolDraw2DCairo is best (hopefully not too 
> contentious a question).
> I think you want an SVG, so that would be the one to use. The Cairo one 
> produces a PNG.
>  My requirement is to ideally:
> a. Take InchI string
> As long as you aware that InChIs are not a good way to transfer chemical 
> information this is fine. 
> You may be able to create beautiful chemistry drawings, but the chemistry 
> itself is going to be horrible a lot of the time. InChI just wasn't designed 
> to be an interchange format.
> b. Render as a set of SVGs optimised for current iPhone, iPad and latest 
> Android screen resolutions
> - transparent bg
> - all white bonds and atom text in sans bold
> I assume you mean black bonds? The atom text thing you can do via string 
> manipulation. 
> - ensure all non-carbon atoms' text identifiers are perfectly positioned in 
> the mol render (think max-posh latest mobile rendering)
> That's going to be tough to do; it's a hard problem. Concrete suggestions as 
> to how to improve the existing code are, of course, very welcome.
> + this is so that as technology advances, each device equivalent will get a 
> higher res-still, but as SVG, the nearest image to fit will scale OK 
> (probably until I end up using iPad-optimised images for iPhones...) with no 
> worries about antialiasing artefacts, bond lines perfectly meeting each end 
> it was originally rendered to, as the svg is scaled to fit a new, slightly 
> larger resolution
> + I've given up the notion of being able to rotate a molecule after rendering 
> and have the text remain the right way up - unless you know of a way (not 
> googled this yet)
> Nope, you want to rotate it first. There is RDKit code to do this.
> c. Use a self-rolled post-pro script to edit the svg into the required state 
> (such as bold text etc) as needed
> d. Use python where possible
> 2) You mention using c++ classes, and although I can programme c++ my 
> knowledge is 20 years old; I can programme c and python more easily, so are 
> you suggesting I need to actually write this in c++?  
> Nope. The "C++ rendering code" is all exposed to Python, so you can work 
> purely in Python. I just use that phrase to contrast it with the old, pure 
> python, rendering code.

Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Rdkit-discuss mailing list

Reply via email to