It looks like you're new here. If you want to get involved, click one of these buttons!
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:
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.
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
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
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
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.
Matthias
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.
hope it help.
daiv
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.
dai
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.
Matthias
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.
Matthias