Daniel Gibert

When adding a hyperlink to a text in publisher, it automatically uses the selected text as the source for the url so you don't need to paste it on the url field. But if you add a hyperlink to a url that has already been used in the document, now it adds an space and a sequential number to the url. If you don't notice it and save the url, it does not work because the url has now %20 and the number added to it, resulting in a 404 error on the webpage (page not found). Publisher should add that numeral in the Hyperlink palette list, as a way to identify it, but never on the url field. Or be smart enough to detect that a url already exist and it is just being used twice. Now we need to manually paste the url in each link so ensure that the correct url is used. HOW TO REPRODUCE IT In a document, select a URL (sampleurl.com) and then select "Add hyperlink" on the contextual menu. Dialog opens and the selected url is already added to the url field (sampleurl.com). Just close the dialog. In the same document, select another instance of the same url (sampleurl.com) and repeat the process. This time the url field is autofilled adding a sequential number to it (sampleurl.com 2) When exporting or visiting the destination, the url becomes sampleurl.com%202, failing to load the page because of incorrect url. HOW TO PROVISIONALLY PREVENT IT Just copy the url before adding the hyperlink, and delete the autofill url and paste the copied one. HOW SHOULD IT WORK It should use always the selected url without adding or changing a single character. --- Publisher 2.6.3 MacOS 15.5 (System in Spanish) Processor M2, 24 gb RAM

Hi, we had the same issue after updating to 2.6.0 and now we have figured it out. The problem is that the anchor to spine option has been automatically activated in all documents made before the updating, without any notification. So we just had a serious issue with a customer because a project we have been working in the last months has numerous images moved because a behaviour that never existed before. By the time the customer and us noticed it and discovered what was happening, it was so late in the project that we had to manually recompose numerous pages and do a profound review of a project with more than 3000 images to be sure (lost time, lost money, and worst, lost customer trust). This new function is cool, and we like it for when we really need it, but please, for next update, make it so it does not activate on existing documents. Don't force a delicate layout changing option on documents that don't had it before. Now we have to remember to check it on all the projects made from the former version to avoid risk of damaging the layout. Just another nuisance to have in mind. Or quoting Pink Floyd "just another brik on the wall" This should be an option only active if the user want it, not an option by default.

This is absurd. The goal of cropping is to remove non necessary areas of the image to work with the remaining. What use is there if the cropped images selection area is the original image's one? What's the use of cropping if I can't set measures to the cropped image because the measures applies to the original image? And yes, i can convert it to image frame, but that result in a image frame containing the cropped image with the same issues, and being even harder to manage size. It is an useless nuisance, and just now I have a catalog with already thousands of cropped images that I cant resize properly because the cropping does not work. I can't conceive a single other software with image cropping that make this, and I've used a lot of them. You know it is wrong when even the f$%&nkg Word and Powerpoint does it right and your app NOT.

Hi there. Not completely a bug, but a export option confusing subject. I'm testing with 8bit grayscale document in Publisher. If I add a colour image, it appears correctly on grayscale on the document. Now, if I export the document as PDF (Using Export for print) with colour as "Same as document" or manually forcing to "Grayscale" the resulting PDF has the image in colour, as the "convert image colour spaces" is not active by default. Steps to reproduce: New document: colour as 8bit grayscale, profile as Grayscale D50 Add a colour image to the document (Is shows in correct grayscale once placed). In this case I used an RGB image in JPEG. Export to PDF: PDF (for print) - Colour space: as document - Profile: use document profile. (Or manually set as grayscale) The question is… shouldn't be the "convert image colour spaces" active by default when the pdf colour space does not match the document one? It took a lot of testing from us until we realised where the issue was. If I choose a different space colour for the pdf I suppose that that implies that I want the images on the same colour space, as they appear in the document. Not sure if this is a bug or a feature request/suggestion. By now I will create my own grayscale PDF preset with the option active.

Whit the expected differences of being a different app, yes. It is a panel where you manage the different chapter documents, sync information and page numbering and export all documents as a whole. We used it constantly for easy management for complex catalogs made of multiple Publisher documents. The panel config is saved onto a book file, just like indesign. If you need more information https://affinity.help/publisher2/en-US.lproj/index.html?page=pages/Advanced/creatingBooks.html&title=Creating books has all the help about books.

Just tested it on some actual work photos and whoa! this could save us tons of work. And I love the approach by local computing and local trained model. That is the way to do it.

