Insertion point when placing files

[Clayton King]

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. I want where I click to be the upper left point, but can't seem to figure that out.

[walt.farrell]

11 minutes ago, Clayton King said:

I want where I click to be the upper left point, but can't seem to figure that out.

You can click and drag rather than just clicking. Other than that, I don't think you can do what you want.

Edit: Or you could use Picture Frames if you're in Publisher, and click in the frame.

[thomaso]

This confuses me, too, but I also don't know how to get the upper left corner at the cursor position. It appears strange that none of the modifier keys CMD, OPT, SHIFT have any use when placing a resource.

In case you did not discover yet, aside the dragging option: If you press the CTRL key you get a preview under the cursor, though the cursor is in the center of the image you see the upper left corner at least.

[Joachim_L]

7 hours ago, thomaso said:

CTRL key you get a preview under the cursor

Must be Mac only, on Windows you have to use RightMouse. Ctrl on Windows means to place centered about the drag start point. Apart from that, this centric approach is an annoyance for me. Who at Serif thought, that placing images centered was a good a idea and WHY?

[Clayton King]

10 hours ago, walt.farrell said:

You can click and drag rather than just clicking. Other than that, I don't think you can do what you want.

Edit: Or you could use Picture Frames if you're in Publisher, and click in the frame.

That's a helpful idea! It seems to me that one should generally size an image before placing it (within reason), so click/drag works, but also feels superfluous. 

Something else just occurred to me. I wonder why Affinity wouldn't automatically create a picture frame when placing a bitmap image? As I think about it, I'm not sure why you wouldn't want every picture in a frame.

[thomaso]

47 minutes ago, Hens said:

Or create a rectangle>use fill/gradienttool>option "bitmap" This will work in all three apps.

This, imho, doesn't really belong to your options list: It is very hard to setup with the limited UI options of the gradient tool, in particular if you actually don't want to achieve a pattern but a single image only. Also, it doesn't tell the resource file name and resolution, it reduces the options for further fill of the image and it disables the k-only option.

[thomaso]

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

I wonder why Affinity wouldn't automatically create a picture frame when placing a bitmap image? As I think about it, I'm not sure why you wouldn't want every picture in a frame.

It depends on the user habits, Picture Frames can be annoying, too. To me Picture Frames have various disadvantages towards the Vector Crop Tool, for instance …

• The parent layer does not show the image file name but says "(Picture Frame)"

• You can't select the frame layer itself without its nested image (you can for the vector cropped rectangle)

• Therefore it may require more often to activate the "Lock Children" option (for single selected layers unfortunately well hidden outside the UI and not accessible via menu + shortcut key)

• The need to open the Properties dialog window + toggle between its options (in the lack of a "fit image to frame" button aside the existing "fit frame to image" button, respectively if you have set the property option "None" before) is cumbersome.

• To scale the frame + image you need to use the outer bottom right handle in case you have set the property option "None", all other handles alter the cropping only. (which works charming with all 4 + 4 handles of a vector cropped image). For Picture Frames you can press the CTRL key to scale with other handles but this way it is hard not to rotate the object when scaling it.

The scaling slider below the Picture Frames + the centered 4-arrow circle is, imho, rather a nice to have gimmick than useful UI options. Instead I most often prefer old school way: double click the image area + get access to its handles.

For easier access of the Vector Crop Tool you can assign a keyboard shortcut, I use just C to toggle between Vector Crop and Move Tool.

[thomaso]

14 minutes ago, Hens said:

 it is an option to place 😄
Then again, use the zero bitmap option>rasterise and trim>convert to image source will give you back the K-only option and make it available in resourcemanager
I wish Serif would extend this option

Rasterizing an image to a "(Pixel)" layer burns (reduces) the image resolution according to its current size / .afpub document resolution. Instead it may be more healthy to remove the bitmap fill + load the resource normally.

Though bitmap fill is an option to make an image file visually appear in the layout I would not compare it with the true place options you had also mentioned. It just has too many limitations, though its visual result on screen may satisfy.

[R C-R]

9 hours ago, Joachim_L said:

Must be Mac only, on Windows you have to use RightMouse. Ctrl on Windows means to place centered about the drag start point.

On Macs, place centered around the drag starting point is done by holding down the CMD key. OPT (same as Alt) ignores snapping, & SHIFT permits dragging out the placed resource non-proportionally.

So all of the 4 Mac modifier keys are in fact already used to provide options with the Place command.

[thomaso]

2 hours ago, R C-R said:

So all of the 4 Mac modifier keys are in fact already used to provide options with the Place command.

Indeed, so I was wrong with saying above: "strange that none of the modifier keys CMD, OPT, SHIFT have any use when placing a resource".

I had tried click-placing for my statement. Now with your hints I wonder why CMD is used for drag-placing centered, as the OP I can't imagine a situation where centered placement would be helpful.

Whereas the CMD key could be useful to click-place not-centered instead.

[R C-R]

4 minutes ago, thomaso said:

Now with your hints I wonder why CMD is used for drag-placing centered, as the OP I can't imagine a situation where centered placement would be helpful.

