LayOut Text Box Clipping

Hello SketchUp Community!

We’d like to get your feedback on one particular area of existing LayOut functionality: Text box clipping. As many of you may have noticed, text boxes in LayOut only display the lines of text that fit inside the bounding area of the box. Any text that doesn’t fit is “clipped”, and the box displays a red arrow in the lower right corner of the text box.

The clipped text can be made visible by dragging the handles of the text box to increase the size of the text box. Is this confusing, or would it be more confusing if text boxes weren’t clipped?

We’re interested in knowing if text boxes in LayOut should continue to clip text that doesn’t fit inside the bounding box, or if text should simply overflow the text box bounds and not be clipped?

Have you had any issues or problems with clipped text? How often do you open LayOut files in scenarios where fonts have changed and many text boxes have been automatically clipped? Is the little red arrow a useful indicator to you that text is being clipped in a text box?

That does happen if you drag out a text box before typing in it. I’ve seen some reports from users who are confused by this and it would be nice to have the text box continue to get longer (taller) if the text would otherwise get clipped.

Of course this clipping doesn’t occur if you single click to start a text box. I wouldn’t want to lose that feature.

I can feel stupidity creeping over me…

The two options I get for text in Layout are Text and Label. If I just want loose text, I choose Text. Then I can either just start typing or can define a text box which will auto-wrap text within it. The limitation with doing that, as the OP points out, is that the text you type is likely to either not fill the box or to extend beyond it, when it gets clipped. That’s when you have to choose Size to Fit to correct things.

Is there actually a way to invoke auto-wrap and get auto box sizing? That is surely what is needed. I have posted before about how unintuitive it is to have to select a box size and then correct it, rather than having a box expand with text.

1 Like

If you single click to start a text box you can then determine the width of the box by where you insert a carriage return. The box will continue to get longer as you type. There’s no way with this text box method to get auto-wrap because you aren’t telling LayOut how wide you want the text box.

Peter is asking if a sort of combination of the two methods would be useful. You would define the width of the text box by dragging it out (like drawing a rectangle) but if you type more than will fit in the text box you made, it’ll get taller to compensate. It sounds like that is a feature you could use. I would use it but I don’t really find hitting Return a big problem.

Ah, I thought so.

Hitting return doesn’t define the box size though. Here’s a bit of text I just typed in LO:

Screenshot 2021-08-21 at 15.37.11

I hit return after “find” but then I would have had to be touch typing to notice when I needed to hit it again. Now if the Return did define the box size, things would be very different.

I put a box around the text retrospectively just to make it look like a text box done the other way with Stroke turned on.

