Jump to content

rnbutler87

Members
  • Content count

    20
  • Joined

  • Last visited

  1. Ah my bad! What a relief - the end of a long day and was really starting to tear my hair out about this one. Thank you again!
  2. See the screen share: https://www.useloom.com/share/7ed69a9106504bd3bf2f0aaad72c37dc Note: - Basic brushes work as expected (i.e. you can remove the stroke on duplicated strokes). The problem just seems to be on textured brushes. Whether the inbuilt ones or ones I have made myself. - It doesn't seem to matter how you duplicate the stroke - Holding ALT and dragging / CMD + J to duplicate the layer / a simple copy and paste - all subsequent strokes will result in being unable to shed the line. -------- I'm trying to stay objective especially in the bugs forum but this is the third bug today and this one in particular is a massive blow to production workflow - Can you say if these will be fixed in the 1.7 beta?
  3. Please see vid link: https://www.useloom.com/share/3db0fee3bd294fec8a72536cab9f9c66 Hopefully this is a bug and not by design. Would love to hear any thoughts. Thanks, Richard
  4. rnbutler87

    Symbol attributes become unlinked in unexpected ways...

    Hi thanks for the reply. Here is a link to a screen recording: https://www.useloom.com/share/d42ae912451e4e559d9c9bc6a84c9f3d If I do not duplicate the symbol first before moving it into the body group, attributes do not become unlinked. However, if, as demonstrated in the video, I duplicate the symbol first before moving it into the group and then adjust the stroke width, then the symbol attributes become unlinked. (I've attached an updated version of the file with global colours added - (I read another comment on a similar subject that was occurring with objects that had global colours. Whether that matters or not I don't know but here is the updated file anyway.) On a general note, symbols do seem a little unstable as I've found that general manipulation of them results in AD crashing more so than when doing anything else. And other strange things like if I want to amend a symbol (in this case e.g. lets say I want to draw some eyelashes in the eye symbol and move them into the eye group, they immediately have unlinked attributes which I can't do anything about.) Anyway, hope this helps and am eager to hear your thoughts. Thanks symnol-stroke-unlink.afdesign
  5. I have a symbol (some eyes) that when the parent symbol is selected, I can manipulate the stroke width of the constituent parts of the symbol using the slider of the stroke window. No problem. However, as soon as i put that symbol into a group (the body, lets say) and then select the group and manipulate the stroke width of the whole group, the symbol stroke attribute becomes unlinked. This seems odd and unexpected, especially if I continue to manipulate the symbol in some way, the program often crashes, making me think that this isn't expected behaviour. I have attached the file, hopefully it's contents and what I am trying to do are self explanatory. Let me know if you need any further information from. Thanks, Richard symnol-stroke-unlink.afdesign
  6. I can reproduce it by inserting a symbol into a group and changing the groups stroke settings...
  7. Ahh this was good to see, thank you. So the bitmap is also being sort of mirrored but not 100% exactly... I'll create a topic in the bugs forum and refer to this post. Many thanks. EDIT Wait, I've read it again and you're saying it is behaving normally because the stroke isn't along the centre line...?
  8. I've got some textured brushes which look awesome but when the curves are flipped, the lines become 'off'. The points are clearly flipped but it's as if the way the texture flows down the curve is not flipped. I know the solution would just be to expand the curve to be a fill but I need the stroke widths to remain editable. I want to flip the 'artwork' not just the mathematical points which make up the artwork. Is this something which could be looked at in the 1.7 beta?! Any advice would be greatly appreciated. Richard
  9. Thanks you, this is great to know. I've also downloaded the latest 1.7 beta (updated on Tues, I think) and tried the recolour in a CMYK doc and it no longer crashes!
  10. Thanks for taking the time to explain this. I may have to read about this more as not sure I entirely understand why HSL doesn't lighten black but it lightens other colours, even in CMYK. That being said, a CMYK document in photoshop behaves in a similar fashion with the HSL not lightening black very much so I suppose this is how these apps are designed to work. This is excellent! And it works on CMYK which is awesome. The ONLY thing is, in my 1.7 beta, if I lighten something and then shift the hue, the app crashes instantly. I suppose this is why it is still in beta tho... Anyway, thank you for all your responses, this has helped clarify things immensely so it's greatly appreciated. I look forward to the 1.7 version of the app going live.
  11. I think I've diagnosed the problem - I'm currently working in CMYK and experiencing this problem. However, when I change the document colour format to RGB, it works as expected.... Is this expected functionality for a CMYK document? Many thanks.
  12. This is what I would expect too and I can clearly see it works for you but I'm still having no luck - I've even opened a new document and tried it in the Beta too... Affinity Designer 1.6.5 Affinity Designer Beta --- Any suggestions? I've also attached the AD 1.6.5 file should this be useful... Thanks again. AD_HSL-test.afdesign
  13. Hi thanks all for your replies! I suppose it's just for the continuation of a workflow I'm used to using in Photoshop. However I can adjust to alternative ways of working i.e. using a colour overlay effect (even though this seems buggy - it's very laggy to respond to colour wheel changes in the colour overlay effects (as opposed to the document colour wheel changes) and crashed yesterday when I was applying the colour effect across multiple objects...) It does seem to be lightening black but not very much, even at 100% - I would expect all colours, even black, to be completely white at 100% lightness. I've attached an example of what is going on in my document when using an HSL adjusment layer. It's at the top of the stack, set to normal, everything else is below it and only applied to the red square area so you can see the result. Is this expected functionality of is there any reason why it's not applying to the100% lightness to blacks? (I can think of some great examples when this would be useful but not in this instance!) Again, any thoughts would be appreciated. Thanks.
  14. I'm trying to move away from Adobe and use Affinity products exclusively. Things are similar but on this one topic I can't seem to make headway. I have small black pixel graphics imported from Photoshop. And in Affinity Designer I'd like to colorize them using an adjustment layer, similar to how I'd do in Photohshop. However, the Lightness slider of the adjustment layer in AD doesn't seem to affect (i.e. lighten) black like it does in Photoshop and therefore I can't colorize the black graphic. I've found a way around it in AD by using the colour overlay effects set to screen or similarly putting a shape above the graphic and setting it to screen. However, out of curiosity for future use is there an adjustment layer in AD that will colorize black similar to that in Photoshop? Any help would be greatly appreciated. Kind regards, Richard
×