Paul Mc

Thanks @Lagarto for the details instructions. I have been experimenting since posting and I ended up doing what you have suggested to get to the point where things worked as I expected. I now have something I can use for the pre-visualisations. Hopefully this will be fixed in a future release. Kind regards

Is it related to this post:

I've noticed a few issues surrounding problems with Global Colours and I'm not sure if my problem is part of that so I thought I'd ask. I've been provided with a PDF that I have to modify where the original design uses a pink colour for a white overlay. It is included in the PDF as a spot colour and appears in the Colour panel as below: For the mock-ups I'm doing need to change this to pure white. In the past, when I've originated the artwork this has been a simple matter of editing the single spot colour and everywhere it is used it changes. This appears not to work here. First, I can't find the palette in which this spot colour resides and second, clicking the Edit Global Colour button and changing the colour appears to have no effect. Am I missing something?

I think @kaffeeundsalz has it figured out. Selective blurring on masked layers is almost certainly how this result was achieved. I think camera motion is unlikely as the blur effect looks very precisely horizontal and vertical.

@Old Bruce's method is probably the best way to do it but you can get a long way to your objective using a preset or two in the Export Persona as well. If your source images don't have the correct aspect ratio then you are going to have to set up your slices to define the crop you want then it's a single click to get the file output.

@walt.farrell apologies for belittling your comment. Like I said, I can navigate anywhere in my file system using the menu Export so I don't see how this makes anything more secure. This is an OS and permissions issue making the app responsible for this level of security seems the wrong way around.

@Lagarto thanks. I'd noticed that it was only relative but in Windows-land .\ and ..\ are valid elements of a relative pathname and they are considered invalid - or are at least displayed in red which I'm interpreting as invalid. I agree about leaving them untouched though. I'm currently working on four designs in parallel and the Export save dialog box "remembers" the last folder I used by the program rather than the last folder used when exporting this design. This is an inconvenience and a hazard given that the filenames are similar and could be mistaken for one another. What I want is for the files to be deposited in a well-know absolute folder location so there is no confusion. Yes, I could choose the parent folder directly in the Export dialog box but that seems to defeat one of the main benefits of the configuration function in the Export Persona. @walt.farrell Thanks for your post. How so? Please would you explain what vulnerability this presents? I hope you were grinning when you said that! Just in case you weren't - I feel that is more work to achieve a simple result than should be necessary. The fact that I can export via the menu or keystrokes to anywhere on my file system is something I'd expect of any file saving mechanism in any application. However, there is not the same functionality as the File | Save as.. or Export menu options when it comes to specifying the output file location in the Export Persona.

Is this TIFF the input or the output? What is your source image? Are you starting from a RAW image file? What is your workflow i.e. the steps that you took to get to the blurry result? First, try just importing the image and immediately exporting at 1:1 and then compare the results outside of Affinity. Does this show any difference? DPI is unlikely to make any difference here. What you need to check are the absolute dimensions of your image in pixels. This image is 6024x4024 pixels. Depending on your answer to my first question, does this align with the source pixel dimensions or is it different? Any scaling (or resampling) of the image, up or down, can sometimes make the result a little soft or blurry. Have you tried printing to a PDF to see if you get the same result? I'm a little puzzled as to why exporting to JPEG, TIFF and PNG is mentioned as you can print directly from within Affinity Photo, are you using another application to do the printing?

Thanks @Lagarto, thanks for confirming. I hadn't noticed that the rotation reset might be related to the previous tab's view orientation. This is definitely something that could be improved. i.e. Rotation really needs to be saved with the file (like position and scale are) and also added to the saved views in Navigation. The scrollbars are a little more difficult in that what's right might vary between different use cases. Maybe a modifier key (Alt?) could change the function so scrolling to the top without it scrolls to the top of the window and with it scrolls to the top of the canvas taking into account the rotation?

So I'm reaching the point of delivering work to the client and need to export to a different drive. I just changed the parent path in a bunch of files and clicked Export Slices and promptly found a new folder called "D" which contained all the exports. I was trying to export to "D:\Dropbox\..." and found the new folder contained a subfolder called Dropbox. On closer examination I find that the path in the parameters section of the slices wasn't as I'd entered it. The colon after the drive letter was omitted. As this was a copy and paste step I knew that it had been entered correctly. After a bit of searching on here I find that this has been discussed before but no resolution proposed. From a UI/UX perspective I've always believed that code should never change the data that a user enters without letting them know that it has happened and why. In other instances this edit box changes the text to red when things aren't quite right but doesn't prevent the text being entered - although still doesn't explain why. e.g. A full stop/period (or two) in Windows is a valid (relative) path. I know I could use links to make this work but I really shouldn't have to. I'm guessing that this is a problem due to the Mac centric development of the application where colons are outlawed in file and pathnames. I'm hoping that because this has been raised before that it is on the roadmap (although I can no longer find that to check). Any chance of any feedback on whether this is likely to be addressed?