In the previous thread where I commented on this, I said that I couldn’t see a reason why anyone would want it to work the way it does. The logical thing is that once you define your text box width (either by the current method or by hitting return), the text should carry on autowrapping to that width until you choose to alter it (say by dragging the text box handles.

This is probably one of the host of things about LO that Trimble must know is a bit daft but presumably cannot change as easily as us mere mortals might suppose. Or maybe…the boffins are hard at work on a completely new and wonderful version of Layout that will blow everyone’s socks off. Here’s hoping!

1 Like

I didn’t tell you that the width of the box would be set by hitting Return once. How did you jump to that conclusion? What if you want the first line to be a heading for a paragraph or you have something like this?
Screenshot - 8_21_2021 , 10_11_34 AM

If the firs return determined the width of the text box and then auto-wrap takes over it would look like this unless it splits words.

So apparently hitting Return is a problem for you and you would like the feature that Peter asked about.

I must say this is a rather obscure thread.
The title doesn’t suggest that opinions on working practices and how changes to layout might be implemented.

It is sort of standaanrd behaviour in CAD and illustration applications that click produces unbounded text and click and drag a text box. I hope that no change to that is on the works. What I miss is a ruler to set tabs and indents, and other paragraph style features.


I can’t speak for the OP but the way I see it working is this.

If you want some text bounded to right and left, you do exactly as you do now but the bottom of the box would automatically adjust to length vertically of the text you type. It’s a minor issue, but maybe you just click and drag horizontally to define right and left justification, instead of opposite corners to signify a box size. The point is that the current system seems odd (to me) in that it expects you to define a box that you cannot know will be the right size and so requires altering afterwards. Admittedly, that only really applies if you want a Stroke-defined bounding box, but I often do.

I wouldn’t take up arms over it!

Thanks everyone for your thoughts on this! I appreciate you sharing your experience using this feature. I’ve been collecting examples of text box behavior from as many other applications as I can find and I’m not seeing an obvious consistent pattern, just a combination of behaviors, some similar to LayOut, some different. I’m most concerned with making the SketchUp and LayOut user experience the best it can be by removing as many pain points as possible. I suspect that clipped text boxes in LayOut is causing some users some amount of pain, but at the moment I’m not convinced there is a significantly better alternative to the existing feature that would completely eliminate that pain. But we’ll keep thinking about it! Thanks!

1 Like

This drives me bonkers! Text top anchored. Single or double click makes no difference. I then have to resize the box which moves the leader point.
Screenshot 2021-08-25 at 11.36.19 am
Screenshot 2021-08-25 at 11.36.39 am

Does this happen with all fonts? It might be something in the font height definition.

It’s hard to say, it seems worse with smaller fonts, my default for notes in 8 point Arial narrow. If I use say 36 point, it’s fine, if I resize that to 8 point, it’s clipped. Clearly the size of the bounding box is not scaling proportionally with the font size. For construction drawings, notes, and usually lots of them, are fundamental, it’s a huge distraction having to constantly tweek things, rather than just concentrating on the job in hand.

I have to commend you on coming to the community for guidance.

In my opinion Text style editing in LayOut is an absolute dog’s breakfast. Simple functions are difficult to use (m2 or ft3), there are very limited features (e.g. there’s no stroke/frame padding around a text box, no margins, paragraph styles, etc… and it’s very difficult to generate consistent text/visual styles at a template level. A complete overhaul is in order.

Regarding your specific question; I can’t think of any reason why I would want to clip text from the bottom of a text box. But i’ve seen people use clipping as a lazy way to “delete” or hide text that’s pasted in from other places. What’s needed, really, are basic linked/anchored boxes (like MS Word) or, better still, Flowed like InDesign.

  1. There are a lot of font size/alignment issues as axys has demonstrated.
    And there’s this really nasty bug/behaviour that can lead to critical information being missed from documentation issues. Here is what I see - hopefully you can see that this is a real problem.

Four images below: 1 = text box as it appears in LO unselected. 2 = text box once it has been selected 3 = text box while it is being edited. 4 = PDF export showing clipped text.

I assume this is a big or known issue on 2021.1.279?

  1. One of the strangest behaviours I’ve observed with Layout is that the preview/edit mode font size and placement is often very different from the text that once editing has ceased. This varies from font to font.
    When setting a text box size and editing text to look tidy (using returns, tabs, or other techniques to align it nicely) it all goes astray as soon as the user clicks away and the text is committed. In addition to the above, here’s another more pronounced example using a different font.

  2. Free text i think is fine - can just type and use Return as DaveR says. I guess what I’m focussed on are the large documentation sets that are needing to be automated - stuff where you have dozens of text items per sheet and dozens of sheets in a drawing set. Manually typing things is not a viable option in that situation.

  3. There is a signficant functional difference between a “Leader Text” box and a regular “Paragraph Text box” or "free Text box as described above by other users. A leader text box wants to be consisent with other leaders, and make sure nothing is cropped (because leaders are updated dynamically).
    The aim (visually) is to make all leaders look consistent in terms of leader length, angle and position of the text relative to the leader. So a Leader Text Box option would be quite helpful here as opposed to the exisitng “free text” format.
    (sidenote: This would also help the annoying behaviour that ocucrs when a user wants to scale or rotate the text that is part of a leader or dimension ; the scale tool is currently applied to the entire text and leader combination. An independent text box would make total sense since the leader line or dimension line is also independently editable. )

  4. For the “paragraph text box” (bounded text), what is needed are basic margins / padding, line spacing settings, tabs, etc, within easy reach. Paragraph styles would really help here, too.
    if you’re concerned about clippig, then why not do what other programs do; put an option under Preferences/Settings to tell LO to either extend or clip the text?? Why does it have to be one or the other? (remember LO is a professional tool now…we pros can handle a few settings adjustments)

  5. The edges of each text box are only visible if the item is selected. This makes detecting edges of frames etc or clipping a bit more difficult. InDesign has a very helpful viewing mode where all text frames, margins, grids, etc become visible/hidden with a shortcut key. This mode is good for adjusting layouts when needed and can help the user align boxes etc (using snapping or guides).

  6. Many programs have a feature where text is auto-scaled to fit a box. This could be a very good feature for Layout to implement because it’s a common CAD/drafting scenario where you have limited space withinin a box to fit your text - and the text is often pasted into a box or table (For a common example PowerPoint uses this feature extensively). I can think of a lot of good use cases for this, particualry the leader text boxes for compnents, titleblocks and info schedules (tables).

  7. Maybe there’s opportunity to allow text boxes to be defined (size, etc) and then save that as a style (ie Adobe’s Object Styles). I don’t mean just eyedroppering the colour/weight of their leader line and font, but also adopting the phsyical size and format of the text box and the position of the leader line. It can be a challenge currently to get everything looking uniform across a larger drawing set…and if you change your mind on sizes or font, then you must manually readjust the placement of everything. For some reason the text position also varies signficantly (eg the third box down has a different margin).

9. Following from #8 above, the alignment and size options for text boxes (and leaders, and pretty much any other object in LO) are currently very limited. For example there’s no easy way to define that size acurately (eg using keyboard to enter dimensions). Wecan enter dimensions while creating the text box, but not after it has been created (it is possible to scale it; but that’s not very useful if trying to match with other items… and we can actually put a dimension line and adjust it back and forth til we get it close enouhg, or drag it and snap it…none of these are efficient workflows.

  1. On the image above you’ll note that the red background is very red against my red text. Under Preferences/General there is no option to adjust this colour (but we can adjust the colours of other things…so why not this?).

Okay I think that’s enough for tonight :smiley:


Agree, this is the same as all the graphics and DTP software I use… using a return to define the width is crazy… every time you adjust font type or size you will have an embedded return stuffing up your type setout. Just copy Powerpoints textbox formatting capabilities… billions of people are familiar with them

PS… and yes text style capability would be a great enhancement… but given the pace of any development I would be grateful for a simple FIND AND REPLACE capability

Seems the answer is adding a word processor to Layout. That should satisfy most users.

The functionality of MacWrite II (released 1989) would be quite enough.

Yes! Find and Replace…

and “Find and Replace Format” is another good one. At a push it can be used to change style of text throughout a document, which might be an easier addition to LO than proper Paragraph/Text styles.

1 Like

Wordpad for Windows is a classic. That would probably be enough for LO text boxes. It has margins, tabs, heading styles.
It escapes me why such a thing hasn’t been added to LO from the outset.


I would find it extremely useful if the text box did not clip the text. I find myself having to adjust text size/bounding boxes due to the fact that text does not scale when using the scaled drawing feature.