4dimage

Variable fonts are a useful addition also with regard to use in web designs. But there is something strange i found when using the "new" Roboto Condensed from fonts.google.com. I guess this is not a bug, it also appears in the current v2.4.2. https://fonts.google.com/specimen/Roboto+Condensed For compatibility reasons with current web projects i installed the 18 "static" font styles, not the single variable font itself (RobotoCondensed-VariableFont_wght.ttf). Here is the test file: 2024-04-19-variable-fonts-roboto-artefacts_1-1.afpub As soon as a drop shadow or other effects are applied to the text frame, visible artifacts occur depending on the letter. This doesn't seem to be an affinity bug, but rather due to the way certain letters in variable fonts are constructed. Instead of the usual compound paths, the letters consist of individual shapes that only visually merge into an overall shape through overlapping. Your can see this in the wireframe view even without converting the text frame to pathes. The problem now seems to be that for certain letters, especially the bottom and top edges, the effects are applied to the internal individual shapes instead of to the entire letter (composite shape). Depending on the font size, this results in “bumpy” outlines. This doesn't just seem to be a display problem in the editor only. Some of the artifacts are retained even when exporting for the web (PNG, JPEG). Did the developers also experience such artifacts during the integration of the real variable fonts? Or is this a special case that occurs when a variable font is broken down into individual font styles ("static") for compatibility reasons. Like Google did with the Roboto Condensed variable font.

@anto I guess this is not a bug. The difference is, that you use the additional alignment functions and options from the dropdown. These do exactly what the option "Align to" ("Ausrichten an") say. There is no explicit option "Align to anchor object". Therefore i customized my symbols with all alignment functions directly availlable. If you then choose an anchor (key) object (ALT + click on Windows), the alignment works like expected: 2024-03-28_publisher-alignment-with-anchor_001.mp4 Customize Symbols and Toolbar via view menu:

When exporting to WebP, the preview left hand does not show the exact colors. This is format specific. E.g. exporting to JPEG, PNG or TIFF shows the preview exactly like the original. On the other hand WebP, PSD or EPS show somewhat offset colors. In this example (8bit, sRGB) you can see this in the sky blue tones in the upper left area. WebP offset blue: JPEG ok: In the final WebP file that is saved, the colors are like in the original. But the preview is not only "for fun". When exporting for web i heavily rely on the preview, balancing image qualitiy vs. file size. The preview should show the exact output with the right target color profile applied.

Maybe this is just a Problem with my old (outdated) Adobe CS6, Acrobat X Pro Software ? 2024-01-30_afpub_pdf-x3-export-bug_1-1_fail.pdf I tested the failing PDF with an actual version of Qoppa PDF Studio 2023. https://www.qoppa.com/pdfstudio/ There the PDF which fails in my old Acrobat X passes the preflight test. Can anyone confirm this with an actual Version of Acrobat Pro CC (2023 or 2024) ? Does an actual Acrobat Pro CC preflight test the above PDF successfully?

@Andreas CH Super - das ist erst mal eine ordentliche Zwischenlösung für bereits in v2 erstellte Layouts 🙂 Allerdings war auch in v1 und in der aktuellen customer v2 diese Option nie als Teil des PDF/X-3:2003 Presets aktiviert. So sieht das auch in v1.10... schon aus. Es hat also früher schon jahrelang ohne das Umwandeln der Bilder reibungslos funktioniert. Hab mit v1 Dutzende PDF mit flyeralarm unter exakt den Vorgaben ausgetauscht und nie Probleme gehabt. Bis zu Version 2, wo wieder mal Fehler eingeschleppt wurden... Ich glaube die Umwandlung zum Zielfarbraum schon beim Export ist nicht optimal. Zum einen wird gleich mal die Dateigröße der PDF mehr als verdoppelt (RGB zu CMYK), was ja auch übertragen werden muss! Zudem bin ich mit dem RGB-Workflow jahrelang bestens gefahren - es heißt ja nicht umsonst "OutputIntent". Der Druckdienstleister sollte final die Möglichkeit haben, auf Basis der Original RGB-Daten ggf. die Umwandlung zu CMYK auf seine Pipeline hin zu optimieren. Wenn ich die Bitmaps aber bereits nach 300% Deckkraft geplättet habe, gibts da wohl auch final nicht mehr viel zu retten? Zugegebenermaßen dient das exportierte PDF ja dann sowieso nur noch dem Druck bei z.B. flyeralarm. Wie ist eure Erfahrung mit dem RGB-Workflow ?

