4dimage

I have no experience with Discord, but I don't really want to create another account on a third-party platform just to get help from the community in the future! And just seeing the age check on the lock screen makes my toenails curl😞 Too bad. This forum has been a great place for me for years when I had problems with the Affinity programs. Yes, I admit, I also vented a lot of (justified) frustration here, especially with the 2.0 release and its myriad of catastrophic bugs. In response, I participated in the beta program and tried to provide as much constructive feedback as possible to solve the problems. And the beta program has been going reasonably well up until now - right? The crucial point about this forum is that the Serif team was never the first point of contact for problems. But they always kept an eye on the discussions in the background and would chime in at some point, if necessary, to create a ticket for the developers. So it was more of a casual exchange between users and the team, so everyone could contribute to solving the problem. There are also some exceptional ! users here (for example @walt.farrell @Old Bruce , to name just two), who have thousands of posts and have, from the very beginning, essentially acted as a "quick response force" for Serif, providing quick help, especially to new forum users. Do we now have to file an official ticket with Serif Support? Or create a Discord account first to get quick help from other users? Does Serif really seem to be abandoning the community mentality in favor of the corporate mentality?!

This also applies to current customer release 2.6.3 The Transformation Origin tool displays an offset between the internally used position and the crosshair widget. When I drag the widget with the mouse, it follows the mouse position and snaps to nodes and guides, for example. However, when I release the mouse, the widget jumps several pixels to the left. To be able to move the transformation origin again with the mouse, you have to blindly search around the right until you happen to be positioned over the actual coordinates position and the mouse pointer changes its symbol. The internal numerical position appears to be correct after releasing the mouse button. In this example, a rotation around the left anchor point of the curve is to occur. beta-2.6.4.3624-pivot-point-marker-offset_1-1.afdesign 2025-09-15-beta-2.6.4.3624-pivot-point-marker-offset_1-1.mp4

This also applies to the latest beta 2.6.4.3439 I discovered this by chance while working on a real logo. Maybe you can't call it a bug, but in practice it is more than time-consuming. I noticed that in the layouts in which I later used the logo, bitmaps were always visible in Adobe Acrobat Preflight when exporting to PDF/X-3:2003. Even though I had created all the graphics as resolution-independent vector shapes. I tested this in a minimal layout and discovered that when gradients are subsequently skewed (not the ones at 0, 90, 180, or 270 degrees), the gradient surfaces are treated differently internally than when such a skewed gradient is created from scratch. For example, after disproportionately scaling the Gradient tool, an extended widget appears on the object, the functionality of which is more than puzzling. Here's a simple test run: 2025-07-15-distorted-gradients-export-to-pdf-as-bitmaps_001.mp4 Affinity seems to handle these scaled gradients differently during export, so the "Rasterize: Unsupported Properties" option comes into play when exporting to PDF? This is very annoying because, when working with gradients, even the simplest shapes often have to be scaled disproportionately afterwards. Just think of a rectangle with a simple 45° gradient as a page background. Initially, I always laboriously recreated all the gradients with the Gradient tool and then exported PDFs until no bitmap was visible in the PDF preflight. If you use the "Paste Style" function, you only copy the non-standard gradient from the old object to the new one, resulting in only a bitmap in the PDF export. What a waste of time, especially with multi-level gradients 😞 As a dirty fix, I now do the following after scaling shapes with gradient fill: for simple linear gradients, it's enough to briefly switch the gradient type to Circular and then back to Linear. Then the "special gradient" becomes a normal gradient again, which can then be seen in the PDF as a PDF Smooth Shade as expected. See end of the video.

