Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

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.

Comments

  • 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.

    Matthias

  • 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.

    Matthias

  • edited July 30

    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?

    Matthias

  • 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

    Matthias

Sign In or Register to comment.