The question & answer seems to be really simple, thus I am afraid I have misunderstood it. Sorry if this does not apply.
My answer if for OG 5.4.4. Of course it should work the same for any later release (unless OG have jettisoned rearward compatibility).
Make a Shape, say a square
Duplicate it. Position them as you wish
Group the two Shapes. Now you have one Object, composed of two Shapes
Set the default on both Shapes to Text/Overflow (or Text/Clip)
(what you have is Text/ResizeToFit)
Double-click or click twice on the forward Shape to access it [within the Group]. Type in your text.
IFF the text in the front Shape exceeds the vertical size, wherein it overflows:
Set the forward Shape to Text/ResizeToFit
There are nuances that may make it better or worse for your particular use. You need to play with it and work the nuances out.
Eg. if you change the text, such that it no longer exceeds teh vertical size, you need to set it back to Text/Overflow.
In a similar grouped Object, I set the font in the rear Shape to Helvetica 24 dark red. Thus if I accidentally access the rear Shape and start typing, I get a nice red signal. That feature is in my Stencil.
Ok, but that does not affect the back shape in any way (see screenshot below): are you implying that the back shape must be manually resized? The point of my question is whether it is possible to avoid manually tweaking the stacked shape as much as possible. As far as I can tell, the only way is to use a shadow as a back shape (as in my first screenshot above), although that limits the back shape to one uniform color.
Use a Backing Object [atom] for the rear Shape. Click twice on the forward Shape, set the Fill to pink 50%. The rear Shape remains a solid colour, with a predictable Shadow. Set the Shadow as you wish.
Last, if you inform me as to exactly which symbol you are trying to build, I can provide more precision.
Thanks for the detailed explanation, but I think I did not explain myself clearly enough. This is the stencil I want:
I can build it by stacking and grouping two rectangles, of course. But when the stencil is resized (say, vertically), the distance between the bottom side of the front rectangle and the bottom side of the back rectangle changes:
The above is the result I get when I drag the grouped object. Another way to express the same issue is that, even if the stencil is initially aligned to a grid (that is, both the front and the back rectangle are indivisdually aligned to the grid, and the grouped object is as well, of course), resizing the grouped object maintains the group aligned to the grid, but the individual component objects are displaced off the grid.
Currently, to get this, I have to resize the front rectangle and the back rectangle separately, so that they remain aligned to the grid.
A (sharp) shadow would behave as I want, but a shadow does not have a fill and stroke color, so I cannot get the appearance of a white back rectangle with a dark border using a shadow.
I hope it is clear now. I can live with OG’s current behaviour, though slightly inconvenient: I wrote this post to know whether you gurus know a better way—perhaps, some setting that keeps the components of a grouped object aligned to the grid.
The only way is to obtain both rectangles aligned is to resize each rectangle separately.
Ok. So the value in all that detail is, the Backing Object, which may come in handy as your grouped Objects progress and mature.
If I may say so …
The issue you have in intellective, and typical of people with an OO mindset. The larger problem is the suppression of the hierarchy. The specific problem is, they want both the total independence of each Component, and also the total integrity of the Group [grouped Object]. This is the Inheritance problem that they have never resolved. It is not an exclusive choice at the Object level. It is to be understood that in any given Object, due to multiple inheritance, several channels of access exist and that when using one channel of access, the others will be negatively affected.
In this example, there are only two such channels, but that is enough to expose the issue. The resolution is to apply the Grouping last: easy in a compiler, but impossible in a tool that works from the finished product (an OO Object or a OG grouped Object) backwards. One must be clear in the intent, when approaching a grouped Object on one channel, and not expect the behaviour of the other channel:
either change the grouped Object
xor change one or more Components of a grouped Object
As demonstrated here, the correction was at the intellective level, the expectation.