Well. Testing on the last beta and can affirm that the issue is solved, ate least on Mac. Exported a 360 pagers book, 19 chapters, 17 of them with TOC, flawlessly, and even faster than before. Now waiting for the next release to update all studio computers. Thanks a lot, team!

I agree. Anyway, I tried opening it on Pixelmator and it opens correctly there. An Pixelmator HEIC exports opens in Photo. So something happens with HEICs on Sequoia that affects to Affinity but no others… Not saying it is Affinity's fault, just that it happens. Probably Pixelmator use some system services/APIs to open it the same way Preview does. Don't know, not my expertise field.

Yup, this is all very weird. I can open all four of your exports, but can't open any of my own exports. Tried in 8 and 10 bits, with and without compression, but nothing opens in Photo. There must be a subtle difference between my computer and your's that makes the exports readable by Photo.In fact, none of my Macs allows me to export it and open in Photo. We'll wait for a solution.

I tried and I can open this two HEIC without issues in APhoto. But i'm not able to open my own HEIC files Neither directly from the iphone nor the Preview exported ones, on 8 and 16 bits format. I'm attaching one of my original heic to offer more options to investigate. In this case photo is from an iPhone 15 pro max, in HEIF Max, with iOs 18.0.1 and Sequoia 15.0.1 on the mac. Also attaching the Preview exported one. Both fail to open in Photo. IMG_E8889.HEIC IMG_E8889-export 10bits.heic

In fact I'm using less steps. Just opening each chapter separately and exporting it and joint them. (The TOCs are for each separate chapter, no global TOC fortunately) The thing that irritates me is that is a new bug on 2.5 that never happened before. I've always exported flawlessly. Something has gone very wrong to broke a well stablished function. As it is now, i'm just using books to sync page numbering.

I confirm that i'm getting this issue on MacOs. Exporting a book results in a PDF with only the chapters that don't have a TOC and all the chapters with TOC got locked. Can't open them again because the OS says they are in use in another app. Once you quit Publisher they get unlocked. It is a perfect bug for a perfect moment with a perfect big project just on the edge of delivery. Arrrrgh! By now i'm solving it by exporting one by one and joining on Acrobat, but that is a time wasting solution. Mac OS 15.0 over m2 processor and 24gb RAM Affinity Publisher 2.5.5

Please, do not apologize. It is me the one who should offer apologies, since I promised to test further and come with better step by step ways to reproduce and failed miserably due to workload. Nice to know about this option and will check that deactivating Allow Advanced Features solve this for the works we have already on production. As always, cheers and kudos for the team, and to you. I appreciate your work a lot.

Oh, it is very weird. The white area may be because the piece is not just transparent, but in multiply mode, so it need to render as a bitmap image. This is normal on PDF. I am suspecting more and more that it is an error caused by the colour formulation of the piece and the custom library colour used, because if you change it by a bit, the issue disappear. I'll post my experiments on this by tomorrow. Thanks for looking at it!

Hi, Dan C True, my mistake. The file I sent is in RGB (The document where it happens originally was in CMYK). After reading your comment and testing. I see that the issue happens on any document regardless of the colour space, so I must retire my assumption that it was about colour space. I've been testing more deeply based on your clues. It seems that is a rare case. If I get the FX object and change it using the RGB colour panel, it ceases to fail. And if I change it using the CMYK again, the fail does not return (It is as if there was a colour formulation error) We assign that colour from a custom colour library, and the error has happened always with that same colour, so maybe there is an issue on the library. Please, let me do some further test and I'll try to catch the steps on video. I know the issue is there because it appeared to us on different documents, but now I'm not sure about the steps to reproduce. I'll remade the illustrations again as I made it at first to force the issue and let you know. I hope to have it by tomorrow. If I find a solution or a cause I'll let you know so it can be useful for others having this issue. Thanks a lot for your patience.

This is one error on V2.5.3 that has resurfaced as it happened before a long time ago, on V1 If you export a CMYK document onto a RGB PDF, effects on objects that are clipped inside other objects are not rendered and appear as white areas. This didn't happen on 2.5.1 and earlier. The same effect outside the clipping object does not happens and render correctly. If you export to a PDF in the same colour space the result is correct. I have memories of this error happening a long time ago in V1 and being solved then, so I think it is a regression. Attached to this comment there are the Publisher document used to test this and the incorrectly exported PDF. Tested using the default PDF settings and custom one. It is always when the colour space differs from document to pdf. The issue.afpub export.pdf

