Crossing Arrows

Will J
  • Will J
    Will J

    I am trying to determine if it is possible to have arrows cross each other.
    Like an entity1 sends a message that is angled because it takes some time
    to get to the target entity2. But before the first message is received a
    second message is received by entity 2.

    I am trying to get the messages to cross. This is a valid scenario for a
    MSC but I cannot seem to do this with this tool. Is this possible at all
    with this tool or am I trying to do something that can't be done.

  • It can be done. You shall use parallel blocks ( However, since the parallel block layout tries to avoid overlaps between the blocks, crossing arrows will be prevented. (I did not think of this use case when re-writing the algorithm.) You need to switch back to the algorithm that allows overlaps via the "classic_parallel_layout=yes;" chart option. After setting it to true, you can have parallel blocks with overlaps.

    The attached example shows two ways of crossing. The first one is when one message from 'a' to 'b' is faster and there is re-ordering; the second when two messages cross each other in opposite directions. The "hscale=2" is just to make the chart wider, so that labels have space. The "\pl" escape sequence makes the labels left aligned. The "vspace" command merely inserts empty space so that the arrow starts lower.

    I hope it helps and sorry for the delay in responding. Please let me know if you have ANY suggestion on how to cover this use case a bit more elegantly (or with any other aspect of the program.)

  • Will J
    Will J

    Thanks for the quick response. This helps a lot. I figured I needed the classic parallel layout but still could not put all the pieces together with the angles and spacing.

    I also noticed the blocks example in section 3.5 but didn't realize I had to use this format to get the lines to cross. As far as I can tell I can't get them to cross with the the regular non-block syntax where the message is defined with "parallel" and then the next message is parallel to it.

    This is a very important and good feature because I have not been able to do this any of the other self drawing tools that I have found except for now this one. To make it clear that this is possible you probably could just add a small section explaining it, with examples, to the manual in section 3.5 or 5.12 or both.


  • I agree. I will add an example on this. Can you think of a better syntax to express this? I am thinking of a new "overlap" keyword. This would be similar to "parallel" but would allow the next element(s) to overlap with the one marked with the "overlap" keyword. Would this work better?

    If yes, shall this keyword allow all subsequent elements to overlap the marked one or only the next one?

  • Will J
    Will J

    I think the overlap keyword would be more clear for sure.

    Or you could also, if possible, allow the drawing of arrows based on marks in the attributes.

    mark m1;
    a<-b: \plslow_msg[marks:m1-m2];
    a->b: \prfoo; # message to cross
    b->a: \plfoo_rsp; # message2 to cross
    mark m2;

    of you could also make it an attribute of the crossing messages to not make them move automatically the next clear line:

    a<-b: \plslow_msg [angle=20];
    a->b: \prfoo [allow_cross=yes]; # message to cross
    b->a: \plfoo_rsp [allow_cross=yes]; # message2 to cross

    If you go the overlap keyword route I would just keep is similar to the two syntaxes of parallel. And then just make it so the user does not have to worry about defining the angles and spacing. You can explain it as a special case of parallel.

    Last edit: Will J 2013-09-25
    • Hi Will,

      I plan to do the following. Please check if you, as a user find these additions satisfying.

      Thing #1. I will introduce the "overlay" keyword similar to "parallel". While the latter allows any later element to be positioned besides the element marked with "parallel" (but keep avoiding overlaps), the new keyword would position subsequent elements on top of the element marked by the "overlay" keyword.

      So your second example would look like:

      overlay {
          a->b: foo; #message to cross
          b->a: foo_rsp; #message2 to cross
      a<-b: slow_msg [angle=20];

      Thing #2. I will add an attribute to arrows "slant_depth" which would take a number in pixels and would be an alternative to "angle". Instead of specifying the slant angle of the arrow, you can specify how much lower the end of the arrow should be compared to its start.

      I appreciate your input, however, the construct you have specified in your first example would be difficult. I first do the layout of all elements except verticals and symbols before determining the y-coordinate of the markers. (Then are verticals and symbols laid out.) Specifying a marker in an arrow definition would require to lay out some of the arrows also in a deferred manner, which would be a) a big piece of work, moreover b) would prevent subsequent (normal) arrows to be laid out below the slow message, as they would be laid out before the slow message.


    • Hi Will,

      I have uploaded 3.6.4, which does what I have described below. Please test and comment, if you have the time.


      • Will J
        Will J

        Hi Zoltan,

        Sorry for the late response... For some reason I can't get sourceforge to send me an email for replies.

        Disregard my previous post if you saw it... After looking at the documentation I see that the key word is actually "overlap" instead of "overlay". You may want to edit your post in case someone else reads this.

        So yes, this is a good implementations. It is much less confusing than trying to use the classic parallel syntax. Thanks for taking input and making updates.

        Last edit: Will J 2013-12-11