Resize multiple objects to same size

[P.N.]

I'm have a publisher page with multiple photo's (over 30) all in 4:3 but in multiple sizes. How do I give them all the same exact height in one transformation. I don't want to retype the size for all images. 

[P.N.]

3 hours ago, P.N. said:

I'm have a publisher page with multiple photo's (over 30) all in 4:3 but in multiple sizes. How do I give them all the same exact height in one transformation. I don't want to retype the size for all images. 

Having read some other posts I believe this is a bug in the software. Selecting multiple items in order to give them the same size does not seem te be possible

[Old Bruce]

You should use Picture frames, Make one and set the size to what you need and then set the appropriate scaling. I would use the Scale to Min Fit option (but that is me). Now duplicate this Picture Frame 29 times and you can place the pictures into them and they will be resized by the frames.

Not resizing multiple selections individually into a single size is not a bug. It is a disappointment, but not a bug.

[thomaso]

4 hours ago, P.N. said:

How do I give them all the same exact height in one transformation.

Not available yet as simple function – though it's technically no big thing, like e.g. page dimensions can get applied to more than the current page of a document also object dimensions could get an according UI.

It's worth to add your vote to this related feature request:

 

[R C-R]

2 hours ago, Hens said:

A pictureframe on a masterpage would work better @Old Bruce

In the first post, the OP said all the photos are on the same page, so I am not sure how a master page would work for this.

[lacerto]

13 hours ago, thomaso said:

It's worth to add your vote to this related feature request

Once it is decided to be implemented, I would rather see it done as part of the Alignment panel, similarly as in VectorStyler, which you can now use as an auxiliary app to do such things for Affinity apps (the Transform panel would then allow scaling separately for each, which currently cannot be done, eitherwhich it already does, without needing to include direct width and height based operations within the same control):

The selected objects can be resized horizontally and/or vertically according to the key object (as in the example), or by the minimum, maximum or medium width/height of the selected objects.

When coming back from VectorStyler, the objects would be grouped and clippedmasked, but could typically easily be "ungrouped all" and then the clip rectangles removedmasks released, if necessary [in case they do not really mask anything].

[lacerto]

2 hours ago, Hens said:

How is this transforming in one go?

Tansformations would be done in the Transform panel, which is appropriate when needing to scale objects (images) with different proportions. The Resize feature could be useful in creating clipping rectangles to crop images with varying proportions to the same size, without scaling the actual image content.

[lacerto]

54 minutes ago, Hens said:

I meant now.

Yes, I understand; my comment was made more to the feature request related post made by @thomaso, and of course would be useful as a workaround only if the user has VectorStyler license.

As an additional note, the feature, once implemented, could ideally also support the kind of masking feature used by VectorStyler, which would allow controlled resizing even with content with diverse proportions (which would result in distorted images, if not autocropped). Below images with (at least) two different proportions are resized according to a 40 x 30 mm resizing target; when they are returned, the distorted images have masks. When child objects are locked, the distorted images can be pretty easily restored (cropped) to non-distorted sizes by using the Layers panel and the DPI / percentage control of the context Toolbar.

[R C-R]

10 hours ago, Lagarto said:

Once it is decided to be implemented, I would rather see it done as part of the Alignment panel, similarly as in VectorStyler...

From what your video shows for VectorStyler, it seems like it would take a very large number of steps to do this via the Alignment panel.

FWIW, I just bought a license for VS yesterday but so far I find its UI overly complicated & difficult to learn. I have also managed to crash it, but that may be due to some local problem I have yet to discover & fix. Anyway, I suppose once I get more familiar with it, it would be a good "companion" app for the Affinity suite, but I suspect I will always prefer to do as much as I can in Affinity.

[lacerto]

15 hours ago, R C-R said:

From what your video shows for VectorStyler, it seems like it would take a very large number of steps to do this via the Alignment panel.

After selecting the images, it is basically two clicks, one for the width and another for the height (theoretically could be made one click less). The rest of the video is "extra" as it shows how to pick the key object to define the target size (this is not always needed), and the two remaining actions just centered horizontally to the artboard and distributed vertically to the selection bounding box. There are many buttons in the size alignment section but they behave logically and pretty much cover the most typical resizing needs. Personally I also think that the feature works better in context of alignment than transformations.

[Wosven]

Another option would be to have real object styles with properties like width & height (at least), like in QXD, and why not scales horizontal & vertival with a percent unit.

[Hangman]

I'm definitely a +1 for a proper 'resize all elements' to the same size using varying criteria across all the Affinity apps, hopefully something we'll see in v2.0...

The OP doesn't mention whether they also have Affinity Photo but if they do, in the absence of this feature and to keep it in the family, why not just do a batch image conversion prior to bringing the images into Publisher?

[R C-R]

1 hour ago, Lagarto said:

After selecting the images, it is basically two clicks, one for the width and another for the height (theoretically could be made one click less).

OK, maybe it is because I am still struggling to understand all the options in VS, but at first I could not get this to work at all. I finally noticed that after pasting into the VS File > New From Clipboard artboard(?) window, it was necessary to use the "Ungroup All" command from the Object menu before the 'align to key object' button actually would let me select just one of the "{Image}" layers as the key object. Without that extra step, the two 'resize to the reference' key(?) buttons would do nothing at all.

So overall, the 'round trip' between VS & Affinity is considerably more than 2 steps; workable but not a good substitute for what should be a feature build into Affinity.

[thomaso]

1 hour ago, Hangman said:

why not just do a batch image conversion

… or why not using a macro to scale the placed objects – instead of burning their size into new exported files.

