Paul Mc

An update: I ended up sending the file to a friend who has a copy of AI. He was able to read and then re-export as an EPS and that reads fine. It is still a bug but I'm able to proceed.

I'm trying to modify (another) PDF artwork file created in AI. The file doesn't import correctly but doesn't show any errors. In an attempt to figure out what was happening I found out that exporting the result back to a PDF also causes an error and fails to create any file - other than flatten which doesn't help in my case. I enabled debug and found this in the resulting log file: [Last exception 1404 in PDF_shading]["Option 'stopcolors' has too many values (> 500)"] I'm wondering if this provides any clues as to what might be wrong. I can't provide the original artwork as this is confidential. The file contains a background image with a repeating pattern which I think might be the culprit as it imports as a stretched image and not evenly spaced at the original size that you see using Acrobat Reader . I don't have access to AI where I am to check any of this at the moment. Any thoughts? (Affinity Designer 1.8.5 for Windows) The 1.9 beta also behaves in the same manner.

That was my original expectation. If this works with an IDML file and the PDF import sets things up like this (to give the impression it would work as a Global) then hopefully there is code in the app that can make this work correctly and it just needs a little TLC to get it across the line.

My copy - Edition 1.0 (Reprint 6) has this content on page 113 and looks fine. I realise that this might not help the OP but others may hesitate to buy the book when this issue may relate to an earlier reprint.

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.