thomaso

Not sure what "screen" you refer to. – I noticed a similar issue before: When I choose "Show Presets…" and then select my custom "n-up spreads +…" preset it does not list the according details on the right side of this sub-dialog (but does if I leave this), whereas after having my custom n-up preset selected than the "Current" list entry does show the according n-up settings: I assume this is rather a macOS or printer driver issue than Affinity. If I check these presets in the TextEdit.app they appear different than in the Preview.app while both seem to be confused, which may be caused/influenced by the fact that both these Apple apps don't offer n-up options in their print dialog.

Nochmal: verwenden die beiden Dokument dasselbe Farb-Profil? Je nach Profil kann jede der zwei Angaben "richtig" sein. Zeigt nur die Pipette unterschiedliche Farbwerte oder bekommst du auch unterschiedliche Definitionen in der Farben-Palette angezeigt wenn du ein Farbfeld in der Palette auswählst das in beiden Dokumenten angelegt wurde aber im Layout optisch gleich aussieht?

In such a situation, to my mind the (theoretical*) answer is clear - You post it in the section dedicated to the app in which you're having the issue, regardless if it's of a "native" nature or using a cross-app embedded function. If the issue / question happens while using X, post it in the section for X. There's too much shared functionality in most apps these days for the customer to have to figure out, "is this a problem with foo app, or with bar module, or with baz library, or ..." Just post in the app's section. For those threads an app splitting in the forum would still cause questions regarding e.g. pixel editing in each of the forum sections APh + AD + APub, which would reduce a possible benefit for those forum users that read / scroll through existing threads before posting: Their question might be asked/answered in one of the other two sections already but doesn't get displayed in each of the sections. So this user would start a thread that exists already but just in another forum section which may increase the total number of threads and thus reduce the benefit for those who use a search engine before posting. Actually your 'clear' answer describes a process that is currently used … for those who understand the 3 apps, various personas and win/mac platforms from the perspective of the interchangeable document file format just as different interfaces of 1 common, parent app: Affinity. (BTW, ironically there are indeed posts that request a merge of the 3 apps to just 1.) The desire to spilt by file format in separate forums for .afpub, .afdesign or .aphoto may also request (want / justify as useful) to split the forum by workflow, for instance into subforums for Text vs. Image or Vector vs. Pixel, just by the focus on a problem/question that you, one, any user may have currently or most often in mind. Why should an image editing user be more interested to get a question displayed about a missing Text Frame panel in a APhoto (split in an APh forum) ... than in a question about using Adjustments or Masks in APublisher (in an APub forum) ... to give sufficient reasons for a forum divided by app file suffixes but not by workflow issues or other aspects, e.g. a split by screen vs. print design and their very specific issues, tasks and interests?

Hi @Chrissi18, Willkommen in den Affinity-Foren! Benutzen die beiden RGB Dokumente auch dasselbe Farb-Profil? Was meinst du mit "Farbkanal" in einem AD Dokument, z.B. Farb-Definition (Colour-Panel) oder Farb-Feld (Swatches-Panel) oder Farb-Kanal (Channel-Panel, nur in APhoto) oder geht es um Sonderfarben (Spot-Colours) als separate Druckfarben neben CMYK?

I did understand it that way (and edited my previous post by adding the two "I") – in my understanding: if "I changed all Normal to TEXT in Word" it can potentially influence the occurrence of the 'arabic' … as long we don't know that text that causes this oddity after import was not triggered for instance by special characters or style set in Word for the related spots in the text. The fact that altering the Word doc did fix the 'arabic' issue seems to confirm my assumption of a possible culprit in Word. I'm wondering about the start of your initial thread description: Did "perfectly" refer to technical aspects or rather to visual like 'look', 'taste', 'feel' only? If I experience style issues I activate "Show Special Characters" (menu Text > bottom entry) to see where a possibly hidden, invisible character exists within the text and may influence text appearance or flow. (e.g. tab, line break, indent and many others). Also activating the option "Show Text Ruler" (menu View or Window) can help, e.g. to get tab or indent position markers displayed on the ruler above the text frame or to use it to set them at certain positions. I am no expert for the auto-numbering feature but if I want to inspect style details I select specific text rather than the frame layer only. Note, a frame selection with the Move Tool doesn't report the style properties for all text but rather seems to report the settings for the top left position inside a frame (= the text cursor placed before the first character in a frame). To detect specific settings, especially character style options, it may even be required to move the text cursor from character to character (maybe even without selecting any) to get all settings reported (e.g. kerning). – So in your example I'd select the text "6. Reg" and check the settings again. To avoid confusion it may be useful to create for any used formatting a saved style in the Text Styles panel. This way you get possible style deviation indicated in the various UI items as an additional '+' symbol after the style name. Also checking the text field at the top of the Text Styles panel may help to inspect all style properties and possible deviations. Unfortunately this field is tiny and can't get resized but as workaround you can choose to select all text in that field an copy/paste the content to a document page for easier overview and inspection. For saved styles a summary of set style properties is listed at the bottom of the "Edit Text Style" dialog window. Also this content can get copied while its field can't get resized.