That makes me wonder: Is it possible when recording a macro to get the absolute value recorded instead of the percentage? (here I typed 250 during recording, not 86)

[P.N.]

On 11/8/2021 at 10:14 PM, Old Bruce said:

You should use Picture frames, Make one and set the size to what you need and then set the appropriate scaling. I would use the Scale to Min Fit option (but that is me). Now duplicate this Picture Frame 29 times and you can place the pictures into them and they will be resized by the frames..

Thank, I just did a manual resize of every image. took some time but less then the search for the quick fix

Quote

Not resizing multiple selections individually into a single size is not a bug. It is a disappointment, but not a bug

I do think it is a bug. If you select multiple items it only shows one item with sizing shapes. There is no logical reason to select multiple items and have only one item resizable. If anyone wanted that just select the one shape. 

[P.N.]

2 hours ago, Hangman said:

The OP doesn't mention whether they also have Affinity Photo but if they do, in the absence of this feature and to keep it in the family, why not just do a batch image conversion prior to bringing the images into Publisher?

I do have all 3 applications. But in this case the images are linked and I don't want to alter them. I just want them all in the same height. 

[R C-R]

3 minutes ago, P.N. said:

I do think it is a bug.

Generally, the term "bug" refers to some feature that does not work as it was designed to work, like by not working at all, causing a crash, or producing unintended side effects. What we are discussing here is a feature that is totally absent from the apps.

[lacerto]

2 hours ago, R C-R said:

it was necessary to use the "Ungroup All" command from the Object menu before the 'align to key object' button actually would let me select just one of the "{Image}" layers as the key object.

The contents that VS reads from the Clipboard is basically a PDF file so it can be pretty complex and to keep it wrapped and not just defined by the initial selection, it groups it. But I think much more can be exchanged this way than e.g. when using SVG between Affinity apps and Inkscape. I have not tested thoroughly the exchange with other apps (Illustrator, CorelDRAW), but I think that Affinity apps and VS work really well together.

[R C-R]

18 minutes ago, Lagarto said:

... but I think that Affinity apps and VS work really well together.

For now, I will have to take your word for that (& I have no reason not to).

But for me, here at the bottom of what looks like a very steep learning curve, documentation that is no better & in some ways worse that Affinity's, a bunch of modal windows that do not update in real time, & some (possibly local) stability problems with the VS app, it is quite a challenge for me to get it to work at all, much less work well with Affinity.

[thomaso]

1 hour ago, R C-R said:

Generally, the term "bug" refers to some feature that does not work as it was designed to work, like by not working at all, causing a crash, or producing unintended side effects. What we are discussing here is a feature that is totally absent from the apps.

I agree this missing scaling option isn't a bug but a missing feature. But as "generally" the definition appears too narrow: imagine Affinity would not have an option to open or  save or export but create only then every tool and coded function may work perfectly as designed but such a missing feature would result as a bug. So, "by design" is not sufficient as indication, it ignores possible issues in the concept as base of the coding work.

[R C-R]

5 minutes ago, thomaso said:

imagine Affinity would not have an option to open or  save or export but create only then every tool and coded function may work perfectly as designed but such a missing feature would result as a bug.

To me it is still just a missing feature, not a bug. That it would be a massive oversight that would make the app practically unusable is irrelevant.

I believe this is an important distinction because it determines where reports about such things logically should be made. This is why we have different forum sections for bugs & for feature requests.

[thomaso]

3 minutes ago, R C-R said:

To me it is still just a missing feature, not a bug.

Yes, I agree, as mentioned.

16 minutes ago, thomaso said:

Generally, the term "bug" refers to some feature that does not work as it was designed to work,

No, I disagree, in particular to "Generally", as mentioned.

[R C-R]

1 minute ago, thomaso said:

No, I disagree, in particular to "Generally", as mentioned.

So a missing feature -- one not implemented at all in the app -- can in general also be called a bug? Does that mean that every missing feature we have been requesting in the feature requests forum (many for years) can also generally be called a bug?

To me that seems like a perfect formula for widespread confusion about where we should be posting bug reports vs. feature requests, not just here for the Affinity forums but also for any other product support forum that has separate areas for reporting bugs & requesting new features.

[thomaso]

2 minutes ago, R C-R said:

So a missing feature -- one not implemented at all in the app -- can in general also be called a bug?

Not "in general". Bugs exist in specific only, imho, so yes, a feature that is not implemented can be a bug, but then of the concept rather than the code development.

4 minutes ago, R C-R said:

Does that mean that every missing feature we have been requesting in the feature requests forum (many for years) can also generally be called a bug?

No. I suppose none of them. (but why "every" – would "every" do if just 1 would?)

7 minutes ago, R C-R said:

To me that seems like a perfect formula for widespread confusion about where we should be posting bug reports vs. feature requests, not just here for the Affinity forums but also for any other product support forum that has separate areas for reporting bugs & requesting new features.

Correct. And it would not be useful or increase the forum's efficiency.

I was stumbling mainly about the "Generally" in your bug definition. To me there is no "general" (~"universal") definition but various aspects of different needs instead. Even within one software company may be variants of the definition for bug, so the marketing, the coding developers and the design department may have different understandings of "bug" about one same subject, according to their specific task, claim or entitlement. The clients and users of this company can have different understanding of bugs, too, which became obvious a few times in the forum.

 

[R C-R]

14 minutes ago, thomaso said:

I was stumbling mainly about the "Generally" in your bug definition. To me there is no "general" (~"universal") definition but various aspects of different needs instead.

I am using "generally" in the sense of usually, widely, without regard to particulars or exceptions; IOW, as the opposite of seldom. It was not meant to mean universally or without exception.