Ruler start click can't snap to vertex anymore?

Hello to all,
I've updated KLayout from 0.24.6 to 0.26.4 some days ago and wonder about ruler behaviour change. As before I prefer to use only object snapped rulers (grid shouldn't matter), but with the 0.26.4 only the second ruler click snaps to the object's vertex but the first click doesn't anymore. By that, a let's say 0.08mm side length of an object can't be checked, because the ruler start in most cases doesn't hit the object edge, showing a value different from 0.08mm, see attached 'KLayout 0.26.4 - notOK.png'.
It shows out, that the first click hits merely the object edge, but not its corner/vertex.
In Version 0.24.6 also the first click snaps to the vertex reliably, see attached KLayout 0.24.6 - OK.png.
Or have I missed the suitable ruler configuration setting?
What should be done to get a ruler, whose both(!) ends are able to snap on object vertexes/corners?

BTW: The above mentioned issue applies also to the actual version (Windows) 0.26.7

Thank you for helpful hints ...


  • Sorry, I can't confirm 0.26 doesn't snap the first vertex. It's working nicely for me.

    Maybe there is a configuration issue. Try with a fresh configuration (rename "c:\users\your_name.klayout\klayoutrc" to something else and start again).


  • @Matthias: Renaming klayoutrc doesn't matter from my view.
    At first I wondered at your answer 'It's working nicely for me.'. But now I suppose to have the full picture:
    For that I should describe the different 'ruler first click scenarios' more precisely: To hit the vertex in the old version 0.24.6 it was sufficient to click
    ** ANYWHERE **
    near the vertex, (as long as the click fulfills the 'snap range' limit in the config dialog (see my 1st posting attachment), what is assumed for all clicks described in my thread). In the newer versions (at least 0.26.4 and 0.26.7) this behaviour is changed as follows (side length measurement of a rectangle):
    To hit the vertex of a corner for a ruler start point reliably one should
    (a) click inside the 270° angle of the corner in a manner, so that
    (b) the vertex is for sure closer to the click than all the edge points.
    By that edge points can be avoided reliably. But if the first click is inside the 90° angle area of the corner, the click is always nearer to the edge than to the vertex, so it is hard or impossible to hit the vertex as the ruler start.

    My conclusion: In version 0.24.6 it was easy to hit a vertex as ruler start. In the newer KLayout versions this got a little bit tricky, but remains possible by following the rules (a) and (b) described above. (BTW: The same applies to the ruler end point.)

    Is the new, more tricky, behaviour indeed the intended behaviour?

  • Well, 0.24.6 is pretty old. I'm not going to scan four years of commits to answer the last question. Maybe the changed behaviour is a consequence of the auto-measure feature or some other request. I simply don't remember.

    I'm using the ruler feature myself maybe a thousand times on every single day. Condition b) still leaves you with a full 180 degree vertex-capture aperture for a 90 degree corner. For me that's enough.

    You can upgrade to 0.24.10 which is still on the server and happily live with the old snapping algorithm.


  • Thank you for your feedback, Matthias. You mentioned a "180 degree vertex-capture aperture for a 90 degree corner": From my view there is only a "90 degree vertex-capture aperture for a 90 degree corner", whose boundaries are given by the side extensions of the corner. Anyway, after knowing the new behaviour I should be able to get familiar with that. For me KLayout is a very helpful, fast tool.

  • I have the same issue with Windows 10 x64.
    0.25.8 = Ruler snap to vertex is intuitive.
    0.25.9 to 0.26.10 = Impossible to ruler snap to vertex.

    Using clean installs and
    Config - Rulers and Annotations:
    [ ] Snap to grid
    [x] Snap to edge/vertex
    Snap range [8 - 64] pixel
    Angle constraint = Any
    [x] Snap to objects

    Is this the correct place to discuss or should I create a new ticket?

  • I disagree with "impossible" because I'm using that feature myself on a daily basis ...

    But there are substantial improvements in this area: please check out the master build here and give feedback:


  • Yes, impossible is too strong. Easily is the better term.

    I installed 0.27.0 and it looks nice with the pick circle on ruler approaches.
    But, the same initial snap is overwhelmed by all takers.
    Meaning, vertex is not high enough on the pecking order.
    0.27.0 still requires maximal zooming to hit the vertex. Not helpful.

    If you could re-enable the object snapping logic of 0.25.8, that would be awesome.

  • edited February 2021

    There's a setting somewhere that lets you declare
    a pixel-radius for selection "snap". Or was. Have you
    looked at whether this is still present, was ever
    changed from default (I bumped mine up to 8 pixels
    to ease the problems with grabbing and moving the
    zero-width text origins). If left default, maybe it's the
    default that has changed?

    I'd like to suggest, re the "priority" mention, perhaps
    a right-click cyclic that could offer the "selectability"
    filters inline, and maybe things like select-aperture,
    "sticky select" (like, if I make one false click I lose
    all of the selected-set, when I was trying to do a
    "move" incrementally with intervening zooms / pans).

  • Yes, I tried varying pixel ranges from 8-64.
    It simply does not behave the same as 0.25.8.
    To be specific, I am trying to ruler select the intersection of 2 separate entities.
    Maybe the vertex logic is now within a single entity?
    Very frustrating.

  • Even 0.25.8 could not snap to the intersection of 2 separate entities.


  • Yeah, I've never seen a "select by a two-body-
    interaction-feature" nor a snap-to (I'd guess the
    pre-selection logic may be common?).

    But I'd bet some smart guy could make a script
    that does that.

    Here's a thought. How about a ruler that works from
    (between) placed marker-objects, you put the "dot0" here
    and you put the "dot1" there, and a little floating window
    reads out the X0, Y0, X1, Y1, dX, dY and distance (I'll
    even suggest that this be copyable by right-click
    option, to the text buffer). And if you move one, the
    readout updates; if you place only one, you get just
    the X0, Y0 coords displayed. Now your ruler is "live",
    not "static and becoming nothing but clutter shortly".

  • Yes, I am forced to go script route if wanting to upgrade. I'll do a screen cast and post the 0.25.8 behavior. I've avoided automating due to the productivity already in KLayout.
  • @dick_freebird - Yes! A live ruler would be awesome.
    I am quite annoyed by the timeout of the last drawn ruler.

  • 0.25.9 also behaves similar to 0.25.8.
    Can someone explain the code differences between versions for vertex selection?

Sign In or Register to comment.