Just to add to this: the scroll bars are also inverted after a rotation. This morning's session has revealed that depending on the last operation before a tab switch the rotation of the view may or may not reset however on touching the scrollbars when it appears to be OK suddenly causes the view to reset. This is consistently happening with a view that is rotated by 180 degrees. After the initial rotation of the view the scroll bars appear to operate in reverse, what I think is happening is that the scroll bars are changing the view position of the original orientation and then applying the rotation which for a 180 degree rotated view is completely the reverse of what you'd expect.

Hi @Old Bruce Apologies, yes it is in Designer that I'm observing this effect. Maybe this is a Windows only issue as that is what I'm using (Windows 10 Pro). It looks like the saved views are behaving consistently as I too see the position and scale saved but not the rotation.

Hi everyone (is there a collective noun for Affinity users? ) I'm working on some packaging where text appear in different places with different rotations. I have several to do with reference information coming from a text document from which I copy and paste segments. I'm able to rotate the view to work with upright text for any location on the package no problem. However, when I flip to another tab and then back again I find that the rotation has been reset. Is this to be expected? Is there a way to lock it so it doesn't do this? Also saving rotated views in the Navigator advanced section appears not to work.

You could go to File | Document Setup and resize the document to scale everything to the target pixel dimensions you require; use the Export Persona (my preference, because if there is any rework and you need to do this again everything is all set up to repeat on a single click); or File | Export... and set it to the dimensions you require at that point. Resizing the document will give you a tad more control if the smaller image requires any "treatment" to make is acceptable at that scale e.g. very thin lines or image sharpening (if you have access to Affinity Photo). It might not apply to your poster but if you have any other graphic elements in the design you might want to check that scale with object is checked on all your strokes so that the objects will scale proportionally.

Hi Maurice, that's what I did. My results can be seen here: For a curve with a single stroke "Appearance" this is fine and appears to work correctly. For those with a stack of strokes of different widths this seems not to work as expected - at least for me.

Hi @DWright I think he did although it is difficult to know for sure. For what I want to do I understand that with the current version of Designer there is no procedure I can follow. In my explorations I think I've uncovered several bugs as well which Dan appeared to acknowledge and said he'd passed to the devs. The timescale on my current project (deadline today) means I can't wait for the fixes/enhancements so hopefully these will be of benefit in the future. I've found another way to achieve my result using SVG exports and InkScape. Dan's response was very prompt and encouraging. Knowing that this type of edit wasn't possible was useful information so I knew I had to use another method. I hope my post also provided some insight into my mental model of workflow expectations and might provide some input into future design decisions such that they are more complete and robust. I realise that might sound a little selfish but I'm also a developer and know first-hand that I'm an "expert" in how my own code works, however I've learned over the years that this also presents an obstacle in trying to understand it from a user perspective. I'm happy to make myself available for any discussion or testing of these kinds of things.

Thanks Dan It's good to hear that some of this will make it into the specs for a future release. Regarding selecting multiple objects with different combinations and permutations of strokes; I agree with what you are saying. However, when all the properties for that panel are the same then this becomes straightforward. Maybe the new Select Same feature might lead to something workable in this area? Alternatively, why not show nothing with the intention of any edits simply replacing those attributes on the selected curves? Because you currently show something it suggests that those attributes apply to the selected objects when they may not. E.g. select a few curves of different widths, the stroke width slider is still visible and can be dragged to change the thickness of everything selected. I look forward to seeing improvements in a future release. Thanks for the prompt response.

Hi @Dan C, I've just posted the results of my research here I will see if I can get a release on the client work to send you the file. Thanks.