I did some tests with the actual beta 2.4.0.2256. The weird color profile name bug (ÿISO coated v2 300% (ECI)) seems to be gone. But the final PDF/X-3:2003 incompatibility problem still exists. I tried this basic document setup with a lowres sample image, which is placed in a picture frame: 2024-01-30_afpub_pdf-x3-export-bug_1-1.zip These are the exported PDFs: 2024-01-30_afpub_pdf-x3-export-bug_1-1_ok.pdf 2024-01-30_afpub_pdf-x3-export-bug_1-1_fail.pdf 1) In the first scenario the image fills the picture frame WITHOUT beeing croped. When i export this document with the PDF/X-3:2003 preset everything is ok and the PDF passes the Acrobat preflight check as expected. 2) Exact same document and image -> but in the second scenario i just set the picture frame fill mode to "cover" so that the image is partially croped. When i export this PDF with the same preset, the Acrobat preflight fails: The same error appears as soon as the picture frame is much bigger so that it exceeds the document boundaries and has to be croped during export. My Conclusion: It seems that the error appears as soon as the image has to be croped and resampled during PDF export ? If i just rasterize the layer with the croped picture frame (croped and resampled to document 300dpi) so that the bitmap has NOT to be resampled during PDF export, the result passes the Acrobat preflight. So there might be an issue with pdflib and/or the way the color profile informations are applied to resampled bitmaps during export ?

Bereits mit v2.x erstelltes Dokument mit v1 standardkonform nach PDF/X-3:2003 exportieren Das ist eine Knuschellösung für alle, die glücklicherweise noch die letzte stabile Version v1.10.6.1665 installiert haben. Und weil das scheinbar eh vor allen Dingen die deutsche Version betrifft, spare ich mir hier den üblichen Übersetzungsmarathon. Ich hatte leider das Layout in v2.3.1 bereits erstellt. Für den Druckservice ist eine Beschnittzugabe von umlaufend 5mm vorgegeben - und wie fast überall das Farbprofil "ISO Coated v2 300% (ECI)". Wie bekomme ich nun die korrekten Druckdaten, ohne alles in Publisher v1 neu aufbauen zu müssen ? Kann sein, dass nachfolgend die ein oder andere Option nicht zwingend erforderlich wäre - aber so hat es bei mir am Ende funktioniert. 1) Ich exportiere das Dokument aus v2 komplett oder seitenweise NICHT direkt nach PDF/X-3 sondern mit der Vorgabe "PDF (für Export)". Ziel ist es so viele Eigenschaften der Grafikobjekte wie möglich ins PDF herüber zu retten. So sollen z.B. die eingebundenen Bitmaps nicht heruntergerechnet werden, die Texte als Fonts erhalten bleiben und ich will auch die Beschnittzugabe mit exportieren. Hierzu ändere ich einige Optionen gegenüber der Vorgabe. Vor allen Dingen bette ich sicherheitshalber das ICC-Farbprofil NICHT ein! 2) Ich öffne die alte letzte stabile Publisherversion 1.10.6.1665 und erstelle dort ein neues Dokument mit den identischen Einstellungen, wie das v2.x Dokument. Das bezieht sich auf Größe, Auflösung, Farbmodell, Farbprofil, Anschnitt etc. 3) Ich platziere das aus v2 exportierte PDF in Originalgröße auf meiner Layoutseite. Hierzu erstelle ich einen Bilderrahmen, der sich bis über den Anschnittbereich ersteckt. Hierbei ist zu beachten, dass die Seitenbox-Voreinstellung für platzierte PDF zunächst "BeschnittBox" ist. Das würde zu einem verzerrten Einpassen des PDF in den Bilderrahmen führen. Stattdessen sollte die Seitenbox auf "MedienBox" stehen und der Vollständigkeit halber der PDF-Transfer auf "Interpretieren". Letzteres zeigt dann auch bei nahem Heranzoomen, dass die Texte korrekt exportiert und nicht gerastert wurden. Die Einpassen-Eigenschaften des Bilderrahmens sollten auf "Minimal passend skalieren" stehen. Stimmt alles, so zeigt das Transformieren-Panel beim Selektieren des Bitmap-Inhaltes exakt die Größe des Bildes an, die inklusive Anschnitt erwartet wird. 4) Aus diesem v1 Dokument exportiere ich jetzt mit der Vorgabe "PDF/X-3:2003". Die Option "Inklusive Anschnittbereiche" muss aktiv sein, damit die Beschittzugabe Teil des PDF wird und alle Rahmen korrekt geschrieben werden. Heraus kommt ein standardkonformes PDF/X-3:2003, das in Acrobat den Preflight Check fehlerfrei besteht. Danke Serif, dass ich diese Aufgabe, die normalerweise 1/2 Minute dauern würde, in einer Stunde erledigen durfte. What an amazing tool...

