Lorox

Oh man, you saved my day! I was short of despairing, because I couldn't find a way to keep the child element untouched when editing the parent... Almost thought this was actually not possible in AD. This seems to illustrate a problem I tend to have repeatedly in AD: often it turns out that there actually IS a way to do certain things, but for doing so you have to look for a checkbox (or whatever) in some place you wouldn't have thought of. As this is directly related to the stacking and interaction of layers you'd naturally would have been looking there (Layers studio or Layers menu), wouldn't you? P.S.: It's not even mentioned in the Affinity Help on the topic for "Layer clipping"...

I think this a actually a problem because it seems that Affinity Designer strictly keeps the ratios of stroke/space given in the stroke panel. The actual appearance is then dependent on the stroke width that's set (the numbers entered in the dashed strokes settings being just multiples of the stroke's width). So when you have a circle of a given diameter/radius this results in a given length of the circle’s circumference and it is just chance, how the length of the pattern will fit on the circumference's length. The smaller the pattern's length in relation to the length of the circumference the greater the chance that it will just about seem(!) to fit. However, there will almost always be discrepancies because the circumference's length is usually not a regular (natural number) multiple of the pattern's lenght (at it's given stroke weight). So where beginning and end of a circle's periphery meet you will most likely see these "effects" as the pattern isn't really completed by then or the beginning of it's next iteration will be visible. To avoid this you then start to play around with weird decimal numbers for the gaps (with a simple standard dotted line). I find this really bothersome and actually not exactly worthy of an app that claims to play to prefessional needs. It should be a regular feature that the app calculates the necessary tweaks in the patterns automatically to guarantee a seemless appearance. Adobe Illustrator does exactly that for years by now and you can just click a checkbox in InDesign, too, make your stroke patterns align perfectly to the orners of polygons (which regrettably isn't possible in AD either)... So I guess there's quite a bit to set right in version 2 (latest...)...

Yeah, exactly. That's an important and valid point! I've been thinking along those lines for some time, too. Actually, there are quite a few things in the Affinity apps where it has occured to me that things are like they are just because of Serif wanting to differ from Adobe's handling of things. There's nothing bad, though, in learning from your "enemy“... Ultimately, an intuitive and fluent user experience is what it should be about (and what will eventually encourage users to try – and stick with – the Affinity apps).

Ah, interesting – I wouldn't have known! But actually, in the "tints.afpub" file it's the other way round: the larger object has been assigned its light green color via the swatch (as seen in the screenshot) and the smaller light green rectangle has been assigned the darker green colour which then has been modified via the "Tint" slider. Thus the smaller object's color changes according to that of the original darker green whereas the large rectangle only changes when you directly change its own swatch's settings.

So... I did this and got the mask! I also assigned an adjustment to this mask (so it appears nested to that mask layer in the Layers palette) and using "Alpha" as the adjustment's channel my settings of the adjustment are reflected in the transparency of all(!) the layers below as you'd expect. BUT: as soon as I drag that mask layer (with its nested adjustment) to the thumbnail of the layer I specifically want to mask (as opposed to ALL layers below the mask) my nested adjustment just disappears! What is going on here? Is this how it should be? However, if I drag the mask layer (with its nested adjustment) onto the layer's name (meaning the layer I want to apply the masking to) the nested adjustment stays with it (and can be edited as desired afterwards). And the masking is obviously constrained the desired layer. That's actually what I was looking for... BUT: What exactly is different with those 2 ways of dragging the mask with its (own) adjustment? There must be something with this masking/clipping business that I just can't get my head around... Am I just spoiled by all those years of Photoshop (where masking always seemed so easy to understand) or is Affinity's take on masking really that ”oblique“ that it keeps puzzling me again and again?

Ah, sorry, that escaped me – possibly because it all seemed so complicated... With MEB's explanation of how to alter the tones of mask layers with adjustments (selecting "Alpha" for the channel in the adjustment's dialog) it doesn't seem so important anymore anyway... But thanks, nevertheless!

Thanks a lot, MEB! This really works and I possibly would never have found this out by myself, especially that last part about changing the channel to Alpha in the adjustment's dialog. So you can actually see "live" the effect your adjustment makes to the visibility of the layer or object you're masking, which at least is reassuring. I was really afraid you'd possibly have to go to and fro with grayscale layers turned into masks and back after any adjustments... BTW: when once you have "rasterized" a grayscale layer to a mask – can you actually turn that mask back into a regular grayscale layer at all? With all my trial and error this morning I seemed not be able to achieve this.

Exactly!!! Right at this moment I'm seemingly unable to adjust my mask's tones by simply making a Levels adjustment (which is no difficulty whatsoever in PS) or using Curves. In AP it just doesn't seem possible and I cannot see why this should be so, when I – just as Ron P. wrote – can paint into it and even invert it which all is actually nothing different than modifying the tones within the mask as a whole or in certain areas. It seems to me that beeing able to control an finetune the grey values in a given mask in order to change the transparency of a masked object or layer is absolutel essential tro the whole business of masking.

I totally agree! I've been dabbling around with AP for months now and I really and honestly want to use it instead of Photoshop, but it's just driving me nuts every time when it comes to masking and editing masks (especially when you want to paste something into a mask). The process in AP to me is absolutely counter-intuitive and unnecessarily complicated. The whole clipping and masking business is disturbingly confusing in all the Affinity apps once you want to do something that's a bit more advanced than the simple basic stuff. I don't think that making things different from the almighty competitor just for difference's sake is beneficial to the struggling users (and of all: switchers). You have to admit – however grudgingly – that the guys at Adobe did some things right in Photoshop (and in Illustrator and InDesign as well).

Just added a reralated comment on a related thread https://forum.affinity.serif.com/index.php?/topic/40462-roughen-edges-expand-art-stroke/... Yeah, being able to roughen a path – leaving it pure vector – is still a feature that's really missed. Designer's "vector brushes" (being pixel based nevertheless...) are just no viable alternative to achieve REAL 100% vector graphics.

In my opinion this discussion highlights an issue with Designer that is unfortunately the reason why I'm very glad to still have an older version of AI on another computer. To do really versatile 100% vector artwork Designer needs to have REAL vektor brushes like AI has (and had for ages...) – Designer's so called vector brushes so far are just pixel patterns following a vector path. Accordingly they cannot be expanded and subsequently act as any other vector object (with all their inherent advantages) on the canvas. Somewhat related is the issue that you cannot "roughen" or likewise alter/stylize the vector path in Designer in ways that some of Illustrator’s "Effects" (and some tools from the tool bar) do so convincingly. These features are so helpful in many cases when vector objects tend to look just too clean or sterile – and their usage leaves it all vector whereas Designer's vector brushes just add pixel properties to the vector path. I'd so much like to rely entirely on the Affinity Apps in general and Designer in particular but I keep finding that there are still quite a lot of non-missable features in (even 10 year old – and older – versions of) Illustrator that I just cannot do that so far without giving up ways of designing things for best effect (artistically and technically). Too bad, really...

Yeah, definitely. And some envelope distortion options, too. Missed them dearly recently...

For me I wouldn't actually consider it a „KO criterium“ for not using Designer on the average design job but using the shapebuilder in AI is so much more convenient than the Pathfinder (or Geometry Tools in AD) that I'd feel much more at home with the program if there was one in AD. Same goes for some decent envelope distortion tool (and – finally – support for SVG fonts)... Of course, you can always tell yourself: Well, it‘s not even version 2 yet, but then these are features that aren't exactly fresh on the map, as vector graphics in general go...

I totally agree. The way duplication of layers and groups is handled as of today is definitely not ergonomic and there are enough examples of how to do it better (e.g. Photoshop...). It's just so annoying when you finally want to leave Adobe for good and then you feel slowed down in your workflow by such unnecessarily complicated steps. I actually feel that the Affinity apps generally too often make you resort to a menu or a button when some alt/click or -drag or just hitting the "Enter"-key (instead of going to an ”Apply"-button at the other end of the screen) would intuitively feel like the right way to do the job.

Absolutely so! This is just so intuitively right that I cannot see any sound reason why this hasn't been implemented right away. The people at Adobe are having this right for so many years now and it shouldn't be a shame learning from them every now and then...

Thank you very much, but unfortunately that's close to what I was afraid of: applying more or less advanced math to calculate proper ratios of dash length (or stroke width) and gap for any given size of object isn't really cool... I'd think that's exactly what the computer (and well thought programming of applications) is for... The clever guys at Serif should have a look at this – IMHO – obvious problem. Let's hope for the best (and the next update)...

I'm having difficulties getting my dots of a dotted stroke correctly distributed/aligned, on rectangles as well as on a circle (please see screenshot). Obviously the dots don't care a thing about sitting correctly on the corners of the rectangles as you'd most certainly like them to. How on earth can this be achieved for any given shape? With the circle you see that the first (or may the last? or the first and the last?) two circles (marked red) are noticeably closer to each other than the other circles of the stroke – once you've noticed it, you just can't unsee it... There really should be an algorithm or whatever that distributes the dots (as well as dashes) evenly between any two nodes – I'd really think this is what we want when we use a dotted or dashed stroke even if this means that the distances between the dots/dashes are slightly adjusted to fit any segment between two nodes. Or is there already a solution which I haven't discovered so far? O

Hi Walt, I think I know what you mean, but but when – after I click "Revert Defaults" – I use a tool like the shapes tool and the shapes now have default appearance to me it's like I actually reset the tool as such because future "products" of the tool will have the default apperarance. But you possibly could argue about this view. More important: with my Publisher v. 1.8.3 it "Reverts Defaults" for ALL kinds of "future" objects even if only a single distinct object is selected when clicking the button. So for example, when a somewhat formatted circle is selected while clicking the button, all future text frames will also be reverted to the defaults, not only that circle. Naturally, any object already given in the document remains unaffected if it's not selected while clicking "Revert Defaults". This seems to contradict your statement, doesn't it? Or do I get something wrong?

Oh man, this is brilliant – thanks a lot! I didn't even notice this buttons until now... And it's even got a companion button to "Synchronize defaults from Selection". The only downside I see so far, however, is that EVERY tool seems to get reverted to default, not just the type you're currently working with (say text frames) – shapes, typopgraphy, everything. I could imagine, that being able to do this separately for the various tools (e.g. via a button on their respective palettes) would be an interesting improvement.

Maybe this could also be applied to other tools but I came across the topic when working with text frames: Currently, when you change any attribute of a text frame (like the number of columns, background or stroke colour or whatever), these new properties become the default for any new text frames created subsequently (until you make new changes to these). This can can be quite unnerving, especially when you've just set some special attributes for the "odd text frame", while you would really like to use another more standard type for most anything else. As of now it seems you have to manually reset all the special attributes to "normal" before you can get on with frames having your desired standard appearance. I think it would be really helpful to be able to choose (e.g. in Publisher's preferences) between this current behaviour and a behaviour where you once set a standard formatting (e.g. while no document is open) and this standard/default is then used for any new element you create later in any actual document (meaning any changes made to – say – a text frame in a live document remain with that very text frame only and do not automatically affect any other frame created afterwards). Or – maybe even better – keep the current behaviour but combine it with the option of setting an applicationwide standard beforehand which you can revert to any time you wish by just clicking on a button in the – with this example – Text Frame palette.