Thank you for responding, especially in this German thread and if you need to copy/paste to get it translated. (For website translation I use 'TWP' as browser add-on, without the need to copy/paste to a translating site). Your hint to Firefox colour management options makes me wonder why your settings seem to have "_native_srgb" manually activated while mine seem to be active by default (not showing the "reset" button on the right). I also wonder what the option for "display_profile" would cause and, if it is meant to point Firefox to a different than the current system display profile setting, how would Firefox handle the difference. – Nevertheless, both this my questions might not be relevant for this thread. To check displayed colours in any browser the website https://webkit.org/blog-files/color-gamut/ might indicate possible issues, though I can't judge the reliability of this website. Note its hint, "If you're not using a wide-gamut display to view these images, the different versions might be quite similar, although color matching might produce a difference." Since the issue disappeared for the OP with a mac reboot it is complex anyway to detect any culprit for the reported issue or to judge whether Affinity was causing it or rather macOS while Affinity just made it visible. FWIW, APhoto does not indicate tonal clipping for the OP's screenshot with the embedded "Display" profile, as one might expect if it's a wide gamut profile AND a screenshot that includes wide gamut colours. But as @lacerto mentioned, taking a screenshot of an image without wide gamut (e.g. from an average website) does not cause wide gamut colours in the image even if taken with a currently set wide gamut Apple monitor profile. Before that, to me the 'main issue' is that we/I don't know yet whether Affinity 'simply' opens & displays with the profile "Display" that is embedded in the OP's screenshot or whether it uses a profile with same ASCII name "Display" that a user may either have currently set in their macOS or that may just be found by Affinity in one of the ColorSync system folders. If Affinity doesn't care about available "Display" profiles in the folders but respects the embedded profile than a possible profile name confusion might not matter. So it may be interesting if @YourMJK as the OP of the other, earlier thread you linked above, did solve their issue with a reboot, too (like the OP of this thread) – or whether the issue is reproducible on any setup with multiple Apple monitor profiles and an ASCII name "Display".

For a booklet it is useful to create the layout in facing pages (spreads), which is an option in the document setup/properties. For export + print you have the "Area" option in the dialog windows which lets you choose again. (oddly, there the option for single pages is named "All Pages"). "Single-sided printing" might concern a different aspect: printing on both sides of a sheet (front and back side). This is independent from the layout with single or facing (left/right) pages.

Hi @Tait, welcome to the Affinity forums! It might vary with your printer driver but possibly there is a "Preset" option in the Affinity Print dialog, for instance:

Bisher weiß ich leider nicht, wie das Problem klar zu beschreiben wäre, z.B. wie/wo/wann genau es auftritt und wirksam wird. Der Anfang dieses Threads "In Affinity sehen bei mir die Farben anders aus als in Preview or Firefox" reicht imho nicht aus, zumal die Farbdarstellung vorher schon mal anders war und nach deinem Mac-Reboot wieder so ist wie du es als richtig empfindest. Ein Bug muss entweder für viele User auftreten oder nach bestimmten Angaben reproduzierbar sein. Beides sehe ich hier noch nicht gegeben. Das heißt nicht, dass kein Fehler oder Problem vorliegt, sondern dass das Ereignis aus Programmierer-Sicht nicht als Bug gilt, solange kein klarer Ansatzpunkt benannt werden kann. zB: Unter welchen Bedingungen ist die Farbdarstellung in Affinity anders als in Preview oder Firefox? Oder: zeigen Preview und Firefox oder zeigt Affinity die Farben falsch an? Oder: ist das Problem auf solche Profile beschränkt, die den ASCI-Namen "Display" enthalten oder ist der (tatsächlich irreführende) Name nur eine zufällige Gemeinsamkeit mit der Tatsache, dass es um Apple-Profile für bestimmte Apple-Hardware geht? Und welche Rolle spielt das Erstellungs- und Änderungsdatum dieser Profile? Ich bin aber sicher, dass alle Posts des Threads von mindestens einem Serif Stuff Member gelesen werden. [ PS: Im Unterschied zu deinen anfangs geposteten Screenshots (Getränkedose) finde ich, dass bei den zweiten aus dem ZIP die sRGB-Version weniger "leuchtkräftig" (less vivid) wirkt als die mit deinem lokalen Profil (also umgekehrt zum Eingangspost), wobei ich nicht weiß, ob das evtl. am Gelb liegt, während das erste Motiv mehrere Farben zeigt, oder daran, dass dein Profil eingebettet ist. Für einen Bug Report wäre es vielleicht gut, mehr als nur Gelb zu sehen, und das zugehörige Profil als zusätzliche .icc Datei zu bekommen. Wenn ich in ColourSync die groben Profil-Diagramme vergleiche, hat dein Profil einen größeren Umfang / deutlich anderen Umgang mit Grün (was ja für mich in deinem Gelb-Bild in Affinity auch kräftiger/grüner wirkte). links sRGB, rechts deins (mit exiftool aus deinem Screenshot extrahiert):

Danke. Das dachte ich mir schon, dass "gelöst" sich nicht auf alle deine Reports zu Farb-Problemen und Adjustment-, Masken-, Rendering- oder UI-issues etc. bezieht.

It's always worth to get familiar with more basics of the Affinity interface, in particular the first three chapters of the Help: "Introduction" + "User Interface" + "Personas". I always thought that would be most interesting when working with a new app, not to mention the various offers in the main menu bar, for instance the menu "File" … 😉

Many (not all) APhoto features + tools are accessible in APub via APub's Photo Persona. … and, once created, you can edited their layers in APub's APub Persona:

Momentan kommt im Text imho noch zu oft "scheinen" vor, um ihn in ein FAQ oder Tutorial zu packen. – Kannst du denn jeden der Punkte bei dir lokal reproduzieren? Zudem ist unklar, welche Rolle dabei eine jeweilige macOS Version + Apple-Hardware spielen, (was ein FAQ verkomplizieren würde, um eindeutig / hilfreich zu sein). Allerdings ist die Bestätigung von @zuiui zum Mac-Neustart um das Profil-Problem dieses Threads zu lösen definitiv interessant + hilfreich, besonders weil die UI sowohl von macOS als auch von Affinity den Eindruck erwecken, auf Änderungen von Profileinstellungen unmittelbar zu reagieren. Zu einem FAQ mit dem gesamten Inhalt wird es vermutlich nicht kommen, weil auch Serif anscheinend nicht wirklich sicher ist, was wie und wo welchen Einfluss hat. Vgl. z.B. • deine div. Posts / Tests zu Farb-Problemen in APhoto (inkl. Issues mit Adjustment-Layern in CMYK Dokumenten). • @lacerto's zahlreichen Tests + Dokumentationen zur PDF-Ausgabe mit den komplexen Kombinationsmöglichkeiten bei Dokument-Einstellung ("Assign"/"Convert") versus Export-Einstellung ("wie Dokument", "Profile einbetten", "in Profil umwandeln"), die für korrekte Farbausgabe teils paradoxe Einstellungen erfordern (z.B. für Graustufen vs. CMYK oder RGB), • plus der fehlenden Option "Werte beibehalten", • oder die Threads zur Anzeige unterschiedlicher Farbwerte je nach UI-Panel (die in meiner Erinnerung von Serif / Moderatoren nicht kommentiert wurden), • oder die getaggten aber ungelösten Bugs zu Soft Proofs. Das alles taugt eher für (negative) Warnungen (vor inkonsistenter UI, fehlenden Optionen, fehlerhafter Farbbehandlung) als für ein (positives) FAQ oder Tuturial, oder?

Welche anderen hast du gelöscht? Alle alternativen Apple-Monitorprofile? Vielleicht muss das Problem von einem V2-Nutzer nochmal separat angestupst werden, denn im Nov. 2023 schien @DWright das "Farb-LCD" nicht zu kennen: … während @Lee D es 9 Monate vorher als untersuchenswert gemeldet hatte: … wobei unklar ist, ob den Entwicklern / Moderatoren nur der deutsche Profilname unbekannt war/ist, oder grundsätzlich der Unterschied aus "Colour LCD", "Color LCD", "Farb-LCD" etc. und dem ASCII-Namen "Display". Es wäre sicher sinnvoll, wenn Affinity in seinen Menus nicht "Display" verwenden würde, sondern einen der eindeutigeren Profilnamen. Das erinnert mich an ein Problem im Resource-Manager, der in seiner Detail-Beschreibung lange Profilnamen einfach abschneidet, was zB auch bei Ausgabe-Profilen wie z.B. "Schwarze Druckfarbe ISO coated v2 (ECI).icc" ein klares Erkennen des Profils unmöglich macht. (Wobei ECI.org / Adobe von diesem Profil auch Varianten erstellt haben, die alle mit demselben Namensteil beginnen und sich im abgeschnittenen Ende unterscheiden.). Eine minimale Verbesserung wäre schon, den gesamten Textblock nach links zu verschieben, besser aber, den Profilnamen auch mehrzeilig zu ermöglichen. FWIW, this UI-layout issue was reported with other issues in the Manager various times and logged with several tags, e.g. afb-4309 | afb-4320 | afb-4719 | afb-4720.

Ich habe vor Monaten die Erfahrung gemacht, dass ich den Mac neustarten muss, um ein bestimmtes Profil für Affinity unzugänglich zu machen. (als wäre es bei Benutzung in einen Serif-eigenen temp od. cache Ordner kopiert worden) Der verlinkte Issue-Thread erwähnt nur /Library/…, doch außerdem können auch in System/Library/ColorSync sowie in ~/Library/ColorSync noch weitere Profile liegen. Das Profil-Handling der Apple-eigenen Profile (Apple-Hardware) finde ich verwirrend. Der auch hier im Thread im Nov. 23 erwähnte Unterschied in den Varianten zur Profilbenennung (Display" <–> "Farb-LCD", plus weitere Sprachversionen) macht es für mich auch etwas unklar, welches Profil Affinity definitiv verwendet, wenn es ein Bild öffnet, das ein Profil enthält, das mit selbem Namen "Display" bereits auf meinem Mac existiert. Evtl. greift Affinity bei Namensgleichheit auf bereits geladene Profile zurück, zB aus "Performance-Gründen". Ich sehe bei deinen zwei Screenshots in Vorschau (Preview.app) keinen Unterschied – aber einen (geringen) in Affinity: Dort erscheint das Gelb deines Screenshots mit deinem Apple-Profil etwas grünlicher während das Bild mit sRGB etwas wärmer erscheint (wie beide Bilder in Preview). Nicht nur die Varianten von Profil-Benennungen sondern auch die Erstellungs-/Änderungs-Daten der Apple-Profile sind irritierend: Es scheint, dass sie jeweils das Erstellungs-Datum vom Zeitpunkt des Screenshots bekommen, also dem Moment des Einbettens des Profils. Das macht es schwieriger, ein "Original" zu identifizieren. Bei anderen Profilen, zB sRGB oder mein mit X-Rite erzeugtes Monitorprofil, bleibt das Ursprungsdatum des Profils auch im Screenshot erhalten. – Seltsam ist auch, dass die Apple-Profil-Dateien im Library/ColorSync/Profile-Ordner system-eigene Namen (lange Ziffern-Ketten) sowie geänderte Erstellungs- und Änderungsdaten haben, obwohl ich sie nicht benutze. In diesem Ordner liegen auch Profile für meinen externen Eizo-Monitor, die mit X-Rite erzeugt aber von mir anders benannt wurden. Deren "Originale" scheinen dagegen in ~/Library/… zu liegen, mit den Namen und Daten wie ich sie erwarte. Als würden sie durch macOS gelegentlich vom User-Library-Ordner in den /Library-Ordner kopiert werden. Ich werde also momentan nicht schlau aus dem Apple-Profil-Handling. Interessant bleibt aber, dass das Problem bei dir in Affinity "vorher" nicht auftrat und es offenbar möglich ist, die korrekte (oder erwartete) Farbdarstellung in Affinity zu erhalten. – Da ich mit meinen Screenshots + individuellen Profilen keine Farbabweichung in Affinity sehe, ist für dich vielleicht auch eine Chance, wenn du ein eigenes Profil erzeugst, dass dann eine mögliche Namensverwirrung mit "Display" in Affinity vermeidet. (wie es ja für dich auch mit dem sRGB-Profile nicht auftritt). Wenn du keine Kalibrationsshardware hast klappt es eventuell, mit der macOS-internen Software ein Profil zu speichern, das dann nicht automatisch "Display" heißt.

Good to know. How about bleed in PDF with the Export Persona?

What workflow did you try or had have in mind? In APub your English text is not linked to an external resource file that you could just replace, so you need to copy/paste anyway to replace English with another text. But yes, if you want to maintain different styles applied to the text in a frame (or a story of linked frames), you need to either replace selectively (per style) or replace all + restyle all. Where the type/structure of text allows this, the style property "Next Style" can make the restyling easier.

If objects that are placed at the artboard edges got created in the required size so they exceed the artboard size, then it maybe sufficient for those to activate bleed in the document properties. (kind of 1 click as mentioned by @loukash) But if the objects need to get created larger (as in your circle example screenshot) then you need to edit each of the according objects. Possibly you use the Contour Tool to increase the outer shapes (e.g. instead of resizing via Transform Panel). Dirty workaround: If you alternatively want to increase all objects on all artboards simultaneously but without increasing the artboards you can choose "Select All" -> activate the Context Toolbar option "Transform Objects Separately" -> set the anchor in the Transform Panel to centred -> and add a percentage for Width or Height (with the aspect ratio locked active). This enlarging method also works for selected objects only but then it may require many single clicks to select the wanted objects.

You can copy text layers in Affinity, too. But, unlike ID, Affinity doesn't have Global Layers, so you would need to copy all single objects, not just one layer to get all other copied. (I assume the text frames aren't on a master page) Possibly the various "Select" options can support you when copying the objects. Note, in V2 you can select objects on multiple pages of a document, and move them all with 1 click, … maybe you can also copy all selected objects. Nevertheless, if you want to create separate issues of your magazine (one for each language) then the problem of hiding all frames of 1 language in the layout document still remains. I don't know if this can be solved with multi-selection as just mentioned for move (or copy). Hopefully a V2 user will occur with an efficient workflow idea. If not, you could copy the entire document and use the existing text frames (without copies) to replace the existing text and result with multiple .afpubs, one for each language. Well, this workflow will become tricky if you finally need to change layout items (e.g. images) … on the other hand separate documents might make adjustments to the layout easier which may be wanted according to the different amount of space required for by various languages.

This is how bleed is expected and meant to be handled: Not increasing the final print page size but adding bleed (as your topic says) which gets cut after print. Unfortunately, there still seems to be a bug with bleed & multiple artboards … which possibly may require workarounds done to the document layers. – Note, the thread below started in 2021 (V1) and jumped to 2023 (V2) at the end of page 1. So maybe you first want to try to export via the Export menu command, not the Export Persona. Also unfortunately it seems another bleed bug for print (not export) got fixed in Nov. 2023 … but was reported in Dez 2023 once more.

To make them appear under your posts add them to your Account Settings -> Signature. (not via 'Edit Profile') -->

If styles get added on import with same name but an additional number it may indicate that the imported document contains different definitions for an applied style with that name. "I changed all" & "I did nothing" sounds contradictory to me. I wonder whether in Word … … all visual appearing formatting is saved identically in its applied style … no style appears visually that is not also saved as a style with that visual appearing definition. • Are in Word character styles used or paragraph styles only? • If you select a text character in APub does its style name in the context toolbar or the paragraph panel display a + symbol after the name? In the "Find And Replace" panel click on the cog icon and chose a style option, for instance to open the menu of available paragraph styles …

Known issues/bugs don't seem to be focused or prioritized when they impact workflow efficiency only. Unlike newly developed features that may offer pure efficiency improvements, fixed bugs seem to focus on those issues that have no workarounds to avoid them in a workflow – or depending on the complexity of fixing them, like unfixed long-term issues may indicate, like “can't open”, “access lost” or "corrupted document".

Adjustments as assets have various issues reported, some got tagged, e.g. afp-3400 or AF-617, others just discussed. Although they may work "generally" (example) their use may differ and thus complicate the situation and occurring issues. For instance…

No doubt, different users have different expectations. It may require more individual filter settings or/and Invision development work. If the existing notification options for a thread can get set independently of nudging then notifications could continue to occur for posts of non-ignored users even if a thread would not get nudged … and a nudge-resistant thread would still be fully available according to the individual ignore-settings.