Damned, i ran into this crap one more time. Stil trusting in Publisher v2 (2.3.1), i did some signage layouts. How could I have been so stupid? Of course, when exporting it to PDF/X-3 for an online print service i got the same color profile errors. The preflight check in Acrobat fails. This error also appears when exporting from beta v2.4.0.2240. Unfortunately there is no backward compatibility with Publisher v1.10.6.1665 😒 But i don't want to recreate the whole layout in v1.10.x again... 😶 Hi guys - the first post in this thread is of Novemer 2023. Meanwhile any plans to fix this heavy bug ?! Or should I give up my job as a graphic designer and work as a delivery boy instead? All I need is two healthy feet, which thank God I still have. Nothing against delivery workers - they do an honest, hard job! By the way: this error appears even with a fresh EMPTY document. Of course this passes the preflight check because there is no offending content in it. test1.afpubtest1.pdf

I just found the same bug with iso-coated-v2-300 when exporting for an online print service. - Publisher (all) v.2.3.0, German version, Windows 10 This is how it looks like in v2.3.0 and preflight test with Acrobat X Pro (Same profile name error in actual Acrobat Reader): BUT: the preflight fails not only with iso coated v2 300% (ECI) profile but e.g. also with coated fogra39: ----------------------------------- To verify that this is not a Windows color profile error on my computer, i set up the same document layout in Publisher 1.10.6.1665: This shows the correct color profile name in ACrobat X Pro and passed the preflight like a charm: So again - after more than one year of v2 i have to switch back to v1 to get my daily job done. This should be a simple PDF export but now again i spent over 1.5 hours to check the bug and document it. This is so annoying 😔

Hi, as reported here: As feared, some bugs that where already logged in the Windows version in the beta were not fixed in the "stable" release v2.2.0. When I see the advertisement for the new release on the Serif website, the MAC dialog seems to be shown there. This also looks like it's working properly. Can any MAC user confirm this ? I increasingly have the feeling that some UX errors and weaknesses will be fixed for the MAC/iPad version with high priority and then in the end there will be no time left to implement them identically in the Windows version ?! And this is how the bugs in the current v2.2.0 Windows release still look like: Flipping form groups, missing/different translation, wrong button labels ?!?! 2023-09-19_publisher-windows-custom-fields-bugs-not-fixed.mp4 Not funny...

Now there are two form groups. One with "Custom", one with "Selbst definiert". The latter appears after creating the first custom field: Furthermore the two groups flip panel position after deleting at least one custom fields: 2023-09-04_2.2.0.1986-beta_fields-panel-double-group.mp4 After deleting all custom fields the "german" group disappears and now the tooltip for the plus-button has a wrong label:

Hi Gabe, Don't know, where to post these old Bugs. I'm "sorry" if I "annoy" anyone. I spent hours and days of testing and bug reporting during the last 12 Month since release v2. For good reason. In plain language: Either, I'm just moaning around. Or I try to help make the software better. I decided to do the latter after the first big disappointment with v2. We, who have to work with the software every day, have little choice but to help find the bugs and describe them in a way that is as reproducible as possible. All in the hope that they will be fixed as soon as possible. Until then we have to work for hours every day with the workarounds! So, in exchange for my time and the time and effort of many other beta testers and dedicated users, I think it's appropriate to also point out some old bugs that I think are absolutely important to fix, but don't seem worth the trouble are to be fixed with priority ? Instead, new features are still being added instead of making version 2.x completely stable at least once. I'm talking about the basic functions here. And slices are an absolutely important and fundamental functionality for my work. Feel free to move this post to wherever you want the seemingly irrelevant trash to go...

Hi guys, as already mentioned the slices panel presets are still not working. Switching preset produces random form output. The upper preset select and the other form controls have to be properly synchronized. This applies to both the standard tab and the selection tab. Some of the old presets (v1.x) behave as expected. The newer ones (webp, jpeg xl) and others behave randomly. I have to use the slices in every web project. For web development this is not a nice to have. It's a fundamental functionality like exporting PDF-X for print. Not seeing a clear slice status is very annoying and completely unproductive. You can't select a clearly defined standard preset for new slices and have to fiddle around each time you create a new slice. In addition, if you don't see the preset name in the upper select it is not possible to delete a custom preset without a doubt. And - this all worked fine in v1 🙄 The standard tab: 2023-08-16_2.2.0.1954-beta_slices-panel-mess_001.mp4 The selection tab: 2023-08-16_2.2.0.1954-beta_slices-panel-mess_002.mp4 By the way. For me the slices export to SVG, WebP,... is the number one reason why the Affinity apps provide an almost perfect toolset for web development. Layout pixel perfect in Publisher | Designer | Photo -> open in Designer -> create slices from any piece of your artwork -> export web ready graphics as bitmap and/or vector in multiple resolutions and sizes 👍

