lepr

I'd prefer the Node Tool functionality be changed to match the v2 documentation, in all honesty, for reasons I stated earlier in this thread. Now that nodes have a context menu, ctrl-clicking a node should do as the v2 Help says in several paragraphs: raise that context menu. Then cmd-click could change a node from sharp to smooth, and cmd-click a segment could do as the v2 Help says: delete the segment. More Mac-like, to borrow thomaso's words. It is possible that the v2 Help indicates changes that the developers intended to make, but never materialised.

The v2 status bar is the same as in v1: both show ctrl-click to be used for deleting a segment. In both apps, ctrl-click functions as the status bar tells us. The Help tells us cmd-click, and that's how the functionality should have been implemented, in my opinion.

But v1 is the same as v2: ctrl-click deletes a segment

Well, I am using the app, not just reading the Help. Ctrl-click deletes a segment. The v2 Help also informs us in several paragraphs that ctrl-click on a node will raise the node context menu, but that doesn't match reality either.

On macOS it is ctrl+click a segment to delete it. Note that the status/hint line fails to inform the user of that function when the pointer is over a segment, unless the ctrl key is actually depressed.

OK, so I forgot about that exception. The points I made are still valid.

That's an odd choice / error of judgement / mistake. It's illogical to do that for just these two functions when everywhere else in the app there is cmd+click on macOS where it is ctrl+click on Windows. Not only illogical in that way, it is preventing the customary ctrl+click on macOS being equal to secondary click. That's less likely than being hit by an asteroid tonight.

I mean mistake as in an error of judgement. Decades of macOS UI standardisation leads users to expect ctrl+click to be equivalent to secondary click of a two+ button mouse. It originates from the original Mac mouse having only one button. Secondary click on a node raises a node context menu, therefore ctrl+click should raise exactly the same node context menu. The Help author has expected that - there are several sections on the aforementioned page which instruct to ctrl+click a node to get the node context menu. Usually throughout the Affinity apps, we see cmd on macOS being used where ctrl is used on Windows. However, we see ctrl incongruously being used on both macOS and Windows for converting a Sharp node to a Smooth node and deleting a segment of a path. The use of ctrl there makes sense on Windows only. On macOS it is an odd choice / error of judgement / mistake.

For the macOS apps, ctrl+clicking a node should make the node context menu appear, but the developers mistakenly made ctrl+click, instead of cmd+click, be the means for converting a Sharp node to a Smooth node. Similarly, they mistakenly made ctrl+click, instead of cmd-click, be the means for deleting a segment of a path. We are probably stuck with these blunders now.

@slowkow: thanks for improving the title of this topic

@Lee_T: probably, I'm on your ignore list, but in case you can see this message, please realise that you seem to be still completely misunderstanding the reason this thread was started. The current original title, "Buggy unexpected behavior with embedded PDFs and SVGs", and the content of the first post may be misleading you. The problem isn't particular to PDF or SVG files, and it has nothing to do with fonts. I posted an example with screenshot and simple Affinity documents to clearly demonstrate the problem: strokes can be incorrectly scaled when objects copied from one Affinity document are pasted into another Affinity document which has a different pixel density. Repeating a message I already posted in this thread:

Yes, I realise that and wasn't meaning to suggest you should have known that automatically.

@slowkow Please change the title of the thread, so people don't think the problem involves PDF or SVG files in particular. Maybe something like "Buggy stroke widths when pasting objects into another document".

That's because you pasted into a destination with same PPI as the source. The effect of the stroke scaling bug becomes apparent when you paste into a document with a different PPI and a physical unit of measurement (in other words, not pixel as unit of measurement), as I showed. (1.x and 2.x are the same. This is an ancient permabug.) object is not in a copied Group, object's stroke is 'Scale with object' enabled: object's stroke gets wrongly scaled by a factor of destinationPPI/sourcePPI when pasted object is in a copied Group, object's stroke is 'Scale with object' disabled: object's stroke gets wrongly scaled by a factor of sourcePPI/destinationPPI when pasted

Easier to select none of the nodes then use Select All (cmd+A).

You're welcome! Note that Lee_T and v_kyr are talking about another problem, not the one demonstrated by our examples. I don't know why they are doing that. This thread has now been tagged with AFD-5160, which is a different issue than the one you and I have demonstrated. Yes, and there are other ancient bugs which I've abandoned hope of being fixed.

No, it's the years old mismanagement of stroke widths when objects are pasted into a document with different pixel density. source 72 ppi.afdesign destination 300 ppi.afdesign

Certainly, I see that the wording of "All layers" (ignoring the use of the word layers to refer to entities that specifically are not Layers, LOL) is misleading, given the current behaviour of not considering the "layers" inside of a Group.

My message was true and it explained the thing that puzzled you: Dan was able to snap to a member of a Group while you were unable to do that. Some people would show a little gratitude. Pre-selecting is unnecessary, and for your situation (snapping to one specific object in a Group) I would use 1 (although any quantity would work) as the number of candidates along with enabled candidate highlighting (purple outline). In the video below, notice how I hover for about a quarter of a second over the yellow object to nominate it as the only snapping candidate. snapping candidate.mp4

In the apps on macOS, there is no Snapping Candidates option named "Current Layer". Did you mean to write something else?

Your snapping candidates was set to "All layers", which prevents the objects inside a Group from being considered for snapping. Dan's snapping candidates was set to "Candidate List", which allows objects inside a Group to be considered for snapping.

I think you are misinterpreting the behaviour of the app. There was no snapping to an incorrectly calculated location. This is what was happening: when a guide is being moved, its initial position is a snap target during the move and you were re-snapping the guide to its initial position (where it had been dropped a moment earlier). First you dropped the guide near a desired location - the midpoint of an edge of a rotated object's Base Box - where there was no snap target. Remember, Regular Bounds, not Base Box, provide snapping targets when moving anything except a Transform Origin*. Then during the subsequent moving of the guide, it was snapping to its initial position. * A Transform Origin can be snapped to nine points of a Base Box and nine points of Regular Bounds - each corner, each midpoint of an edge, and the centre. A Transform Origin itself isn't a snapping target, though, so a workaround for snapping arbitrary things to the midpoint of an edge of a rotated Base Box is thwarted.

Good luck! Both requested many times already since Designer was first released (2014).

They mean enter a physical size in the brush width field. It will be automatically converted to a size in pixels. There still won't be automatic preservation of the physical width of the brush when you switch between documents with differing pixel density (PPI, misnamed as DPI in Affinity). That's why I suggested you create a request topic for that functionality, as an option, if that indeed is what you want.

The order also matters with the Boolean geometry operations: the result takes its style from the lowest operand.