arrows starting at midpoints of other arrows

Hi, this is a fairly high priority for me. This MarvinSketch drawing contains two arrows, one of which begins at the midpoint of another:

<?xml version="1.0" encoding="UTF-8"?>
<cml xmlns="http://www.chemaxon.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.chemaxon.com/marvin/schema/mrvSchema_14_10_13.xsd" version="ChemAxon file format v14.10.13, generated by v14.11.10.0">
<MDocument>
  <MPolyline id="o2" headLength="0.6" headWidth="0.4">
    <MPoint x="-3.828000068664551" y="2.7279999256134033"/>
    <MPoint x="0.07205782806928035" y="3.9254378789273012"/>
  </MPolyline>
  <MPolyline id="o3" headLength="0.6" headWidth="0.4">
    <MMidPoint lineRef="o2"/>
    <MPoint x="0.32178162270503113" y="1.9432875931126437"/>
  </MPolyline>
</MDocument>
</cml>

If I import this drawing into MarvinJS, the second arrow disappears. Evidently, MarvinJS doesn't understand the concept of one arrow beginning at the midpoint of another arrow, so it just ignores it. This deficiency is serious for us; we use arrows beginning at the midpoints of other arrows in free radical chain reaction mechanisms. Conversely, we need to be able to draw such arrows in MarvinJS. Please fix ASAP! 

I am sorry, we are working on the other part of the code currently. I put your request to our todo list, and we will implement it if we work on a graphical part again.

Best regards,

Efi

I understand, but again, this deficiency is a pretty big deal for us. I'm showing a picture of a typical mechanism drawing. We need to be able to tell that the origin of the bottommost arrow is identical to the midpoint of the arrow above it. I guess we could write some code to see if they are physically close to one another, but that creates other problems in itself.

bobgr wrote:

I guess we could write some code to see if they are physically close to one another, but that creates other problems in itself.

Ha! Funny story. I had already written code to see if the start of one arrow was on or close to another arrow, but the code doesn't always work in MarvinJS, because MarvinJS does not always provide correct coordinates for its arrows, as discussed here.

As I see the arrow snapped to the rectangle causes the problem.

Yes.

Any idea when this bug might be fixed?

As far as I can see around april/may we will work in this area, and try to fix this as well.

Best regards,

Efi

If can give my point of view, in a chemical way the last arrow should begin from the last intermediate and not from the middle of the arrow that come back to the initial reactants.

You have 2 reactants that give an intermediate and this reaction is an equilibrium, but the intermediate can give (whitout reverse) the final product. For me in this example, no need of arrows that beging at the middle of an other.

Cheers

I don't follow what you're saying. The way I have drawn it is the standard way of drawing a catalytic cycle, except we use straight arrows instead of curved ones. Unstable intermediates are in the cycle, products come off of it. Granted, chemists don't usually draw radical chain reactions as catalytic cycles, but that's what they are.

Yes. there are other ways to draw the reaction, and that's the current workaround. But I want students to be able to draw the reaction *this* way.

Sorry, I did not recognize that it was a catalytic cycle.

Oh, I see, you saw the arrows joining the two middle boxes as an equilibrium arrow. I see how you would think that in the absence of any context. No, they're two separate normal reaction arrows. The reaction in the box on the right gives two products; one is in the box on the left, the other is in the box on the bottom.

We're almost to August. Any progress on this bug? As I said, it's high priority for me.

I am really sorry, but we cannot solve it in the near future.

Regards,

Efi

ehoffmann wrote:

I am really sorry, but we cannot solve it in the near future.

I'm very disappointed. Part of the problem is the inversion of rectangle coordinates between MarvinSketch and MarvinJS. (See major bug 2 in the most recent list here.) If you fixed that problem, this one wouldn't be so bad, because we could calculate physical closeness between arrow points, but the combination of problems makes the problem very serious.