I found this by accident in a real project. The same behaviour applies to the current beta 2.6.2.3228. No matter if OpenCL on/off. 2.6.2. beta simplified testfile: 2025-04-14-beta-2.6.2.3228-bug-livefilter-clarity_1-1.afpub I zoom the workplane in and out with the mouse wheel. As soon as the live filter is applied to the background image, the app shows blurred forground objects (text) when the zoom level exceeds a certain value. 2025-04-14-beta-2.6.2.3228-bug-livefilter-clarity_001.mp4 Furthermore, as soon as the the artifacts appear, the CPU usage gets very heavy, up to 100%. 2025-04-14-beta-2.6.2.3228-bug-livefilter-clarity_002.mp4 When i turn off the live filter again the viewport error disappears. This behaviour is 100% reproduceable. --- EDIT --- My performance settings:

Yes - thank you so much !!!!!!!!!! I am just testing some old documents created with 2.5.7 with beta 2.6.2.3213 and everything looks fine so far 😁 - Old documents do not longer show font errors when opening in the beta 🙂 - When exporting PDF/X-3 from beta and opening for editing in Publisher again, all exported/embedded fonts are recognized on the same Windows system. - Crosscheck - opening PDF/X-3 in actual Illustrator 2025 for editing does not show any font errors. Custom font settings are recognized by Illustrator, layout is stable.

I've managed to switch a document from one document color profile to another without changing the CMYK values. Only the screen display changes. The point is that when switching, the "Assign" option seems to work, at least for this one action. In this example, I'm changing the document color profile from ISO Coated v2 300% to ISOnewspaper26v4. a) First, with the "Convert" option. Then the CMYK color values are shifted. b) Then, with the "Assign" option. The CMYK values are then retained, although the display on the screen still changes. 2025-03-14-affinity-2.5.7-colorprofiles-cmyk-shift-003.mp4 It's not possible to permanently set the "Assign" option in the document properties. So, I think the procedure in the dialog described above was exactly how the developers intended it. Similar to the scaling behavior when the document or layout page size is scaled to a fixed size. Not really satisfactory, since you can't even quickly copy a modified graphic from one document to another via the clipboard. You'd have to first set the source and target documents to the same color profile, and then, after pasting the image into the target document, set it back to the desired color profile. And don't forget to activate the "Assign" option in the dialog every time! There's also the problem that, even with linked vector graphics, the color values in the target document are still shifted according to the active color profile. Why is this so important? 1) As described, I frequently have a situation where a specific ad layout is published with slight adjustments in different newspapers. Each newspaper may require a different color profile in its technical specifications. So, if last-minute additions need to be made during the design process, it's difficult to create them in one layout variant and simply duplicate the new element in all other formats. Quick copy and paste doesn't work between the different color profiles, as described. Therefore, the colors have to be manually reset each time after pasting. 2) For example, I have a grid of products with special prices for sales promotions. It's inevitable that individual prices can change at the last minute. To avoid errors after price changes, there's a designer layout file in which the individual items are graphically managed as square insets on named artboards. I then place the Designer artboards as links in the target document in the respective Publisher ad layouts for the various newspapers. If an article price changes, I make the change once centrally in the Designer file. I then open the affected Publisher layout files and export them again to PDF/X-3 for distribution to the newspapers. e.g. So far, so good. However, since the central Designer file also only has a specific document color profile, the colors of the linked article artboards in layouts with a different color profile are shifted as described. So I usually have to maintain at least two or three Designer article files in order to be able to maintain the appropriate target profile for the most common newspapers. At some point, the advantage of centrally maintaining the price data is lost, because changes have to be made synchronously in two or three Designer documents. Ideally, there would actually be only one central Designer article file, and the respective Publisher ad layouts would link to it without any changes. This exact process is possible in Illustrator and InDesign. Does anyone have any other ideas for a practical solution in Affinity? Aside from some crazy data merge solution

