Insertion point when placing files

[R C-R]

11 minutes ago, thomaso said:

Mainly, according to the OP and the initial topic, by getting for click-placing the cursor to the upper left corner.

OK, that seems like a reasonable request (& probably one already mentioned in the Feature Request forums, although I have not checked for that). Of course, while it would determine where the upper left corner of the 100% sized image/file would be placed in (or near) the document's visible area, its size might still have to be adjusted to something other than 100% & moved to some new position for the final composition.

That happens for me when there is a large disparity between the document's dimensions & those of the placed image/file. For me, that is much more often the case than not. That is why I almost always prefer the click-drag placement method.

[Clayton King]

I posted the question originally because I find it creates unnecessary extra work. I typically size places images before I get to layout. When I click to place an image, I obviously wouldn’t want it centered where I click. In fact, I can’t think of a scenario where you would. But regardless, establishing a default anchor by clicking one I. The transform panel prior to placing a file seems reasonable. 

[R C-R]

40 minutes ago, Clayton King said:

The transform panel prior to placing a file seems reasonable. 

Even if you could click once to set an anchor point in the Transform panel wouldn't it still take a second click in the workspace window to place the object? Besides, if you are sizing placed items before placing them in the document, isn't that also an extra step?

To me, it just seems there is no 'one-click' solution that would work in every scenario.

[thomaso]

1 hour ago, R C-R said:

To me, it just seems there is no 'one-click' solution that would work in every scenario.

This is not the goal at any time in this thread. The point is to enable click-place a resource with the cursor in the upper left corner instead the center of the placed resource. – Of course, that can not prevent from any "but then" and "what if" thoughts, their source appears to be endless, for ever.

[R C-R]

7 minutes ago, thomaso said:

This is not the goal at any time in this thread.

Then what do you make of this recent comment by @Clayton King:

Quote

I posted the question originally because I find it creates unnecessary extra work.

 

[thomaso]

7 minutes ago, R C-R said:

Then what do you make of this recent comment by @Clayton King:

I agree to Claytons impression, but don't see a need to make anything of it. This comment, like any other in this thread, does not talk about a "'one-click' solution" – it was just you. Please, just stop such useless arguing. I leave this thread now.

[R C-R]

46 minutes ago, thomaso said:

I agree to Claytons impression, but don't see a need to make anything of it. This comment, like any other in this thread, does not talk about a "'one-click' solution" – it was just you

I interpreted his comment as about avoiding extra work; IOW avoiding extra steps. Thus, I think the number of steps needed for any use case has to be a part of the discussion.

Maybe I have this wrong but you seem to be focused on a one-click solution that would work if the placed item is already the desired (100%) size so its top left corner could be placed at the desired document location with a single click. The author of the topic as recently proposed a more general solution involving a choice of anchor points, not just the top left corner, possibly involving the Transform panel (although I am not sure how that would work), but again assuming the placed item is already at the desired size.

As I wrote previously, I rarely encounter a situation where the size of the placed item is already at this size -- after all, both documents & placed items can have vastly different sizes & I may want to place some item at very different sizes in different documents, & even sometimes place them at different sizes in the pages or artboards of a single document.

Let's also not forget that we are not limited to placing only single layer raster images in our documents. We can also place multipage/multilayer PDF, PSD & native Affinity format files as either linked or embedded documents. We might need or want to resize some of the elements of any of those placed items, or remove them completely.

So bottom line, there are many different workflows involving placing items in different documents. In only a few of them would a single-click to place the top left corner at 100% (or any other) size avoid the need for "extra" work. There are just way too many possibilities for that.

[lacerto]

9 hours ago, thomaso said:

Do you know if this was ever commented by a Serif moderator?

Not really. I remember that there has been discussion on bugginess of this tool -- it e.g. used to trigger failure of passthrough and cause miscellaneous problems in earlier versions. I have not checked if all these issues have been fixed but the passthrough thing is (even if it still has other cropping-related bugs). "Non-destructiveness" may refer just to the fact that rasterization only happens at export. But then I think it also happens disregarding the DPI settings used at export time, always using document DPI, and also "silently" upscaling without any notice or possiblity of the user to have effect on this, which is ultimately a bad feature.

Btw, in this connection I noticed two other things:

1) Turning off JPG compression (that is, disallowing it in export settings), results in dramatic decrease of file size when using other than Vector Crop tool (or masking), and equally dramatic increase when using Vector Crop tool cropping (or masking):

So +17MB when using Vector Crop tool and minus 9-10MB when using clipping rectangle (crops_02_nojpg.pdf) or picture frame (crops_03_nojpg.pdf). That must be a bug. One could say that not only is the Vector Crop tool non-destructive, but "constructive"...

2) If an image has transparent background and it has placed PPI below document DPI, it will be upscaled no matter what cropping method is used, and also when not cropped at all. I have not examined this closer but the top row emblems were initially CMYK images with a transparent background, and I could not get difference in the middle emblem which was dofferently cropped in the three "crop" tests performed above until I realized that the transparent background cause it.

=====

This is probably one of the causes for huge PDF export sizes people are reporting: they have below document-DPI sized images (like large background images, not necessarily patterned) cropped with the Vector Crop tool and JPG compression turned on (as it is by default). But why, on the other hand, non-mask based cropping methods cause lower file size whenJPG cropping is turned off? 

Below are examples of the version where the background pattern image is cropped by using a picture box. When I placed the images on top of each other in Photoshop, I could not see any difference in the background image quality so the error might be simply in encoding (packaging) of the compressed data.

 

crops_03.pdf

crops_03_nojpg.pdf

[Petar Petrenko]

On 11/3/2021 at 1:07 AM, Clayton King said:

I feel stupid asking this, but I've looked and can't find an answer...

When placing an image in Affinity, the default seems to be to center the placed image (for example) centered at the click-point.

The same problem when placing text into Publisher. Text frame must fit the column or page margin.

[thomaso]

I added a Feature Request: