[Cdk-devel] True Depiction Bounds / Scale Parameter

[John M. <jo...@eb...>]

Hi all,

This weekend I had a play with a new image generator and have hit a snag - the current API doesn’t compute the the true bounds of a depiction. The bounds calculation is done on the atom coordinates and so placed labels can be truncated. In the attached examples you can see the hydrogens at the left and right and cut off. 

I’ve had a look at JChemPaint and the bounds are calculated the same. A temporary fix is to increase the margin but this isn’t very nice as it’s difficult to get a good value. As I see it the generators need to tell the renderer their bounds. So how should we do it?
allow each rendering element to have ‘getBounds2D’? - correct approach but a lot of work to reimplement the computations from java 2d.
allow a generator to produce a ‘BoundsElement’ which the renderer picks up to set the bounds - inelegant but avoids api change and reimplementing geometry computations
change the generator API method to take a bounds ‘generate(IAtomContainer container, RenderModel model, Bounds2D bounds)’ which each generator modifies - referentially opaque 

Please let me know which you think is best.

Additionally I’m trying to work out what the scale parameter is for? The scale is set at the start of each invocation and is constant there after. It kind of looks like a way to normalise bond length but each generator divides by the scale and then the render multiplies? The actually size change is done by the zoom and there were actually a couple of rendering artefacts because of this. The scale also means the rendering is tied to the BasicBondGenerator and throws an exception if you remove - I currently have to generate clear bonds so they don’t show up...

new AtomContainerRenderer(Arrays.asList(new BasicBondGenerator(),   // <- configured to render transparent bonds
                                        new BasicSceneGenerator(),
                                        new IUPACGenerator()),
                          new AWTFontManager());

Is anyone who design the API still active and could expand on the rational? I kind of think it would be possible to remove it.

Many thanks,
John