I regularly create newspaper advertisements and printed materials that are produced by online printing services. Each provider has its own technical specifications regarding the document color profile to be used. Typical examples include ISO Coated v2 300% (ECI) for regular printed materials, and ISOnewspaper26v4 or WAN-IFRAnewspaper26v5 for newspapers. I often have to make minor adjustments to a specific ad design for different newspapers. This often results in additional work, as every time I change the document color profile, all color areas (vector graphics and fonts) are unnecessarily converted to the new color profile. Then I have to reassign all the colors manually. What a waste of time. For example, even a simple rectangle of CMYK 0,0,100,0 is shifted to CMYK 2,0,100,0 in the target document. For newspapers in particular, a color profile with a low overall ink coverage (e.g., 240% or 280%) must be selected. However, that doesn't mean every color needs to be converted! That might only happen if the total ink coverage is actually exceeded. But that's certainly not the case with 0, 0, 100, 0. The error occurs when the document color profiles differ between the source and target documents, regardless of the actual need to limit the total ink coverage. Of course, the screen display of the colors changes! But the underlying CMYK color values should remain unchanged. Here are two source graphics, each with its document color profile, and two target documents in which the graphics are placed. test-source-isocoatedv2-300.afpub test-source-isonewspaper26v4.afpub test-target-isocoatedv2-300.afpub test-target-isonewspaper26v4.afpub 1) The unnecessary color shift occurs even when simply copying via the clipboard between documents with different color profiles. Neither the red nor the yellow have an excessive total ink coverage. Nevertheless, both colors are unintentionally changed when pasting. It is possible to manually reset the CMYK color values in the new target document to their original values using the color palette. Therefore, the current document color profile does not necessarily prevent certain color values. 2025-03-14-affinity-2.5.7-colorprofiles-cmyk-shift-001.mp4 2) The same applies when placing. As soon as the color profiles differ between the source and target, the colors are unnecessarily shifted. 2025-03-14-affinity-2.5.7-colorprofiles-cmyk-shift-002.mp4 I specifically conducted a test with Illustrator and InDesign, copying and placing graphics between documents with different document color profiles. In these cases, the pure CMYK color values are retained in the target document, even if the screen display naturally differs. So, it doesn't seem to be a standard procedure to always recalculate colors. 3) In the Publisher document properties, on the "Color" tab, there are the options "Assign" and "Convert." Unfortunately, it's not possible to permanently enable the "Assign" option. Every time the dialog is reopened, the behavior reverts to "Convert." This could be the reason for the color shifts. There must be a mode in which the pure color values of inserted vector graphics remain untouched. Especially if the target profile actually allows the color values to be manually reassigned.

Tested the 1500 dpi document again: test-1500dpi.afpub Here is a a PDFlib log for 2.5.7: 2.5.7_pdflib.log Steps: - Open Publisher document - File -> Export. The previously used PDF settings were still active -> dialog shows some already broken preview. - I guess the application has already crashed at this point. As soon as I try to toggle something in the dialog or cancel and then call up Export again, Publisher crashes completely in 100% of cases. If i directly click "Export" then the file dialog is shown. But then the app creashes after confirming with OK. I don't have any Publisher crash reports for this error. - I also tried the procedures with Performance -> OpenCL deactivated. Same failures. Same error in my last beta: 2.6.0.3134-beta_pdflib.log

