lepr

@Bitarts I'm guessing you want to select all of the objects that are inside a Group rather than select the Group itself. If you have an object of a Group selected, then cmd+A (Select All) will select it and all of its peers, and nothing else, if Edit All Layers is disabled. Edit All Layers is toggled with the little button in bottom left corner of Layers panel. It does not appear in any menu and cannot be assigned a keyboard shortcut, unfortunately.

Please clarify whether you mean the B&W section of the Tones tab of the Develop Persona or a B&W Adjustment Layer in the Photo Persona.

Welcome to the Affinity forums Use a Compound; it provides non-destructive Boolean geometry operations with vector objects. With the ellipse over the rectangle as in your first screenshot, select both objects then hold down the option/alt key and click the Subtract button in the main toolbar at top of the app window to create a Compound containing the two objects. These contained objects can later be edited as required to change the result.

I deleted all of my posts when p!ssed off with some people in the forum three years ago, so the evidence is gone, but I talked about this export size flaw several times. No Serif person ever commented in response, as far as I remember. There are a couple of posts I made since then which still exist.

Attached is a contrived extreme example of the oversized export problem. The source document has a silly 3 PPI to exaggerate and clearly illustrate the sizing flaw in Affinity's exporting process. The export includes bleed and crop marks. source3.afdesign source3exported.pdf 'source3.afdesign' measures 35.07874 px x 24.80315 px @ 3 PPI, which is 297 mm x 210 mm or 841.89 pt x 595.276 pt Round up the pixel quantities to 36 px x 25 px @ 3 PPI, which is 304.8 mm x 211.667 mm or 864 pt x 600 pt 'source3exported.pdf' measures 864 pt x 600 pt

Your PDF exports are larger than the source Affinity documents because Affinity increases the page size of the export so that its width and height are the size of an integer quantity of pixels at the document pixel density (PPI, meaning pixels per inch, which is deliberately misnamed as DPI in Affinity apps). The graphical elements in the export aren't scaled up, though. 'Check-list.afdesign' measures 1169.291339 px x 2480.314961 px @ 300 PPI, which is 99 mm x 210 mm or 280.63 pt x 595.276 pt Round up the pixel quantities to 1170 px x 2481 px @ 300 PPI, which is 99.06 mm x 210.058 mm or 280.8 pt x 595.44 pt 'Check-list.pdf' measures 280.8 pt x 595.44 pt 'Meal Plan.afdesign' measures 3507.874016 px x 2480.314961 px @ 300 ppi, which is 297 mm x 210 mm or 841.89 pt x 595.276 pt Round up the pixel quantities to 3508 px x 2481 px @ 300 PPI, which is 297.011 mm x 210.058 mm or 841.92 pt x 595.44 pt 'Meal Plan_PRINT.pdf' measures 841.92 pt x 595.44 pt 'Recipes.afdesign' measures 3507.874016 px x 2480.314961 px @ 96 ppi, which is 928.125 mm x 656.25 mm or 2630.906 pt x 1860.236 pt Round up the pixel quantities to 3508 px x 2481 px @ 96 PPI, which is 928.158 mm x 656.431 mm or 2631 pt x 1860.75 pt 'Recipes_PRINT.pdf' measures 2631 pt x 1860.75 pt

I've been having the same problem for months with all three Affinity 2.x apps (from Serif store) on macOS Monterey.

Agreed 100%. I have today, again, had to perform a ridiculous workaround because of that situation. Another infuriating omission for these commands is a toggle for including/excluding locked objects. There is a toggle for hidden objects, so why on earth didn't the developers also give us a toggle for locked objects? [rhetorical question]

The apps have been changed so they have Auto-select choices instead as shown below.

It may be months or years until that bug gets fixed, so would you like a workaround?

A macro is attached. Import it into the Macro panel of Affinity Photo then add it to the Library of macros for future use. Open a blue pencil and graphite image then run the macro to produce a CMYK image with the blue pencil eliminated and the graphite converted to cyan for printing or exporting. remove cyan and convert remainder to cyan.afmacro blue pencil.mp4

Yes on a Mac

That's strange. A screenshot from my Mac is far clearer:

An alternative version using Inner Shadow instead of Inner Glow because the latter lacks angle and offset controls. drop.afdesign

My answer to that was: "Various Affinity proprietary object types will be exported as generic paths when exported to SVG, so one cannot say what was in the Affinity document with any certainty."

My guess is that is a trick question. Various Affinity proprietary object types will be exported as generic paths when exported to SVG, so one cannot say what was in the Affinity document with any certainty. In case it escaped your notice, the discussion has never been about reconstructing an Affinity document from an SVG. Another thread heading for the sewer.

@thomaso Attached is a contrived example in an AD1 document and the exported SVG. Look at the path elements in the SVG. All contain the definition of nodes at their original location: d="M200,100L150,150L100,100L100,200L200,200L200,100Z" transformations (v1-10-6).afdesign transformations (v1-10-6).svg Edit: there was a mislabeled object, so I've replaced the attachments with corrected versions.

I've not been referring to that. You will find an object defined in its original size nested inside that container element (the nesting may be several levels deep). Before you go further with snippets of code, if you are not familiar with the fundamentals of SVG then there is going to be much miscommunication between us.

Percentage scaling [of original width/height] is possible. It just hasn't been made available by the developers (yet).

I have no access to the software's source code and, clearly, it is not possible for me to prove my claim for "every [your emphasis] created or pasted object" that could exist. My background in computer graphics and software development gives me insight that many users will not have. Constructing a test Affinity document and examining the code in an SVG export (without enabling 'flatten transforms'!) confirms my expectation.

Don't be so defensive. I didn't actually say you said something wouldn't be possible. You did say "the original values are not remembered", which is wrong. [deleted snarky comment]

They do get the plural name, but the Layers panel doesn't always update immediately. That happens with a few particular operations in v1, also. If you force an update by modifying the stacking order or toggling the visibility of some object, then the name will become Curves.

Actually, an object is defined in its original size. Its current apparent size is the result of non-destructive transformations assigned to it and any containers in which it may be nested. For that reason, it is possible for the developers to provide us with a scale control in Transform panel for each of width and height, where 100% or 1.0 is the original size, for any type of object, just like they have done in context toolbar for only an Image or Document object.

That is a workaround for the bug which has been in the apps for years. Your workaround won't be a practical solution for many cases. Please log this thread for the developers to see.