Text size, selectability and moving.

Chasing down why changing text size properties does nothing, I found in the File>Setup options a fly-out note that text size doesn't work on the "Default" font. However it does work on "stick" and "Times". If you have an imported layout with illegibly small texts (mine show tiny and don't scale, as-opened) try changing the font, the texts may resume their original (exported / property) size.

It's difficult to select texts by click, you have to find the origin. Drag-select is better. I am having trouble moving a selected text, using the banner "Move" icon the "from" click (if you were moving, say, a polygon or instance object) instead deselects the text and selects some other object under the click-point. However the keyboard arrows will do the right thing. There is something odd about text object move / select / reselect behavior.

I could not find a settings option to force display of text origin. Depending on justification this may not be where you think it is, relative to the displayed body of the text, and point-selection needs you to hit the mark pretty exactly.


  • Well, yes ...

    In some interpretations of GDS (including KLayout) and in particular in OASIS, texts aren't drawing objects but rather points with a label attached. In OASIS (at least in the standard flavour), texts don't even have a size, no justification and no orientation.

    Texts are essentially points. That's why it's difficult to select them. The current capture distance is 5 pixels. Maybe that is too small for modern displays. It's probably possible to have a configuration option for this.

    You can enable "marked" style on the text layer. This will make the origin of the texts marked with a small cross.

    BTW: there are some other peculiar effects related to the point nature:

    • If a text origin moves out of the drawing area, the entire text is skipped. So the text drawing disappears even if the characters themselves would still show up but the origin is already outside.
    • A cell with a single text has a point-like bounding box and no area. It will never "overlap" with a search box because "overlap" is defined as having a common area > 0. Because of this, such cells are not drawn correctly - i.e. the text won't show. This is a systematic known issue.


  • Thanks, Matthias,

    The aspect you did not comment on, is how a selected text will deselect on (what I expect to be) the "reference" point-click of the Move command, and "something else" selects (exchange) instead. I cannot seem to move a text that is already selected, by mouse.

  • I'm sorry, but I can't reproduce an issue with text selection and move.

    • Without anything selected I can chose "Move" mode, click on the text, move it and then click again to place it.
    • If the text is selected I can move it, but I still have to click close to the origin

    Maybe the issue is that even with the text selected, you still need to click on the origin (or close to). In general, if you have some objects selected and want to move them, you still need to have to capture the selected objects with the mouse. The reasoning is that if I'd always pick the selected objects when clicking in Move mode, it gets pretty confusing if the selection is outside the view and you don't even know if there is anything selected.


  • edited July 2019

    I'm used to copy, move being just relative from:to coordinate clicks to define the translation. It seems like I'm getting a "reselect" action bundled with what I expect to be a plain coordinate entry.

    Seems like regular objects exhibit a similar behavior, clicking from, to points when "from" lies within the object extent moves the object but if "from" lies outside, the object is deselected instead (would select what's under the cursor, if anything).

    So maybe the problem is that the "from" is doing two things when it should be doing one?

    Question - I can't find any option to enable "infix" style (where "M" as move, would take the coords present at "M" entry as the first operand and mouse click for the second, rather than "M" only opens command, click for "from", click for "to". This style is handy for several reasons, another being that you don't have to hold the mouse dead steady on a zero-width origin feature while clicking to get it to "catch".

  • Hi,

    this is what move does when you click first time

    • If there is no selection, it will pick the object under the mouse and start moving it
    • If there is a selection and the mouse is inside the selection, it will pick the selection and start moving it.
    • If there is a selection and the mouse is outside the selection, it will first select the object under the mouse, then move it.

    I noticed that there is a small inconsistency with the second case: for normal shapes, the shapes stay selected when you drop them. For a single text, the text becomes deselected after you have dropped it. I need to check the code why this happens.

    The definition of "inside the selection" isn't zero-size for texts. "Inside" includes the capture distance which was 5 pixels before. So I can't confirm that you need to hold "dead steady" ... except for a very jumpy mouse?

    The infix version of "M" is a good idea, but it would only work for key bindings. So that's a separate feature then which makes sense only to be bound to a key and only if there is a selection, right?


  • I stand corrected. The text capture boundary can actually be zero-size when there is only one text selected.

    I have created a ticket for this: https://github.com/KLayout/klayout/issues/316


  • Hi Jim,

    I have implemented the "infix move" feature (https://github.com/KLayout/klayout/issues/317). It's in branch "issue-317" and unless there are issues with this feature, I'll merge it master soon.


  • hi dick_freebird

    I tried add more some line code to layBitmapRenderer.cc(from line 381) to change point to cross.
    it a bit make text is easier to view and select.

            frame->pixel (pp.x (), pp.y () +1);
            frame->pixel (pp.x (), pp.y () +2);
            frame->pixel (pp.x (), pp.y () +3);
            frame->pixel (pp.x (), pp.y () -1);
            frame->pixel (pp.x (), pp.y () -2);
            frame->pixel (pp.x (), pp.y () -3);
            frame->pixel (pp.x () + 1, pp.y ());
            frame->pixel (pp.x () + 2, pp.y ());
            frame->pixel (pp.x () + 3, pp.y ());
            frame->pixel (pp.x () - 1, pp.y ());
            frame->pixel (pp.x () - 2, pp.y ());
            frame->pixel (pp.x () - 3, pp.y ());

    hope it help.


  • hi Matthias
    your comment "You can enable "marked" style on the text layer. This will make the origin of the texts marked with a small cross".
    it help and don't need change source code

    thank you very much.


  • The "window of selectability" can still be tricky, especially
    if you're zoomed out working with large text. I have upped
    the setting to 16 pixels to make it a little easier to
    grab, but I still "misfire" a lot....

  • There was another post recently where I tried to explain the background of this problem as well: https://www.klayout.de/forum/discussion/1589/f2-cuts-off-some-text-features#latest

    I guess I need to think up a smarter way of handling texts with respect to selections. The display issue mentioned in the other post will be tricky to solve however.


  • I am wondering whether a scheme for "select" to pre-figure
    extents, could work for both texts -and- my interest in making
    a "constrained selectable area" for layout cells that is defined
    by a intra-cell object (like Cadence's use of the instance/dwg
    layer). The texts would require a separate figuring, and some
    embedded info about {font_size*char_count} -> extent I guess.
    But I think the key "pivot point" is in the select action's figuring
    of extents, some more special-case logic?

  • Hi Jim,

    well, the main issue is the non-scaling font (which I personally use a lot). This means that one cannot assign a fixed dimension to a text which itself means the database (which does not know about the zoom factor) can't store that and so this font breaks the whole concept.

    But it's not just the non-scaling font, there is also the default font size which you can configure and which is important for OASIS files (as labels don't have a size there). So again, the label dimensions cannot be put into the database.

    I'm thinking more in the direction of "collision detection" with label pixels (which should be simple as KLayout keeps texts on a separate bitmap). In such a case I can do a deeper search based on the current zoom factor. Something that way.


Sign In or Register to comment.