There are definitely significant changes in font management starting with 2.6.0! I have done some more tests. As I said, I have used this technology in practically all documents since the introduction of variable fonts last year. In particular, Roboto Flex, as it provides a very flexible width axis (custom value 25 = Condensed). After installing 2.6.0 customer release last week, all my work from the last few months is mixed up when opened in 2.6.0 due to the unnecessary font replacement. The Roboto Flex variable font is definitely still in the system! So I would have to laboriously correct all my work from the last few months, assuming I still have a PDF as a visual template. Fortunately, I had found a nearby Windows restore point, so I could go back to 2.5.7 and have been working with 2.5.7 again since last week. I don't want to think about what would happen if I had to reinstall Affinity because of hardware changes. Then a lot of work would be ruined, because then there would only be 2.6.0 or newer as an installer! Trying to open a 2.5.7 document in 2.6.0 results in unwanted font substitution for occurendes with custom axis settings. e.g.: 2025-02-28-affinity-2.6.0-variable-fonts-bug_002_pub-open-2.5.7-in-2.6.0.mp4 When I tried to save my old work from 2.5.7 as PDF for export or PDF/X-3, in order to possibly transfer it to Adobe Illustrator, I noticed something that really gave me food for thought. Here are two Publisher documents, one created with version 2.5.7, the other with the latest 2.6.0.3134 BETA. I assume that 2.6.0 shares the same errors as 2.6.0.3134 BETA. variable-fonts-bug_1-1_2.5.7.afpub variable-fonts-bug_1-1_2.6.0.3134.afpub And here are the PDF/X-3 exported from Publisher: variable-fonts-bug_1-1_2.5.7_x3.pdf variable-fonts-bug_1-1_2.6.0.3134_x3.pdf - Roboto Flex downloadable from Google: https://fonts.google.com/specimen/Roboto+Flex?query=roboto+flex - Bahnschrift is a Microsoft system font (Windows 11) Starting point When opened for editing in Illustrator 2025, the PDF/X-3 exported from 2.6.0.3134 does NOT generate any errors. All fonts are recognized and all properties (custom weight) are correctly recognized and displayed in the character properties panel. However, if I open the PDF exported from 2.5.7, there is a font error and Illustrator does not recognize that it was a custom setting for Roboto Flex. 2025-02-28-affinity-2.6.0-variable-fonts-bug_001.mp4 If I now perform these tests with Publisher 2.5.7 and try to open the PDF/X-3 for editing, the following behavior occurs. Open PDF in Publisher 2.5.7: 2025-02-28-affinity-2.6.0-variable-fonts-bug_002_pub-2.5.7.mp4 Open PDF in Publisher 2.6.0.3134 BETA: 2025-02-28-affinity-2.6.0-variable-fonts-bug_003_pub-2.6.0.3134-beta.mp4 - The basic error is that in documents prior 2.6.0 all occurrences of variable fonts that have custom axis values set produce unusable font names and are later replaced unintentionally when opended in 2.6.0. Occurrences with the standard values of the axes (font names such as: RobotoThin, RobotoRegular, RobotoBold, ...) remain in the layout. - Font names of the custom axes that cannot be resolved are mostly substituted with the first standard style of a font. e.g. RobotFlexThinItalic. Can anyone reproduce the behavior of the variable fonts under Windows using my Publisher documents or the PDF? On the MAC, there seem to be other font problems from version 2.6.0 onwards? Conclusion I have the strong impression that when support for variable fonts was introduced, the first implementation led to compatibility problems or other hidden difficulties. With version 2.6.0, massive changes were simply made under the hood, without considering backwards compatibility with older documents (2.5.7). Unfortunately, it seems that the management of font names now conforms more to standards and also follows more general conventions when exporting to PDF (embedding font) ??? I fear that, unless this is a bug, Serif will not take a step back. It would have been decent to at least inform users that older documents will be destroyed from 2.6.0 onwards, rather than leaving them to run into the open knife... But strictly speaking, Serif needs to implement an automated routine when opening older files that converts the old font management to the new procedure. Instead of leaving users to waste hours and days recreating and repairing older layouts in the middle of ongoing projects!