1) Thanks😁 The refined Windows panel appearence looks so much clearer now 👍 The Windows issue with the truncated labels still exists. The panel persists the column width of the left label-column at least during one user session. But after app restart the column width is reset to default and the labels are truncated again. In consequence the user has to resize the column once for every user session to read the truncated parameter names. Would be helpfull, if the last user defined column width could also be persisted like the panel size. 2) I can't rename a custom field - maybe this is intended behaviour ? Steps: a) I add a custom field to the palette with some inital value (German translation missing). OK so far. b) Now i edit the field by clicking the button "Edit Custom Field" (German translation missing). The flyout dialog shows the text input with the current field name selected. It appears as if i could change the name. But as soon as i press any letter key the flyout dialog closes without letting me type into the input. If the field name may not be changed afterwards, the input might be disabled to indicate that the name is immutable ?

Sean, you are right! A quick zoom change updates the viewport and all text frames are rerendered correctly. So, the devs can easily fix this 😁 2023-07-18-publisher-windows-fields-update-002.mp4

It's a little bit confusing. The update error seems to occur as soon as i select the second (bottom) text frame. Either select the second text frame Object as a whole or setting the text cursor inside the frame. 2023-07-18-publisher-windows-fileds-update-001.mp4 The internal IDs in the layer preview look the same ?

I can't reproduce this focus problem on Windows. It seems that the input focus remains in the text frame after inserting a custom field by doubleclicking in the fields panel (as intended). Sorry for having no visual mouse-action marker in the video. I don't click into the text frame inbetween. The cursor stays active in the text so i can type the next letter directly after inserting the field by doubleclicking in the panel. This also applies when the panel is docked in the UI. But another bug: at the end, after changing the field value in the panel, only the second text frame is updated. 2023-07-18-publisher-windows-fields-focus-001.mp4

Yes it does. Here is the complete show: 2023-07-15-publisher-fields-panel-custom-field-bug-002.mp4

Windows panel bug: value input remains in the panel after deleting custom field entry from the list. Even after closing the panel or document. Need to restart Publisher to get rid of the stray value. 2023-07-15-publisher-fields-panel-custom-field-bug-001.mp4

There is a significant visual difference between the MAC version of the panel shown above and the current Windows version. The MAC panel looks much tidier and the buttons are more clearly recognizable as such. On MAC (from Ash): This is how it looks like in the current Windows version: 1) The add-button is missing the plus-sign 2) To my mind, in comparison to Ash's MAC screenshot, overall the data sections and buttons on the right lack contrast against the background. Buttons are too small and the button labes (vertical dots) are to thin. The UI lacks visual guidance. 3) And of course the truncated label problem in the Windows version as reported here: These are my current UI settings:

beta 2.2.0.1903, Windows. Still random for some file types. Even for custom presets. One consequence of this is that you cannot delete a preset without a doubt, since you do not know which preset is currently active. 2023-07-14-designer-slice-presets-ad-2.2.0.1930-beta-001.mp4 This is how it should (used to) work correctly: see in stable Designer 1.10.6.1665... 2023-07-14-designer-slice-presets-ad-1.10.6.1655-002.mp4

This also applies to customer 2.1.1. 1) When opening the fields panel for the first time, the longer property names (nested level 1) are cut off on the left side because the left column is to narrow. 2) I can drag the split point to the right to reveal the hidden words. 3) After closing and restarting Publisher the old/initial panel split is used again and the property names are cut off again. This is annoying because you have to fix the panel layout each time before you can work with it. Automatic panel layout depending on the word lengths of the localized property names might be difficult. But the panel should at least persist and restore the last split position manually set by the user. E.g. the last position, width/height of the fields panel are already persisted.

Also applies to current release 2.1.0 The button still has has the english label.

@blackstone Könntest Du vielleicht ein vereinfachtes Publisher Dokument mit nur der einen entsprechenden Seite hier im Forum zum Testen bereitstellen. Tritt darin dann der Fehler immer noch auf?

I found this strange behaviour. EDIT: this also applies to Beta 2.1.1.1847 I want to change the layer order in the layers panel. The three other picture frames (sibblings) get deleted randomly during dragdrop as well as after droping the draged layer at the new position in the stack. All bitmaps are linked. 2023-06-14_bug_publisher-2.1.0_picture-frame-dragdrop_001.mp4 The only way to get the the layer to the target position without errors is by using the menu ordering commands (or keyboard shortcuts): It seems that, allthough the insertion position is marked BETWEEN the other picture frames, the draged picture frame is droped INTO the hovered/targeted picture frame and replaces its contents. Additionally the draged picture frame looses its content randomly. Here is a simplified test file with embeded bitmaps: 2023-06-14_bug_publisher-2.1.0_dragdrop-pictureframe-deletes-other-layers.afpub 2023-06-14_bug_publisher-2.1.0_picture-frame-dragdrop_002.mp4