mmmccckkk

I know there is a possibility to export PDF-X1 (PDF 1.3) file from Affinity apps. But this file (by definition) cannot have color profile included, which may (in less experienced or not much color-aware printshops) result in unwanted results. There is a possibility to include a color profile, but only in PDFs 1.4 and above, which does not ensure proper flattening of all "functions/effects" into raster images (even with the "Flatten unsupported..." checked). The trouble is, that there still are printshops, where all "functions/efects" (like transparencies and so on) are not properly rendered or are just left out (black (white) squares). The only possibility to print properly in these printshops is to hand-over a PDF 1.3 with all effects flattened. Yet, the color profile is best to include so that there are no misunderstandings and all prints as it should. That is IMPOSSIBLE in Affinity apps. The only way to print in these circumstances is wasting time with communicating and explaining how to process the data, which is a tedious process prone to mistakes. My first question is: Why don't we have the possibility of exporting Non-X PDF1.3 files with the possibility of including color profile in Affinity apps? It can't be hard to add for the programmers. It's an issue of point of view/company politics, I think. The argument, that the industry has developed (outdated standards...) and there are almost no printshops who cannot print from PDF 1.4 files does not count, since it is usually the customer who decides where to print and it is my task to deliver correct data. Indesign and Illustrator have always had this option (and still have it) and that makes it much more usable and versatile and No.1 app for me, even though I'd really like to replace them. My second question: Am I the only one who experiences this? I doubt that... And the third and last question: Is there any chance to include this in future updates? It is a small change, but would have great impact. Thanx for creating great apps, please consider making it even better by including this feature.

No no, I was using the propper cog for each field, but it would not allow me to have both set. As a two step action, it makes sense. I can't see the reason why would it have to be two step, but it works this way (as far as I can say after only a few tries) and that is important.

I seeeeee. I was using it wrong, all the time. It's a two step action - first find, then replace (at least for the formatting). Now I get it. It's very different, but can work just fine probably, I just need to think different. Thanks guys.

Hi, I tried to change some text characteristics (color, etc.) globally in the whole document. But Find/Replace completely failed. It would not allow for setting the search and reaplace formatting together. The panel would allow me to set the search formatting and shows it, but if I set the replace formatting the search formatting disappears and so I'm left with either search for format of replace format, but never both. I tried to search and replace when only replace was visible, to see if it isn't only a visual glitch and it isn't. It replaces everything. Publisher 1.10.5, MacOS 10.13.6

Hi Murfee, I agree that everyone is using different workflows. But as you say (and as I wrote) Publisher remembers only one last location on app level. That comes handy if you are using one export location for all of your project files. But what happens if you have to open and export a file from an old project in the middle of working on a new project? You will have to navigate to the export location of your old project, export, and when exporting a file from your new project (the one you were working on before being iterrupted by having to export a new version from previous project) you will have to navigate to the propper folder again. Then, your safe, as long as another interruption comes. And now - what is the difference when this "save destination memory" goes file level? With every file you will have to navigate to your export destination, but only once. Which, as for my experience makes almost no difference in the end. Though, I use different, more organized/structurized workflow, and at this moment I'm pulling the short end of the rope. Another Q is the name of the exported file - that should be remembered (on file level) whatever the workflow. Moving this to settings is probably the most useful solution.

Hi, does it trouble only me or are there people who would like these features too? Export - the app does not remember the name nor the location of an exported file. It only remembers one location on app level and always provides the name of the AFPUB file as the name for the file being exported. This is soooo wrong and places a concentration burden on the operator… leads to many mistakes, missplaced files… It should remember both - name and location on file level! It is not possible to export a PDF1.3 file with color profile included! Why? PDF:X1a is ok, but it cannot include color profile (by definition). Though 1.3 is the only version of PDF that really does not include transparencies and other unprintable functions. The possibility of flattening unsupported properties does not always do a good job - especially with afphoto or afpub files placed.