It is used for drag-placing centered around wherever the drag is started from, not centered in the document, if that is what you mean. So for example it could be centered around a point anywhere on or off an artboard, canvas, or page.

The status bar shows this as follows:

[thomaso]

Yes, that was clear. In fact it is centered around the cursor which is placing it. Without pressing CTRL first (for preview under the cursor) you wouldn't even have an idea for any of its edges where they will land on your page. – Do you know a use case when this centered placement is helpful?

[R C-R]

25 minutes ago, thomaso said:

Do you know a use case when this centered placement is helpful?

Why would it be any less useful than any of the other possibilities?

[thomaso]

If you know at least one edge or corner, e.g. top left, you could place it more suitable within a specific layout. Then you would need to resize it from one corner only (e.g. bottom right) to set its size after click-placing. This touches the behavior of Picture frames which – if property is set to None to allow cropping without moving the nested image – you can resize from the bottom right corner only, unless you press CTRL, which allows to resize from any corner but then will also rotate the object while even SHIFT does not prevent rotation but avoids stretching when using one of the middle handles.

[R C-R]

23 minutes ago, thomaso said:

If you know at least one edge or corner, e.g. top left, you could place it more suitable within a specific layout.

Maybe I am misunderstanding what you mean, but if you just click & drag without holding down any modifier key, then isn't the top left corner of the placed item always placed where you start the drag? Plus, since Place honors snapping options, couldn't you use guides or a grid to place the item precisely within the document?

[thomaso]

14 minutes ago, R C-R said:

Maybe I am misunderstanding what you mean, but if you just click & drag without holding down any modifier key, then isn't the top left corner of the placed item always placed where you start the drag?

Yes, then it is top-left. Click-place ensures the original size while click-drag doesn't display any info about scaling. So if I don't know the size & resolution of an image I prefer click-place to avoid upscaling. Also it gives me a visual impression of its size, other than the numerical info which appears additionally after having it placed.

So drag-place is helpful for certain layouts, e.g. a brochure with specified dimensions for images – whereas click-place is more useful (as described above) when the layout doesn't exist yet and may depend on the image content or their available size and resolution.

27 minutes ago, R C-R said:

Plus, since Place honors snapping options, couldn't you use guides or a grid to place the item precisely within the document?

Not with click placement. Then the snap guides appear according to the position of the floating cursor and do not take into account the edges of the image to be placed. So for placement by mouse click I cannot use the snap guides of the object edges because the placement click would not place the image at the edges but centred relative to the cursor. This means that the snap guides of the object edges tend to confuse, while the guides of the object centres fit the centred placement but do not seem to make sense either. I don't layout along centres but with edges; I guess everyone does that.

Possibly I am still used to ID where the click-place cursor is positioned at the upper left corner of the image to be placed (on a tiny thumbnail of the image). Which feels weird because – meanwhile, after years with APub – I notice, if I open ID occasionally, I have forgotten more of ID's UI and behavior than I'd expect. But this top-left click-place position seems to be burned in my mind, I suppose because it is simply more natural in a layout process for our left-to-right reading orientation.

@Clayton King, what made you start this thread and ask for a top-left placement cursor? Do you have any different reasons than me?

[R C-R]

13 minutes ago, thomaso said:

So if I don't know the size & resolution of an image I prefer click-place to avoid upscaling.

I am not sure what you mean by upscaling. Placed images retain their resolution independently of that of the document, so I am not sure what it is you are trying to avoid.

13 minutes ago, thomaso said:

So for placement by mouse click I cannot use the snap guides of the object edges because the placement click would not place the image at the edges but centred relative to the cursor.

You lost me here. Snapping is active for me even if I just click rather than click-drag. So for example, if I have snap to spread/snap to midpoints enabled, the top left edge of a click still snaps to any of those locations. Same wiyth guides & grids.

Never mind on that. I see what you mean. I was not testing correctly.

[thomaso]

28 minutes ago, R C-R said:

I am not sure what you mean by upscaling. Placed images retain their resolution independently of that of the document, so I am not sure what it is you are trying to avoid.

This is important for small, low resolution image files, e.g. screenshots (which I often use). If the image is significantly smaller than the page layout dimension then it happens easily with drag-placing to exceed the 100% size of the placed image. To ensure in a 300 dpi document the print resolution it is useful to avoid an image placement with results in a lower image resolution, which may happen if it gets dragged (=placed) too large relatively to its pixel dimensions.

Conversely, this is not a problem if you want to create a photo book with high-resolution photos from modern digital cameras, for example. Then a placed image usually has pixel dimensions which are close to or larger than the page dimensions and therefore an overscaling rather does not happen (unless one crops + upscales image details).

[R C-R]

3 hours ago, thomaso said:

If the image is significantly smaller than the page layout dimension then it happens easily with drag-placing to exceed the 100% size of the placed image.

Until or unless the placed image is rasterized, it retains its resolution independently of that of the document it is placed in. Besides, if at any time you want to return the image to its 'native' 100% size, you can easily do that with the image selected with the move tool using the "Original Size" button on the dropdown menu in the context toolbar:

[thomaso]

I am aware about this but that's not what I am talking about. The point is that the size at which an image appears as 100% when it gets placed depends on image + on page size and + documents resolution. On a 72 dpi .afpub's page of size A4 (= ca. 800x600px) a certain image (e.g. 800x600px, 72 dpi) appears as full page image and thus about 4 times larger than the same image on a 300 dpi document's page. So to drag-place an image without having its size and resolution in mind in relation to the documents resolution may easily result in placing the image larger than its 100%. Of course one can adjust it afterwards – anyway, this thread is not looking for longer workflows but for shorter

[lacerto]

19 hours ago, thomaso said:

This is important for small, low resolution image files, e.g. screenshots (which I often use). If the image is significantly smaller than the page layout dimension then it happens easily with drag-placing to exceed the 100% size of the placed image. To ensure in a 300 dpi document the print resolution it is useful to avoid an image placement with results in a lower image resolution, which may happen if it gets dragged (=placed) too large relatively to its pixel dimensions.

This is a good point but it depends on the workflow what kind of behavior is preferred, the kind of images that are placed, the primary target, and purpose of the placed image. I typically prepare images before placing them and set the appropriate DPI values so that the images will have their ideal or max size by default when placed in the layout. Certain images like screenshots might have lower than document DPI resolution, but are wanted to be kept that way and have them resized only at production time (basically using nearest neighbour pixel duplication). 

On 11/3/2021 at 2:34 PM, thomaso said:

To me Picture Frames have various disadvantages towards the Vector Crop Tool, for instance

These are valid points, but using the Vector Crop tool (or mask) have some serious disadvantages:

1) The images cropped with the Vector Crop tool (or that are masked) will be silently rasterized using the document DPI, and resampling is (it seems) always done using the bilinear algorithm. This means that images that are meant to stay hard edged, will get blurred, so that you get this (this could represent a screenshot):

...instead of this:

Here is a PDF (exported with PDF/X-1a:2003) to demonstrate this:

croppedimages.pdf

2) In addition, if you have medium-res images placed (e.g. as you typically would if you have e.g. pattern-based background image covering a 50 x 70cm poster, which could well have 100ppi effective resolution ["placed ppi" in Affinity terms]), and this image is cropped with the Vector Crop tool (or masked), it would be upscaled using the document DPI at export time, and this would follow (PDF/X1-a:2003):

 

If the background has pattern, resampling might also cause distortion or blurring of the pattern.

3) Using the Vector Crop tool, similarly as using the clipping mask, also causes the hassle with the "Lock children" option (needed to be toggled whenever you wish the child to be moved with the container, or not be affected if the container is resized). It also hides the cropped object's dimensions and position in the Transform panel (and hides its own size and position while the Crop Tool is being used).

[thomaso]

4 minutes ago, Lagarto said:

using the Vector Crop tool (or mask) have some serious disadvantages

Indeed, none of both fits for every situation. Thanks for the details and issues, I just had the issue with layer opacity in mind (solved meanwhile). I vaguely only remember * the rasterizing and dpi issues (was totally out of mind), which appear quite risky, not to say buggy, especially since the label "vector" may not make users expect at all such manipulation on export. – Do you know if this was ever commented by a Serif moderator?

According tho the Help text it works "non-destructively" and for "images". Hm, what a promise.

According to your list it seems the Vector Crop Tool should get used for vector content only, not for "(image)" resources with need for high quality.

* Ah, you had pointed me to this 'feature' one year ago. It seems that made me entirely forget this tool in purpose to avoid using it – while 'rediscovering' it some weeks ago happened without awareness. Thank your for this "security-update"!

 

[prophet]

On 11/3/2021 at 8:34 AM, thomaso said:

To me Picture Frames have various disadvantages towards the Vector Crop Tool,

I'm still waffling between using Picture Frames and Vector Crops for the very articulately stated reasons @thomaso lists. The behavior of Picture Frames is one of the last few hurdles to overcome before I can fully enjoy Publisher.

I hadn't realized the Vector Crop resampling issue @Lagarto mentioned, but I'll now pay closer attention to that risk. Thanks.

[R C-R]

12 hours ago, thomaso said:

So to drag-place an image without having its size and resolution in mind in relation to the documents resolution may easily result in placing the image larger than its 100%. Of course one can adjust it afterwards – anyway, this thread is not looking for longer workflows but for shorter

OK, but I am still not sure how specifically you would like to see this shorter workflow implemented. At least on Macs, all four modifier keys already have an assigned function when placing images (or multi-layer files like PSD's or Affinity native ones), so are you suggesting changing the function of one or them, or maybe something else?

[thomaso]

41 minutes ago, R C-R said:

not sure how specifically you would like to see this shorter workflow implemented.

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

Alternatively, regarding modifier keys and if the upper left corner should not be the general origin: I would change the current use of the Cmd key. At the moment it has no function at click-place, while at drag-place it changes the cursor origin from the upper left corner to the centre, ironically enabling for drag-placing exactly what I already want to avoid for click-placing.