Hi thomaso, I'm using Acrobat Pro 9.5.5: v183 black text & doc col space_embYES-convNO.pdf > all blacks are "rich" RGB black (and stay this way, regardless of what I set as the simulation profile in Acrobat Pro) – when I change the profile I see subtle changes in colours of the pics (as you'd expect) – I don't have the PSO Coated v3 profile, though (as I don't ever use it) v183 black text & doc col space_embNO-convYES.pdf > blacks behave as they should (100 K text stays that way, regardless of what I set as the simulation profile) – pics' colours change a bit (as expected) v183 black text & doc col space_embNO-convNO.pdf > blacks behave as they should (100 K text stays that way, regardless of what I set as the simulation profile) – pics' colours change a bit (as expected) This seems to correspond to your findings, doesn't it? As soon as I have time for it, I'll double check the PDFs I've exported myself to see if I can replicate this. But – be it as it may – it's certainly more than a bit unsettling that for the time being it seems so hard for Affinity Publisher to offer the easy and (most of the time) flawless PDF output which InDesign has been offering for years by now. With Publisher it still feels to me like you actually have to fight for your PDFs to come out right and that's definitely not good for an app used in a real life print production workflow... With one of my last jobs there still were RGB-elements in my PDF although the file's colour space was CMYK (ISO coated v2 profile) and the profile set for PDF export was CMYK. It took quite a bit of trial and error before the PDFs were finally OK... What I also miss dearly is the ability to actually convert RGB colours to CMYK within Publisher or (at least) to just globally replace an offending RGB colour with a specially created new CMYK swatch. Sometimes when you're using external elements (e.g. logos supplied by clients) these are not necessarily in CMYK colour mode and their RGB colours sort of "spam" your colour palette. Actually the whole colour swatches/palette thing is not actually convincing in the Affinity apps, I'd say... You cannot even – like in the Adobe apps – "add used" colours (or "colours in use"), can you? Meaning colours you mixed and just assigned to an object without creating a swatch – or colours from objects you pasted into your document. You can do this in InDesign easily and it's really annoying to me that you cannot in Publisher (unless I missed something here).