It seems that SF Pro continues to give headaches. Publisher 2.5.3 won't export a document if it contains SF Pro font. It won't even preview the page in the export dialog too. And if you cancel the export the app gets non responsive and won't let you work with any object, undo or so, needing to force quit. Steps to reproduce: 1 - New document 2 - New paragraph, select SF Pro font and type any character 3 - Export as PDF (Any setting) 4 - Preview is not generating on the export dialog and if you export it it never generates the pdf and it gets stuck in limbo. Can anyone replicate this and confirm if it is me or the app? If it is the app, anyone have a quick solution that can save the next days of work ahead? Publisher 2.5.3 - MacOS 14.5 - Mac with M2 and 24 gb RAM ------- EDIT: It seems that if you leave it and don't touch anything, after loooooong minutes, it eventually export it, so there is something on exporting SF Pro that creates an export bottleneck, even if the document is just a single letter in SF Pro. Hence it looks as if the app has crashed.

Well. 2.5.3 is out and the issue has been solved (On Mac at least) so now I can upgrade the suite in all computers. Thanks and kudos to the team.

To the app marking it as missing with ?SF Pro. We just select the font or re-select the style and it shows correctly, with the correct font style applied. No ? involved. That happened to us a year ago, but since then we cleaned and reinstalled all SF Pro instances in all computers to be sure we are on the latest one.

Curious. This does not happens to us. But maybe it is because I have installed the most recent update for SF Pro (I download it from Apple Developer Fon page twice a year as they improve and enlarge the included characters very often) You can download the current version from here: https://developer.apple.com/fonts/ That installs the whole SF set, independently of what OS version you have.

Thanks, Mike. Good to know. At this moment we have downgraded to 2.4.2 again, as this issue (and another logged for page numbering) affects a lot of our documents and can't risk to send projects to printing. There is big money on risk. Also, not all cases are made using styles, specially on Designer graphics, so manually solving it could be a nightmare in our case. Waiting patiently for 2.5.1

It shows as variable, anyway, 2.4.2 uses it with no issues as if it is fixed, and 2.5.0 use offer the variable options as being variable. Been using it since ever with no issues until the 2.5 update. As it is installed by Apple's official installer I'm not sure if there is the option to use fixed only. It just installs and come installed with the system as it is. I checked installing the last font release from official source, just in case.

Thanks both, for reporting and for acknowledging the bug. Downgrading now to 2.4.2 because we are just finishing a multi-document 450 pages book and this could be disastrous, having to go printing in the next days. We will have 2.5 on a test computer to check for future resolution but this and another bug in the last version puts our work in risk. Waiting for 2.5.1

After 2.5.0 update, any document we open on Publisher that uses SF Pro doesn't display characters of that font. The font is loaded, and you can use it on new paragraphs with no issue. The invisible characters are there, they just don't render on page. In order for them to re-appear, we need to do a format Search and replace for the font (Search font SF Pro and replace with font SF Pro) in the entire document and then it reappears. Or, if you are using styles, you must edit the style and re-select SF Pro again, or manually select the character and re-apply the font. So far we have detected this only with SF Pro, but now we are nervous that it could happen with other fonts unknown to us. Checked in two different Macs with multiple documents. It fails on any mac with the apps updated to 2.5.0 Also, the issue is only a visualization problem on 2.5.0. We can open a 2.5.0 saved document back onto 2.4.2 and the font shows up well there. Just won't show (and won't export) on 2.5.0 Steps to reproduce: 1 - In Publisher 2.4.2 or earlier make a document and use some SF Pro symbols on the text. Save 2 - Open the document in Publisher 2.5.0 SF Pro characters are not visible. 3 - Do a Search and Replace format, searching for SF Pro and replacing with SF Pro, or reselect SF Pro in font/character style 4 - Now SF Pro is visible again. Attached you can find a document made on 2.4.2 that uses SF Pro for testing, from a real project from us. Temporary we are putting the updating on hold, to prevent the problem from spreading. EDIT: We can confirm it happens on the three suite apps. That force designer and photo documents to be opened on Publisher for solving it, as Search and Replace is only available there. Mac OS Sonoma 14.5 Tested on Macbook Air M1 and Mac Mini m2 Designer 2.5.0 Using SF Pro font (System included font and updated to last official version from Apple) test.afpub

I want to believe you. But also I want you to know that at this instant moment, you are haemorrhaging your trust and credibility at the creative community on Mastodon. I can see nothing but despair and deception on my timeline.