p10n

Daniel you are so right! I was referred to your post, from my one, see I now tried to explain why the current behavior of AP is unnecessarily obstructive (if not buggy), I hope my explanations help. My solution will be to use AP to create the headlines and background graphics, and insert copy text and the links in LaTeX (using the wallpaper package to include the AP-generated PDF as a background). This has been working very well with PDFs that I have created earlier with Inkscape.

Yes, HTML would be very reasonable to use. However, PDF has some advantages here: We want to design it like a printed matter (such as the linked manuals are), I do not want to deal with line wrapping, window size etc. It should look good when printed We do not want users to need a web browser as well (I think it is nicer to have one tool for all documents) YMMV, of course. (I was so happy to find that Serif had thought of file links, but then got frustrated as it turned out not working. If Serif would want me to use HTML, why would they have implemented the "file" link option? 🙂 )

Thank you for the link! The original poster (Daniel Gilbert) is fully correct. He basically makes the same point: The only thing AP needs to do is to write a URL into the PDF file. As long as the URL conforms to the standard, it is a bug (or at least very unexpected, bad behavior) that AP removes the link from the generated PDF for no forseeable reason. The other problems mentioned further down in the thread are related, but do not argue logical a root cause. Let me explain: 1) Spaces in the file names: I would try to avoid spaces in file names, but it is possible to have them – you just need to properly encode them in the URL, as it is explained further down in the thread. Ask any knowledgeable web programmer. If anything, this would be a reasonable thing for AP to do here. (Check that the URL conforms to the standard.) 2) Slashes versus back slashes ("/" vs "\"): URLs or file paths should be system-independent, and I am sure all PDF readers, also on Windows, will adhere to the standard here (which is to use forward slashes "/"). Same as 1, if anything, this would be reasonable thing that AP could check (see 1, ensure standard-compliance). 3) The excuse that "AP refuses to export because the URLs are invalid" is imho not a good one: I agree that the job of AP is to verify that the URL is syntactically correct (adheres to the standard), and yes, AP should warn if it is not. BUT, it should not just delete the URL from the PDF, just because the link target is not present. There are users who know what they are doing, and you should not hinder them from using AP. Issue a warning, but go ahead if the user wants to. Summary of 1-3: Affinity, please do not obstruct users, rather help them create a standard-compliant URL. 4) I did not check, but it looks like AP is storing absolute paths in the AP files? If so, I am worried, and I would never ever use this then. Storing absolute paths in files is BAD in most cases. Suppose I move the whole AP project from one folder to another, or I archive it to an external disk, or I send it over to a colleage to work on it. In all these cases, all the links will be broken! Thanks for reading my long post - I hope I explained it in a logic way. I want to avoid that other AP users despair because if this stubborn behvaior of AP, and that they need to use different tools, like Gilbert and me.

Oh, thank you - I was not aware of this! However, this does not alter the problem. My user manuals are generated from LaTeX, and will be copied into the target directory at a later stage of the publishing process. So having AP copy anything anywhere does not make sence. I just want to create this one PDF in AP that has links to a few other pdf files that I know will be present (and yes I know their name exactly, and they do not contain any spaces, totally simple). I do not understand why AP behaves so stubborn. In 98% of use cases you want a relative path. 1% being you create the PDF for a company network where everything is fixed on all workstations, and the other 1% is you are trying to make your users go crazy when they try to copy the parent folder somewhere else. (Sorry for sarcasm.) How did you manage to create the links to relative paths? Does AP convert the links to relative ones, when you let AP copy the files? If this is the workaround, I would have to create 10 dummy files for this, and delete them afterwards...

Goal: I wanted to create a PDF file to serve as a starting page for all user manuals of a software product. This one-page PDF should contain links to all the user manuals (which are PDF files residing in the same folder as the starting page PDF). While no problem with LaTeX (hyperref package), this seems undoable in Affinity Publisher; moreover, the interactive --> File link function in AP appears like a bad joke, looking at the following problems (I do NOT want to embed a file, just link it, thus have unchecked the respective box): 1.a) If I choose type "file", and type a file name like "filename.pdf" the link will not work even though the target file is there. 1.b) If I select a file, AP (seriously!) inserts the absolute path in the document, and thus also into the PDF. So the PDF will only work on my MacBook/PC. Who on earth would do such a thing? 1.c) If I manually delete the folders from the file path I get from 1.a, so that just the file name remains, then on export AP claims that the link is invalid, even though the target file is present. Huh!? 2) If I choose "URL" and type a valid file URL, e.g. "file://MyFile.pdf", the target seems to get modified to be all-lowercase (which kills the link on all case-sensitive operating systems (non-Windows) if the target has uppercase letters). None of these links in a created PDF work on OSX, none works on Linux (did not try Windows): On OSX just nothing happens. On Linux, at least there is an error message - according to that, links from 2) seem to be interpreted as SMB URLs (e.g. smb://myfile.pdf ) which is even more weird. Normal http:// website links do work for me on OSX as well as on Linux, so I think I am not doing sth wrong in general.

You might also look at Corel, they are back at the Mac OS market! You can even BUY their products, as an alternative to the subscription - which I think is very fair. I tested Corel Draw on the Mac about a year ago: It looks different, but all the settings / templates are very intuitive and clear - e.g. showing what is inherited from a default and what is different for each item! If I would not be caught by having so many Affinity files, I would instantly go for Corel. The price is higher, it is a professional and complete product.

Actually, DefaultFolderX is a huge overkill. To get a major part of the desired (sane) behavior, all we need is one single feature of DefaultFolderX. You need to activate it by that tiny little option saying "In Save dialogs, use the current folder of the file" – see screenshot. However, as someone else wrote, I, too, am not so happy installing lots of system tools, especially if I only one need ca. 1% of their features. And, yes, I am 99,9% sure every programmer can override the immature default behavior of the OS X file dialogs – its obviously one of the first things most app programmers do...

I think a good behavior would be: 1.) Save As: Default to the current file's folder. 2.) Export (pdf etc, but also for palettes): Default to the folder where I last exported to, when the current document was open. At first time, use current folder as in 1. (Also Corel has always been much smarter with that, for decades. To be fair, its a different price range. If the Mac Version of the Corel Suite would have came out 3 years earlier, I would now happily be using Corel.) Affinity seems quite stubborn here. Looks like we have to buy DefaultFolderX to make the Affinity products complete.