Hi, ich nutze noch Affinity 2.5.7. Ich habe diese Ungenauigkeiten schon vor Jahren angemahnt. Selbst Inkscape kriegt das auf den Punkt hin: DIN A4 = 210.00 x 297.00 mm !!! Aber da passiert nix bei Affinity... Ich rege mich nicht mehr darüber auf, da es scheinbar bei den Dienstleistern gewisse Toleranzen bei den Datenformaten gibt, die noch akzeptiert werden. Deshalb ist es komisch, dass deine Druckdaten abgelehnt werden?! Ich lasse auch regelmäßig bei www.wir-machen-druck.de, flyeralarm.com und anderen Onlinedruckereien produzieren. Und zwar alles von Vistenkarten bis hin zu großen Schildern und Bannern in der Außenwerbung. Die von Affinity Publisher exportierten PDF/X-3:2003 gingen bis jetzt, trotz Nachkommastellen, immer problemlos bei der Bestellung/Datenupload durch die automatische Druckdatenprüfung. Beispiele die bei Wir Machen Druck akzeptiert wurden (Acrobat Pro Seitenbereich Dialog): Ähnlich ist es bei flyeralarm.com. Auch hier gab es trotz Nachkommastellen noch keine Ablehnung bei der automatischen Druckprüfung. Beispiel: Wie wäre es mit einer telefonischen Nachfrage beim Wir Machen Druck Kundenservice? --- Das hier bekomme ich heraus, wenn ich deine Testdatei exportiere und im Acrobat die Seitenrahmen prüfe:

@Hangman No, does not export. I had already tried out the test file test-1500dpi.afpub. As soon as I try to switch something in the PDF settings in the export dialog, Publisher crashes completely. I also have the impression that the crash is initiated at the latest when the dialog tries to render the preview image on the left. The dialog becomes totally unstable in this configuration and the entire application then crashes completely at the slightest attempt to enter anything. I had also already tried setting the document resolution in the document properties to 1024 dpi. But that also crashed later when exporting the PDF. In the end, I reduced the document resolution in the document properties to 300 dpi. This also matches the standard PDF/X-3:2003 preset in the export dialog. Then it works. It doesn't help that I don't get any crash reports either.

OK, strange. On my system the error still exists. I managed to export the Design by lowering the document resolution to 300 dpi. In this actual case i had only vector shapes. --- For old and future designs containing bitmaps i might have another dirty workaround. In this older example, the banner is 3.5 x 2.2 meters. 1) For the final artwork, I merged all bitmap design components into one bitmap with 1500 dpi and exported it as a JPG with the correct color profile, resolution and CMYK color mode and highest JPG quality. This basically means I'm anticipating the transparency reduction of PDF/X-3. In this case, the result was a CMYK JPG of around 100 MB. Considering the design document size, this is a relatively moderate file size. 2) For a second extra artwork file, I import the fully optimized JPG as a layer into the Publisher layout. 3) All pure vector elements go on a layer above. The crucial part is that I created a custom PDF/X-3 export preset beforehand in which any resampling of the bitmaps is switched off! When I then export to PDF/X-3 including the bleed area, no resampling and/or conversion to the target color space needs to be carried out for the already optimized bitmap. In Acrobat, at the end I can see during preflight that the only large bitmap was actually embedded in the PDF/X-3 unchanged. It's stupid that I can export a standard-compliant PDF/X-3:2003 this way. But after writing the PDF file, Publisher always crashes completely. At least it doesn't destroy the PDF that it just saved with so much effort. A lot of extra work for something that shouldn't take more than 2-3 minutes in everyday business 😕

@NathanC Thanks! I guess this error is related:

I have the same concerns. For the time being, I'll continue to work with 2.5.7 😞 I installed the applications via msie.exe. You have to explicitly download the updates and it's not so easy to click on automatic update in the welcome screen. In the past, there were some major bugs that were later fixed (the first v2 version was a disaster). What should we do? For me, there's no going back to Adobe CC on principle. And Affinity is the only professional alternative on Windows. 😶

Thanks for double checking ! Yes, that's correct In document scale 1:10 that will be the required bleed of 1 cm in the final 1:1 printout. 1 cm bleed that is requested by the printing service. I know this huge banner 12 x 1,5 Meters is a little bit unusual. But Flyeralarm Large Format printing can in fact print this as mesh banner in one piece on request 😁 https://www.flyeralarm-lfp.com/