transform by percentage not working on text in Publisher

[JeremyTankard]

Not sure if this is a bug or a limitation of Publisher.

I have a Text box place on a coloured Graphic element which I want to scale by 50%.

So I select all and enter 50% in the Transform X(or Y) field, making sure that the dimensions are linked together.

The graphic scales correctly but the Text box doesn't. The only way is to manually drag the group by the floating bottom right node/handle. However this isn't accurate.

I asked some time back if there was a more easy way to add scale by percentage as in the Adobe Apps, unfortunately this hasn't appeared.

Transform does seem limited in its abilities, especially in this circumstance.

[GarryP]

You don’t scale things by changing their X or Y fields but you can scale them by using the (W)idth and/or (H)eight fields.
If this doesn’t solve the problem, is there any chance you can supply a GIF/video of this happening?
I only ask as it seems to work fine for me on Windows.

[carl123]

Scaling a text box in the transform W (or Y) fields will only scale the size of the text box not the size of the font

So, scale your Text Box & Graphic element by 50% then select all the text in the text box and scale the font size by 50% using the context toolbar (not the transform panel)

[GarryP]

Ah, a Text Frame and not Artistic Text, I see.
So the problem was actually that the “Text box” itself does scale but the text within the “Text box” doesn’t.
That makes it clearer to me now.

[prophet]

Just ran into this issue myself. I have a group of several elements including an image and artistic text on a curve. When I enter a percentage in Transform, image and curves scale as expected, but the text stays the same size. As @carl123 mentions, I could then select the text itself and scale it separately, but as I often bemoan, why does Affinity make me do extra steps to get something done that could be done more efficiently? I think the default behavior should be to scale the text size as well.

[GarryP]

I think the issue here is that the scaling can be done with two possible results:
1. The frame text is scaled proportionally with the group.
2. The frame text is not scaled proportionally with the group.
When scaling the group via the Transform Panel, the software has to choose one of these and so it seems like someone has decided that option 2 is the one most likely to be wanted by the user.  I have no usage statistics to say if this has been the correct decision or not.
If someone can prove that option 1 is actually the effect which is most wanted/expected by most users in most cases then I guess that could be a reason for the functionality to be changed, but I have no idea how anyone might come by such proof.

Another way to think about this is: Just because one person happens to want it the other way round doesn’t mean that everyone else does. Swapping the functionality round because it makes it easier for an individual might make it harder for many other people. What’s “efficient” for one person may be inefficient for lots of people. We have no objective way of knowing either way.

[prophet]

Well said @GarryP. We can't know the exact workflow and thought process of everyone. But I think we can make an educated inference that if someone has grouped items together, they have likely done some specific work to get those element to be in a particular relationship with one another. Thus, if they are scaling the group as a whole, they'd like those elements to remain in that relationship. That's a much more logical inference than assuming they'd like all the elements to remain in relationship, except the size of text.

[thomaso]

On 4/25/2020 at 9:32 AM, GarryP said:

I think the issue here is that the scaling can be done with two possible results:
1. The frame text is scaled proportionally with the group.
2. The frame text is not scaled proportionally with the group.
(...) If someone can prove that option 1 is actually the effect which is most wanted/expected by most users in most cases then I guess that could be a reason for the functionality to be changed, but I have no idea how anyone might come by such proof.

Another way to think about this is: Just because one person happens to want it the other way round doesn’t mean that everyone else does.

The issue is not that there are two possible results – but that there aren't two according options, too. The simplest would be a modifier key for a user defined choice, as modifier keys are quite common, e.g. to constrain ratio when scaling etc. Or an object property, as for stroke width. Or an app preference setting, as for constrain ratio, again.

The lack of this numerical scaling option appears strange for design development in a professional app. I'd agree, in a final use of a logo or an ad (various objects + text), the professional workflow wouldn't use editable layout data but rather a PDF or an image file format. But for the design development, when things need to get tried in various versions, isn't size and scaling one of the typical aspects ...?

The argument there is no prove that option 1 would be preferred sounds a bit odd if you consider that also option 2 could require a proof to be taken as decision. This is not a matter of proofs, but a matter of options. – Imagine I would prove that most printed media are in portrait format. Would this be a reason to ignore landscape as format option in a layout app?

After all, isn't it interesting that Affinity always does scale text (without asking) when a page size gets scaled in spread properties? So it appears the use of scaled text together with other selected objects is a well known desire. Now, a page is 'just' a kind of group (as in AD an artboard is a layer).

[lacerto]

(...)

[prophet]

3 hours ago, Lagarto said:

This feature can be used as a (rather tedious) workaround for scaling text frames (or any selection that is wished to be uniformly scaled as a group), so in the Spread Setup dialog box, after specifying the rescale option and entering the percentage (in both size boxes, and unlocked, as otherwise the width and height will be the same size), and applying the change, copy the selection, undo rescaling, and paste, position the scaled group, and delete the original selection.

Talk about a hack! Yikes!

I trust the Affinity team will fix things soon.