This post comes from my frustration about having to rework a significant part of a project because of problems with the Appearance panel. I have posted about this previously but thought a new thread would be better. The Appearance panel, in my recent experience, is an incomplete design and implementation. I'm guessing that it was introduced to satisfy some requirement but it wasn't completely thought through from both a UI/UX and a functional perspective. In the normal use, we can create a curve and then over in the Appearance panel we can add an extra stroke. Fine. Note that without the curve selected the Appearance panel reverts to the regular Stroke panel properties. We can then duplicate that curve. Selecting either curve shows the stack of strokes as expected. Selecting both curves (with identical attributes/properties) will only show the "base" stroke/fill properties and the new stroke properties are not visible. There might be a good reason in the code for this but from a UI point of view this is very unintuitive and unexpected. Because the new stroke properties are not visible, any changes to the properties of any additional strokes or fills can only be made if a single curve is selected. In my case there are hundreds of strokes that need to be changed so this isn't a reasonable possibility. The problem which started all this was to draw a leaf and then scale it to fit into another illustration. For context, there are many leaves and each leaf has many veins. The veins are drawn using two strokes in Appearance, one thin light green and and outer one (underneath) that is dark green. Scaling it produced this result whereas I wanted the veins to scale proportionally with the leaf. In this case the upper stroke completely covers the lower one. I also have some issues with the Paste Style operation. It seems to work some of the time. As an alternative to the above method I was expecting to be able to select a single curve, set its attributes, copy it, select the other objects and then Paste Style to have all the strokes in the Appearance panel be copied to them. This nearly works but I'm seeing different stroke widths appearing on the strokes above the base stroke. The base stroke in my testing appears to remain set at the copied source value. Any strokes above it seem to get set to random values. Again, because you cannot select multiple curves, and access the additional strokes, fixing this is not possible without editing individual curves. So then, as an experiment, I thought I'd copy my leaf object with a group of curves and paste it as a New From Clipboard document in case that would reset something and allow me to continue. The stroke widths changed. Subsequent scaling/resizing of the object only scales the stroke width of the base stroke - as expected. I'm guessing that this is a completely unrelated issue so won't discuss this further as it is a distraction from my getting my problem resolved. In my particular instance all of this would have been avoided if the Scale With Object checkbox had been checked in the new stroke before I used it to draw the veins of the leaves. It was set in the parent group and the base stroke but not the top stroke that I added. I've been unable to figure out a way to select all my curves and then apply that setting to them all without it causing problems. All I want to do is scale the leaf down to a smaller size without the strokes looking fat and out of scale. I can't see any reason why this isn't checked by default. The situations where you would not want this checked seem (to me at least) very niche. Alternatively, Preferences could have a default setting for this if my expectations are wrong or biased. Back to the UI and user expectations, checking Scale with object in the stroke should really be setting it in all the Appearance strokes too (IMHO). If I had two strokes in Appearance with one checked and the other not checked then what is the point of having it checked in the Stroke panel? In addition to this inheritance seems to be a bit hit and miss. If I collect the curves together in a group or layer and then check Scale with object shouldn't that be applied to all objects within the group? I'm sure I'm missing things and there may be a way to do what I want but after several hours of research and experimentation I could not discover how that could be done.

I've been drawing some leaves and they have an outline and a fill. Overlaid on top is a group of curves to represent the veins in the leaf. These use two strokes a thicker dark one underneath a thinner light one (with no fill). Now I need to scale the leaves. I thought I had set Scale with object on everything but it appears not to have been set on the lighter stroke. So how to update all the curves (several hundred of them) without selecting each one and modifying the setting? (As an aside Select same in the Beta doesn't provide an option to select just these as the double stroke in Appearance is not a match option). Selecting an individual curve allows it to be updated by clicking the stroke with in the Appearance panel. Selecting a group and toggling the checkbox has no effect on the stroke Scale with object setting. Selecting multiple curves and then going into Appearance only shows a single stroke setting and not the two that they all possess. Selecting a curve, copying it and then selecting the group and pasting the style doesn't appear to update all curves either.

Thank you @Old Bruce. If you draw a curve you can then set/adjust the stroke width either via the tool or the curve properties. It is then an attribute of the tool or curve rather than that of the brush pattern. Therefore, it's not an unreasonable expectation (IMHO) that if you change the brush pattern it preserves the stroke width previously set on the brush tool or the curve. Maybe there's a good software reason for this but from a UI/UX perspective I feel that it's not very intuitive. Thanks for confirming that this is just how it works. I will check out the beta and see if there is anything new there that helps.

Is there any way to lock the brush size when changing brushes? There have been a few instances recently where I've created a drawing using curves, or imported an SVG from Blender, and then wanted to apply a brush to the curve(s) retrospectively. Selecting a new brush sets the stroke width to that set in the brush settings. Doing this with a group overrides any difference in the stroke widths within the group. This is especially frustrating when experimenting with different brush styles as each selection then requires and adjustment of the stroke width to something acceptable. Invariably all the brush sizes are too large for the designs I'm working on. Am I doing this wrong or is this just the way it works?

I've just checked a few of my exports that I use with Blender and this is sprinkled throughout them. It hasn't caused me any problems though. This is a well-formed namespace:id so is valid XML. This means it should be read by any other software that reads XML and ignored as they are not likely to be interested in any data from that namespace. What kind of error message or problem are you seeing?

Just a thought. This banding looks like it has been rasterised for printing. You've not sent this out of Sketchup to a PDF file via print capture have you?

The afpub file includes embedded images which are constructed from a set of horizontal strips. The streaks appear where the strips touch. This will be due to anti-aliasing of the strip edge on both sides not being completely opaque. I loaded Back persp.pdf into Photoshop and it behaves the same way. It looks like Adobe Reader/Acrobat "knows" about the overlap and probably does a linear transition across the tile edges on the source image before resampling for the view. Photoshop and the Affinity programs don't know that this is how it should look so they use a different anti-aliasing method where the background leaks through the adjacent edges. I would suggest this is a problem in the export rather than a problem in Publisher. If you can export as a regular bitmap then this would go away. As this isn't a vector image there is little benefit in exporting as a PDF.