Hi, I came across this behavior of Publisher. Situation - one AFPUB file with many small page and pictures, some of which are afphoto docs with adjustments layers, masks and so on. If I place pages of this AFPUB files into another AFPUB file and export it, the AFPHOTO files will not export correctly - they will not get flattened (even though Flatten unsuppported properties is checked) and only the base layer without any changes is exported. The only way to properly export such a file is PDF-X1:a, but that cannot include color profile which makes it uneasy/tricky with handing over to a digital printshop and makes it unusable for importing into an AFPUB file - (for me) imported PDFs without color profile stay without profile, no matter what the settings are and the file appears as if it had generic cmyk profile assigned (not working profile). Is this behavior usual or am I doing something wrong?

Hi, let me add a few suggestions/possible bugs to the swatches panel. If and object with global color is copied into another document the global swatch color of the copied object does not appear in the swatches panel. The object has it, as displayed in the color panel. All swatches copied from a diffrerent document do not appear in the swatches panel. They sometimes do appear among the greys, but not always. When I create a new swatch, the possibility to show document swatches appears and works, but the copied swatches don’t appear there either. When deleting a swatch, the app should ask, whether I want to replace it with another swatch - easy and useful. When adding a global color the color bars in the color selector are always set to one default dark color - why not the actual color? In the greys tab, the swatches appear and are named as Grey 10% and so on. But after applying it to an object the grey is mixed from all cmyk colors - that is a mistake. If I create a truly grey (K-only) swatch, it works. Does this work the same for you, or am I doing something wrong?

Absolutely, multi-page spreads are not essential, but they are such a help. Please incorporate them soon.

Yes, plese. Either "Multi Find/Replace" or some kind of scripting support whicht would allow this kind of functionality. It's a HUGE timesaver.

Alfred, I get your point, I was just trying to say that the website is not saying what exactly the "place" a PDF means, which it should as it is something different than what all other software makers mean by this. That's all.

Hi Catshill The pain originates in a presumption that importing or placing a PDF means placing as is (Passthrough PDF), but what Affinity does is parsing a PDF thus making it editable. But you the web does not say a word about it, just place PDF and many others... It is kind of missleading and does not feel like a final version... I have already tried a few PDF rasterizers and feel that it is going to be the best and easiest way even for those who bought affinity after my recommendation.

Hi Fixx, end of 2019 is ok, 2020 is a bit far away and 2021... I do know how to export a PDF to raster image on a Mac. The question is how to do it on Windows - is there something similar to Preview? An app that would do the job acurately and with no additional cost? Thanks P.S. Stil... I'd like to hear an official answer to my questions about the arrival time of the Passthrough PDF functionality...

Hi MEB, thanks for the straight forward answer, even though it is not the kind of answer i' like to hear. What do you mean by take some time? Are you talking about 1.7.x, 1.8, 1.9? How many months away is that? Is there a roadmap that would sum up future plans for each product? I'd say this is a crucial feature for your software to be used in production environments, where accuracy, reliability and speed are a must. Thanks

Hi Callum, The truth is, that I tried all the ticking possibilities on importing the PDF and the outcome was the same. Affinity tries to parse all PDFs no matter what happens to the look of the document - meaning the fonts. So what you suggested just does not work - does not keep the imported PDF intact, as it should be/as was created. Try it yourself and you'll see. I tried on Windows and Mac - same result. And the same happens in all three apps. So with the whole suite of three "professional" apps there is no way of including an advertisement (for example) from your customer unless you own all the fonts used in the PDF or all the type was outlined. That is a serious trouble, if I am not mistaken and doing something wrong. The outcome of such functionality may look like this: see the difference in the type. Now, the question is: Is there a way of avoiding this? Is there a way of rasterizing the PDF, so that it can be imported to Publisher as was, not with altered looks of the missing fonts? If there is one, PLEASE tell me. If not: PLEASE incorporate the possibility of importing PDFs without parsing and substituting fonts AS SOON AS POSSIBLE. The sotware is otherwise still in beta (Publisher) when it is missing such basic feature. At least the Photo app should be able to rasterize ANY correct PDF. That is fundamental too.