Scaling bitmaps and vector

[Konspaul]

This is more a note than a question.

 

I've noticed when scaling imported bitmaps scaling + SHIFT lets you scale WITHOUT proportion. Vise versa when scaling vectors + SHIFT it KEEPS the proportions. This is confusing. I understand why it is made like this but to me it would be more convenient to make the SHIFT action always keep the proportion.

[Ben]

There was a very long conversation about this subject.  We are trying to strike a balance between fine control and general usability.

[Dave Harris]

The default (ie, without SHIFT) depends on whether the object has a natural aspect ratio. Bitmaps do; most vector objects don't. Art text does; Frame text doesn't, unless you use the also-scale-text handle in which case it does. The default is that way around so that you don't get squished text by accident, but constraining aspect ratio for rectangles by default would be annoying.

 

In this case we decided usability was more important than consistency.

[MaxClass]

Since we already have a Contextual menu using a right click how about something like this.

 

Add into the Contextual menu under “Transform” > “Scale to…” (since scaling is a transform)

 

1. Select any object.

2. Right click for a contextual menu.

3. Select “Scale to…” from the Transform option.

4. Small dialog pops up with two edit fields. One for Horizontal scale factor and one for Vertical, both empty.

5. User enters the exact scale percentage they need and press return. If either field is left blank the scale factor is matched by the field who's entry was entered. (This way only one entry is required for a proportional scaling.)

 

Object has now been scaled exactly as required.

 

Max

 

P.S. I used this approached for scaling in my “SignPost” Software and everyone loved the simplicity of it.

 



[Matthias]

The default (ie, without SHIFT) depends on whether the object has a natural aspect ratio. Bitmaps do; most vector objects don't. Art text does; Frame text doesn't, unless you use the also-scale-text handle in which case it does. The default is that way around so that you don't get squished text by accident, but constraining aspect ratio for rectangles by default would be annoying.

 

In this case we decided usability was more important than consistency.

This reasoning is technically derived rather than aesthetically. How does a vector drawn star or a circle or a square affect my creative intent differently than the same shapes drawn with bitmap tools? Why wouldn’t I want my exemplary vector star to scale proportionally just like the pixel star?

 

We all know their different nature and we will eventually get used to oppositional effects to the same cause (having to use the shift key/having to avoid the shift key for the same type of action). But this way the user is forced to spend a fraction of a second to first think about the technical nature of the element to be scaled before actually scaling.

 

I’d have no problem having a constrained aspect ratio by default – neither having a free aspect ratio – as long as it is consistent.

[Raskolnikov]

This is more a note than a question.

 

I've noticed when scaling imported bitmaps scaling + SHIFT lets you scale WITHOUT proportion. Vise versa when scaling vectors + SHIFT it KEEPS the proportions. This is confusing. I understand why it is made like this but to me it would be more convenient to make the SHIFT action always keep the proportion.

 

For me it's too a confunsing thing, as I use to combine AF with Photoshop.... and both programs do differently on this task...

 

I would like AF to revert that controls (although looks logical this behaviour) ....in the way you wrote. (because I don't think Adobe would do it....)

 

In this case I prefer usability before coherence, I mean, I prefer do things as quick as possible, without having to think on which program I am now.

[rui_mac]

Why so much talk?
Simply add a preference switch to make it work either way.

Personally, I prefer a coherent behavior.  But some users may prefer another.

Just add a preference switch.

[Andy Somerfield]

I have no problem with a preferences option for this - we will add it to our list..

 

A

[rui_mac]

Nice :D

I love applications with LOTS of preferences. Lately, application have less and less preferences.

[Raskolnikov]

What about this? more info when scalling. (maybe silly idea or maybe not)

 

 

When rotating it appears the "º" (degress) you rotate, so why not the % when scalling? of course if the proportions are locked, the % on W and H would be the same.

 

This feature could help to control how much exactly you want to scale an object (for example: Double in W (200%) and half in H (50%)

 

The 100% would be of course the original size of that element before using the tool :)

 

 

And the transforming panel could show a bit more info (as relative distancies between original position and the currently new when moving an object), till the smart-guide-distance-visualization arrives (hopefully someday...  I want to believe! :P)

[rui_mac]

I like this idea a lot :-)

[MaxClass]

Yes, this idea would be helpful but depending upon the current zoom level you are at will depend upon the accuracy you get. It is also another action internally that has to take place constantly redrawing the info block, recalculating and updating the display numbers every time the cursor moves even one pixel. All of this digs into the overall performance of the software (specking from a programmers point of view here).

 

Still being able to specify exact proportions is never a bad idea. For instance when I need a rectangle of an exact size I simply drag one onto the screen then go to “Transforms” and enter in the Height and Width I want and I know it is exact without question.

 

Max



[gbravetti]

On 9/25/2014 at 11:53 AM, MaxClass said:

recalculating and updating the display numbers every time the cursor moves even one pixel. All of this digs into the overall performance of the software (specking from a programmers point of view here).

I know this is a pretty old topic but I can't let this assertion pass.

First of all @Raskolnikov idea is brilliant, and to implement this wouldn't actually use no more resources that what you are using currently. Well for real it will, but that CPU usage difference can't be even measured on nowadays computers.

We are talking about adding a couple of simple math operations here, and the result will be added to the function that shows current size, so there is no need of extra screen redrawing. Btw values can be updated only when size updates.

What you said about zoom and accuracy isn't true also. Say that is like saying that the shown measure's accuracy will depend on current zoom. What would depend on current zoom is the resize accuracy, and this will affect both, real size and percentage size. 

I hope  to see this feature implemented soon. I'm really tired of keep doing maths outside the application to know what percentage I'm using to enlarge/reduce things.

Best,

Gustavo