Yes its a real pity. But, never give up!

Should this be in the OS X version of AD? I can't find the icon the help is suggesting. BTW. Why doesn't Scale just obey the center that I dragged somewhere for rotating? (Feels like the center was forgotten when implementing the Scale function...) Edit: Ahhhhh I have to press cmd while scaling!!! Thats weird. Would expect the same behavior for Mode and Scale. Anyway, it works. Thanks!

In one of the screenshots on https://www.stclairsoft.com/DefaultFolderX/ , there is an option labelled "Default to current document's folder in Save dialogs" — that might be what we need (assuming that Export also goes as a Save dialog). We should probably have a look at it!

They seem to not bother, and let OSX do its default handling of the folders. As far as we know, it would not be difficult to override or improve that in an application. (Besides, other vendors seem to manage to do it properly without problems...) Yes, disappointing. :-(

Yes Yes. In most other OSX apps, you can get the current working folder by right-click on the icon in the title bar. But in Affinity this does not work either – it would have made the workaround a little bit easier. Serif seems to be totally deaf regarding the Save-location problem. No idea what their UX guys say (they must be screaming I thought). Seems like we have to keep wasting our time for navigating the same folders again and again, and for searching and cleaning up after saving files into wrong places...

I am quite sure that this is just the default behavior of the system dialogs. There must be a way for an app to explicitly set a folder for the dialog...

Thanks for supporting this thread! Yes it does not seem to be given big attention, despite its something that hinders my workflow again and again. Above, someone said this weird behavior is a feature of OSX. Might be (OSX has other stupid things as well) – but I think the existence of a poor standard behavior should not be an excuse for not improving it. I am sure there is a way to optionally overrule it. Maybe we should create more buzz on facebook?