Absolutely so – it took me quite a long time to finally grasp what "numbers" InDesign was referring to... To be perfectly clear "Keep Color Values of non-Image Objects" would be even better. I seem to differ from you here: I actually think that any colour translation should be default be applied ONLY to images as "normal" colours which you'd generally apply manually to any object (vector – or possibly – black & white or greyscale images) wouldn't hardly be the plus 300% coverage kind and should be left as set (see my example of a logo with clearly defined CMYK values). Maybe there could be an option(!) to convert these coulors as well, if one decidedly wants to.

Choosing the settings from your screenshot doesn't make a difference: 100 K black is converted to 70C/60M/58Y/84K when the profile used for PDF output differs from the document' s profile. Yes, sure, I did intentionally use another profile for output as the the original document's profile as this is what definitely should be possible using colour management: being able to deliver PDFs with fitting profiles for various printing environments from ONE and the same document (without changing the original colour profile of the document itself). The necessary conversion is – in my opinion – the key feature when you have to deliver to different printers / printing processes and this conversion process MUST honour essential settings as 100 K for black text and the keeping of values/"Numbers" for non-image (i.e. vector) content (just think of a client's logo having fixed/defined CMYK settings). So this – somewhat oddly named – "keep numbers" feature of InDesign is something that has to be implemented in Affinity Publisher as soon as possible.

