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
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.
> 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
> - 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