Coming from Adobe InDesign and actually being highly motivated to finally switch to Affinity for good, I find the way Affinity Publisher handles these things very irrtitating. From the start it has been the desired effect of efficient colour management that you could design your document in a certain colour space (say: the one appropriate for offset printing on coated paper – using the corresponding colour profile as your file's colour space) but NOT being confined to that colour space chosen in the beginning as you could choose another colour profile later for outputting to PDF, should the necessity arise to have your design printed in another way than originally intended – e.g. on newspaper stock where different printing colours behave totally different on different paper. This has hardly ever been a problem in InDesign as during output colour spaces have been converted quite reliably from the document's colour space to the colour space of any special printing process for which you'd need a PDF equipped with the corresponding colour profile. However, with Affinity Publisher, it somehow doesn't work this way: I have done some testing today in Affinity Publisher 1.8.3 with 2 afpub-files – one setup with general European standard "ISO Coated v2" and one setup with "ISO Coated v2 300%" which is pretty much the same profile but with a reduced ink coverage of 300% (which is preferred by many online print services due to shorter drying time of the prints). I was especially concerned about black text (100% K) being unadvertedly converted to mixed CMYK values as this is something you really just DON'T want. Checking the created PDF-files with Acrobat Pro showed that 100% K text had only been preserved in the PDFs if the document colour space was exactly the same colour space that you had chosen in the settings for PDF output (here PDF/1-a:2003). Meaning: document (ISO Coated v2) > PDF (ISO Coated v2) and document (ISO Coated v2 300%) > PDF (ISO Coated v2 300%) both kept black text just in 100 K as intended – no matter if just the »standard« black colour swatch from Publisher was used or a new, specially created 0/0/0/100 global colour in the »Document« palette. So far so good... However, going "crosswise" by document (ISO Coated v2) > PDF (ISO Coated v2 300%) or document (ISO Coated v2 300%) > PDF (ISO Coated v2) both ways of profiles not matching for document and PDF output got the previously 100 K text converted to that "rich black" of various CMYK values that you get when you convert RGB Black to CMYK. You don't want this EVER. To me this behaviour seems to completely ignore the intended use of colour profiles for being able to create PDFs with different colour profiles for different printing scenarios from the SAME original document, which most professionals have used succesfully for years with Adobe InDesign. Why does it get so complicated with Affinity now? BTW: Changing the Colour Profile used by Adobe Acrobat Pro while examining the PDFs between the 2 profiles mentioned resp. used in the files doesn't change anything about the values that are given for the black text elements.

Yes, that is correct – I'm using the regular Magic Mouse that came with the 2019 iMac. The context menu from the right mousedown looks (maybe is) just like the one I get from Control-click and everything except the color options at the very bottom works as it should. It's a bit strange... As I've just verified: It's exactly the same in Designer – layer colours via right mouse click context menu don't work (but everything else) but colours can be assigned when going by Control key with regular mouse click. I don't really see where such a behaviour could possibly be set. Apart from that: Wouldn't it be convenient if double clicking on a layer would offer a dialogue with a few (very) basic settings for the layer (similar to Photoshop's behaviour) like quickly assigning a color or renaming the layer?