lacerto

If you are looking an InDesign kind of document specific setting to define how superscripts, subscripts (and small caps) should be handled, I do not think that there is such feature in Affinity apps: ...so Affinity apps use the font specific settings. Modifying the font would allow you to change the behavior (use similar percentual values to define size and position of these attributes).

IMO the feature works similarly as it has always worked, both on Windows and on macOS, and both with v1 and v2 apps. That is, the "default" simply just loads the specified palette as a working palette at document creation time. It does not activate the palette so that it would be selected when the document is created (instead, the last used in-built or application palette would be active). The best use of this feature would be creating a custom palette e.g. with some often used color definitions (e.g. named corporate colors, overprint and knockout versions of black, standard rich black, spot colors, etc.) defined as a document palette so that global color definitions could be used, and then specifying it as a default for e.g. CMYK/8 documents:

It blended fine on canvas and when exported to raster formats, but I could not export the effect in vector formats at all (though only tested PDF). I used PDF v.1.7 which should not have problems in retaining live transparency (blend modes), but no success. No they are not. I'll need to revisit this in both apps to get a grasp why this works in VectorStyler and not in Corel. Logical operations are basically old-school Boolean register operations so different from modern blend modes, but I am not sure if why this works in VS but not in Corel is a bug in VS or in Corel! Anyway, the Add blend mode also works differently in VS and Corel.

You have basically understood this correctly. When you visit this dialog box, nothing is normally done (as regards assigning or converting of colors) unless you have changed the active color profile. If you have changed it, "Assign" will keep your current color values for native objects (like text and shapes and other "vector" objects), but just tag them with a different color profile (e.g. for export), not changing their present color values, but most probably changing their visual appearance (e.g. if you change assignment of full red of sRGB 255, 0, 0 to Adobe RGB, the redness would be significantly brighter in Adobe RGB color space, provided that your display is capable of showing the full color gamut of Adobe RGB color space). If not, you can test this by using two color spaces that are displayable within the color gamut of your monitor, to see the difference. Conversely, if you convert from a narrower color space to richer (like from sRGB to Adobe RGB), the appearance of redness of full 255 of the sRGB color space would require "less" from a richer color space to represent the same color, so the conversion value might be something like R 219 G1 B0 when using the "Convert" option (the values might be slightly different in different apps depending on rounding accuracy and color engine used for the conversion). Note that Affinity apps cannot convert the values of color swatches in context of color conversion, so if you have made swatch assignments for objects, the color values of objects will change in context of "Convert" option, but as the swatch definitions would not be changed accordingly, you would lose the connection between the swatches and swatch-based object color assignments. That might be a big issue e.g. in context of a map or similar kinds of designs where hundreds or even thousands of objects might have colors assigned by using color swatches, as all these links would be lost after a color conversion. As for importing ICCs (within Photo), I am not sure if this feature does anything else than copies a user-picked ICC file to the location where Affinity Photo looks for ICC profiles to be listed in context of color profile related operations. I suppose that normally Affinity apps require restarting of the app to be able show up-to-date lists for ICCs available for these operations. This menu command might be useful also to detect the folders where Affinity apps generally look for color profiles, as the locations are app specific and also different depending on whether the app was purchased directly from Apple or Microsoft Store (version 2 apps might further complicate the situation depending on whether the default or an alternative MSI installer was used for installation of the app). Anyway, by using this command, and subsequently using the system file search, the user might be able to detect the folder used by the Affinity apps to enumerate the ICC color profiles for color conversions. Considering that the situation was made still more complicated with version 2 apps, it would be a good idea to implement the same command in context of all three apps.

I am not so sure about this. It is much about compatibility and "standards". And that is the sole reason Affinity apps are "bringing sanity" into this thingamabob. Serif is determined to support IDML, therefore they are married to Adobe "insanities", which in part are no doubt results of needing to support exact line spacing of Word, which are to some extent necessitated by ability to support inline math expressions, and who knows what age-old import needs. It is called culture, support of diversity -- not easily explained and rationalized in any field. UPDATE: To be more accurate: I think that the Adobe style default line spacing allowing character based overrides comes partly from the Word-kind of “At least” line spacing that allows single exceptional line spacing within a paragraph (while the other line spacing options force common line spacing throughout the paragraph). In InDesign this feature is additionally improved so that it is possible to use line spacing overrides so that not only is a single line allowed to be larger than line spacing of the whole paragraph (like in Word), but that it is also allowed to be smaller than that of the whole paragraph – provided that all characters within a line use the same exceptional line spacing (which Is not supported in Word). This feature is useful e.g. in headings. Affinity apps support the same practice, so in this sense they are not putting any sense at all to “Adobe insanity”, but simply just follow it (to support IDML), and accordingly might confuse users expecting forced paragraph based line spacing. I do not think that there is an option available in Affinity apps (contrary to InDesign) that allows supporting Word or QuarkXPress kind of forced, paragraph based line spacing. IMO the way InDesign implements line spacing makes a lot of sense since it leaves the full control to designer.

I agree, because JPG (and TIFF) are fully color managed methods of delivering / exchanging image data. There are advanced things like whether overprint attributes are supported in raster data (as it is as an option when exporting JPG images from Adobe apps), which might be extra (similarly as proprietary data that can be smuggled within TIFF; or PDF and EPS, for that matter), but this is different, and IMO a clear bug. IMO v2 apps are (unfortunately including some key features) simply -- but hopefully just "for the moment" -- broken. So therefore possibly not worth reporting at this stage? But I am (still) optimistic that these could be symptoms of some fundamental changes having been done in the core of the apps, making things like full-fledged object model available for scripting (and creating plug-ins). This would be the best thing to happen, as it would make it possible to create shortcuts to hundreds of workarounds devised by the community to make Affinity apps behave more in a way they are expected to operate [because of assimilation to Adobe culture], and more importantly, to deal with the limitations that many in-built-functions of Affinity apps sill have .

I am not sure if I understood correctly your point. Attached is a symmetrically opposite case where you have a CMYK Publisher document using PSO Coated v3, and underlying RGB profile using sRGB. When the file is exported in CMYK color mode without changing the profile, the native CMYK definitions are passed through (and native RGB will be converted to CMYK according to the profile specs), and when you export to digital media (target profile and underltying profile being sRGB), the native RGB definitions are passed trhough (and native CMYK will be converted to RGB according to profile specs). Attached is also the same document in RGB color mode. You can produce from either file PDFs that use native CMYK when producing to CMYK, and native RGB when producing to RGB, disregarding the document color mode. But what you cannot do is produce a PDF that has mixed RGB and CMYK native color values to be resolved at print time with embedded profile information. Native color definitions are always either all CMYK or all RGB. But as I tested if I can do the same when exporting to JPEG, it does not appear so. So it seems that I cannot pass through native RGB definitions from a CMYK Publisher document to RGB JPG, nor can I pass through native CMYK definitions from an RGB Publisher document to CMYK JPEG. I have not tested TIFF files, but I would be surprised if they behaved differently from JPGs. I did test both v1 and v2 and there does not seem to be difference in behavior. mixedcolors_rgb.afpub mixedcolors_cmyk.afpub mixedcolors_rgb.pdf mixedcolors_cmyk.pdf

I tried to use vector blend modes, and while they work on canvas and when exported to raster formats, I could not get the Add blend mode work when producing from CorelDRAW or VectorStyler to PDF (keeping vectors). The former could not blend the red at all and latter blended it somewhat like Multiply. However using Logical Or blend mode against white did work in VectorStyler (but not in CorelDRAW), so another fresh experience of a bit odd results when using Blend modes with vectors. Illustrator CS6 does not have Add blend mode so could not test that. Anyway, it is easy to script solid color wells without blends, and here's one created for CorelDRAW in VBA which works on Windows versions of CorelDRAW (old and new), but not on macOS version (which would require JavaScript), so if you still have CorelDRAW you might want to use the script and modify it to easily generate different kinds of vector-format color well sheets, also using other color models. Python and JavaScript would be best for general-purpose SVG-based vector color wells. The shape could be anything, but is here a rectangle. It should be selected when calling the script and have RGB 0, 0, 0 color definition. The horizontal and vertical gap between color wells defaults to 2 mm. ' Lagarto Jan 2023 Dim OrigSelection As ShapeRange Dim origShape, curShape As Shape Dim curR, curG, curB Dim offsetX, offsetY Dim hGap, vGap Dim i, j, k Dim curFill As Fill Dim p As Page hGap = 2 vGap = 2 Set OrigSelection = ActiveSelectionRange 'Assuming original shape as RGB 0, 0, 0 and selected on canvas Set origShape = OrigSelection.Shapes(1) origShape.Copy w = OrigSelection.SizeWidth h = OrigSelection.SizeHeight Set curShape = OrigSelection.Shapes(1) curR = 0 curG = 20 curB = 0 offsetX = w + hGap offsetY = -(h + vGap) ActiveDocument.Unit = cdrUnit.cdrMillimeter For k = 1 To 14 For j = 1 To 14 For i = 1 To 13 Set curShape = curShape.Duplicate(offsetX, 0) curShape.OrderToFront Set curFill = curShape.Fill curFill.UniformColor.RGBRed = curR curFill.UniformColor.RGBGreen = curG curFill.UniformColor.RGBBlue = curB curX = curX + w + hGap If i < 12 Then curG = curG + 20 ElseIf i = 12 Then curG = 255 End If Next If j <= 12 Then curB = curB + 20 Else curB = 255 End If If j < 14 Then curG = 0 offsetX = -13 * (w + hGap) Set curShape = curShape.Duplicate(offsetX, offsetY) Set curFill = curShape.Fill curFill.UniformColor.RGBRed = curR curFill.UniformColor.RGBGreen = curG curFill.UniformColor.RGBBlue = curB End If curG = 20 offsetX = w + vGap Next If k = 14 Then Exit For End If Set p = ActiveDocument.AddPages(1) p.Activate Set curShape = ActivePage.ActiveLayer.Paste If k < 13 Then curR = curR + 20 Else curR = 255 End If curG = 0 curB = 0 Set curFill = curShape.Fill curFill.UniformColor.RGBRed = curR curFill.UniformColor.RGBGreen = curG curFill.UniformColor.RGBBlue = curB curG = 20 Next End Sub wells.pdf

This does a pretty good job. I tried this with Topaz DeNoise AI, combining it later with Threshold in Photo, and the results were pretty much the same, but this does it in one go!

Does this make it a bug in a bug or a partially fixed bug on its way of becoming a useful feature being intentionally disabled. If this is really a selling point needing a fix, why not do it so that the feature that is already implemented would be available if Publisher is installed, and otherwise hidden. The same principle could then be applied also for e.g. having Live Filters available in the Layers panel of Publisher (without Persona) and Designer, and other similar cases where already implemented features are just hidden for apparent commercial reasons (like being able to convert a pixel layer to an image layer also in Designer and Photo, which based on this fix might also become "fixed" in a similar fashion=.

Yet another method: With Color Picker, sample using 65 x 65 px radius a spot from the candle on the left (I have created a circle where the sample color is picked; the HSL value I got was H59 S48 L54: Using the Info panel, place a sample (magenta crosshair on the right side of the candle top, approximately at the same spot where you sampled the color from the front side of the candle on the left. Mask the image so that recoloring is only applied on the candle. Add Recolor Adjustment Layer, and set the Hue to 59 and Saturation to 59, then use the Brightness control to make the image brighter until you get approximately the L-value of 54 into the sample box of the Info panel:

I tested this copying a vector shape from Photoshop 2023, and indeed get both SVG image format and text formats listed, so there are no problems pasting same content either as code (e.g. in VS Code or in Affinity app text frame) or as image (in any app supporting SVG rendering). When Affinity apps copy a vector shape, all string entries are empty, and there is no specific SVG image entry. Because this works on Windows versions of Affinity apps, and this post shows that this is not a macOS Clipboard limitation, this appears to be a clear bug: EDIT: I was a bit slow, but I could have verified this already when using VS code and copying code from there (as was shown, it can be pasted as rendered graphic object, or code in a text frame, but here, too, the Clipboard contains both explicit text formats and two HTML formats (with SVG embedded). I am not sure whether Affinity apps use the text format and just render it in context of canvas paste, or if they use the HTML format, but the point to prove was that VS Code, too, places SVG code on Clipboard in multiple formats, explicit text format to be used as code, and HTML format to be interpreted and rendered graphically. EDIT2: Later confirmed that Affinity apps can use the plain text code both to render the graphics on canvas and code in a text frame, so the problem of text/code editors not being able to paste Affinity copied SVG content from Clipboard is that the text entries are empty (and additionally because the SVG code is not available via an image tag, either, but just as a file link).

Sorry, I meant the Clipboard content when having copied an image from Illustrator! (I do not have Illustrator currently installed on macOS and my installed Windows version is CS6 which only places PDF, PNG and PS3 on the Clipboard).

Ok, can you use a Clipboard viewer to see how that data is placed? I ask because when using VectorStyler, the SVG code is not placed separately as text and SVG image but as text and PDF. Placing it as text (plain SVG code) would require the pasting app to make a choice of rendering the data as graphics or text (code), so require some additional effort. But if Illustrator places SVG data both as text and svg image (similarly as happens on Windows also when using Affinity apps), then this is a clear omission by Serif.

Yes, and the sub layers being shown in PDF readers may also be useful considering e.g. printing needs so the feature may be useful to work around the issue of some print shops wanting a PDF with native layers (to be opened in Illustrator for printing purposes). I am not sure if other graphic apps can do that (probably partly because hierarchy is typically flattened when opened).

Yes. I think that the preference setting (related to SVG format on the Clipboard) has effect only on what data is copied on the Clipboard. If checked, macOS versions create a temporary SVG file and place a URL on the Clipboard so that apps can embed an SVG file. They place the url in multiple entries, but do not specifically write the code on the Clipboard (contrary to VectorStyler). Perhaps this is a bug, or then a limitation related to macOS Clipboard (meaning that it would not be possible to place plain SVG code -- basically identical information -- both as string data and data intended to be rendered as graphics.

The same content (copied using VS Code) pasted in Designer v.2.0.3 (macOS version), disregarding the Preference setting: Left: source code copied onto Clipboard. Right top: when pasting directly on canvas, right bottom: pasting same content into a text frame:

The difference between versions 1 and 2 seems to be (at least) that version 2 apps now write PDF sub layers (which PDF readers like Adobe Acrobat and PDF X-Change can read). But all apps that I have tried and that read in PDF layers (= OCG, optional content groups), e.g. Xara, CorelDRAW and VectorStyler, only support root level layers so even if sub layers are read in, the hierarchy is not (and apps differ in whether objects are placed in root-level layers or if all objects are directly just placed in the root. And the changed behavior does not change the situation where Illustrator (at least CS6) does not read in any OCG layers (even Adobe created), but only support native AI layers that Illustrator can save as part of PDF. But Affinity apps do read in that layer hierarchy (even if not full document hierarchy, e.g. groups within layers). In this respect passing complex object hierarchy between different apps (via PDF) continues to be as difficult and restricted (proprietary) as always.

I just tested this on macOS Ventura using Designer v.2.0.3 and Visual Studio Code. If I create code in VS Code, copy it on the Clipboard, and paste in Designer directly on canvas, I get graphics. If I create a text frame and paste, I'll get code. This happens disregarding the Clipboard setting related to SVG in the Preferences. In this regard the behavior is the same as on Windows. The other way around, SVG specific information is placed on the Clipboard when copying graphic from Affinity apps only if the referred option in the Preferences is checked. When the option is checked, SVG data is placed on the Clipboard on Windows as pure SVG code and can be pasted as graphics in an app that renders SVG as graphics, and as code at least in Visual Studio Code, but only on Windows. The macOS version of Visual Studio does not support this, or more likely, Designer uses a method of placing the SVG specific data on the Clipboard that is non-standard and cannot be read by at least Visual Studio Code. As I checked this using Clipboard Viewer, Affinity seems to create a temporary SVG file and place information on this by using on Clipbpard as public.file-url: file:///var/folders/_5/3_qwgk1534bf0p_1y5bj98pc0000gn/T/Affinity%20Designer%202/Clipboard.svg I am not sure if other apps that read Clipboard actually use this information when pasting vector data, or PDF format that is available, as well, but e.g. Microsoft Word can place an embedded SVG file based on this information on Clipboard. On Windows Word, I have this, when I have copied graphic on Clipboard (having the SVG specific preference checked): If I select "Unformatted Text", SVG code is pasted, and if I pick SVG in picture format, I'll get vector graphics. In macOS version of Word I can have Paste Special dialog box but the options are like this: Choosing Unformatted Text does not paste anything for some reason, and having the graphics in SVG format requires choosing the Files option. This might be a restriction related to macOS Clipboard and general lack of macOS apps of offering a "Paste Special" feature that allows users to pick the desired format manually, or appropriate Clipboard format based on context or a preference setting. When using VectorStyler and choosing an option to place SVG on clipboard, and using Word, I have "PDF" and "Unformatted Text" options, and both do what they promise. [But there is no specific SVG image format listed as pasting options, so pasting the available code as text or rendering it as graphics would be a choice of the pasting application.] UPDATE: When checking with clipboard viewer on Windows, it can be seen that the Windows version of Designer places copied SVG content separately as image and text data, so perhaps this explains the difference:

Whether an IDML file will be opened in RGB or CMYK color mode in Affinity Publisher seems to depend on whether the IDML file was initially saved targeted for Web / Digital Publishing (in which case the color mode will be RGB), or whether it was saved targeted for Print (in which case the color mode would be CMYK). The actual profiles used as document profiles would probably also be dependent on whether this was done when saving the IDML file but in this case document profiles were not specified, so both in InDesign and Publisher the default working space profiles would be assigned. As for working with photos and printing to a photo printer that expects the input to be in sRGB, you should choose RGB as the document color mode and then ensure that sRGB is the document color profile. When you subsequently set up soft proof using the ICC profile specific to the printer, you should see approximately identical simulations in both apps: a) Soft proof off (both apps using sRGB document profile): b) Soft proof turned on (in InDesign Preserve RGB Numbers unchecked; in Publisher using Relative Colorimetric rendering intent and Black point compensation checked) : The simulated image is a bit more contrasted in InDesign (but I think it is a bit more contrasted already when having the soft proof turned off). But differences are not big. Are you seeing bigger differences? Did you turn off Soft Proof adjustment when printing or producing the print file? (You should.) When exporting or printing, you would produce sRGB color space, which the printer expects to be able to make a proper conversion. This workflow would make it possible to place RGB images in diverse RGB color spaces and produce consistent results.

Much depends on complexity of the jobs, but e.g. publications with 3rd party produced PDF/AI/EPS file content placed are highly problematic (considering the Affinity PDF compatibility rules, workflows not discarding embedded CMYK profiles and not supporting spot colors and overprint attributes and embedded fonts within EPS files; these things behave very differently in context of InDesign publishing). But there is more: many self-publishing services targeted to general public are built on using Adobe apps or Word / Pages based RGB workflows, and expect the print document to be delivered in a specific way, RGB output might be expected by some service providers while transparencies are assumed to be flattened (which kinds of files Affinity apps cannot produce as they do not support PDF v1.3) so they need to be flattened manually (or exported fully rasterized). Pure grayscale productions also cause much problems to users. And non-standard export methods (e.g. not supporting PDF/X-1a:2001) may cause issues with preflight routines requiring specifically PDF 1.3 (as a sign of flattened transparency, even if the export job would not contain transparencies) or an explicit bleed box (even if crop marks are not used). For high-end publishing there are also quality issues like lack of proper transparency flattening (without rasterizations), issues with antialiasing artifacts resulted from mixed color spaces involved in transparency flattening, and issues dealt in this thread related to producing to multiple color spaces from the same document. Not having clearly documented workflows is problematic especially as users are not likely to get step-by-step instructions from the printshops and commercial printers. The expectations of those trying a full switch from Adobe ecosystem are often also unrealistically high, partly because of marketing hype, partly because Affinity apps have clearly been built so that switchers would immediately feel at home. Whether the actual differences hit hard or not is much a matter of not just complexity and variety of productions but also degree of co-operation (and file exchange and compatibility) needed.

I might be wrong and state inadequately tested information so I need to recheck, but I think that this is how the Affinity apps behave as regards CMYK content: a) PDFs placed to be passed through should pass through all CMYK values as they are without conversion. If the values get converted, the reason is probably that the content has been rasterized because of so called "compatibility rules" (e.g. if non-PDF/X-based PDF content is placed, it will be rasterized no matter which PDF/X-based method is used; also, if placed PDF content is of later PDF version than the export, the content will be rasterized). b) What I mentioned above about AI files with profile was inaccurate. First of all, native AI content is not supported at all, so whatever gets exported is interpreted PDF stream content, and it seems that CMYK color values will be passed through in case the AI file does not have embedded profile, or if the embedded profile matches the Publisher document CMYK target. What is disturbing is that version 2 apps seem to always rasterize AI content, no matter what. c) Raster files with CMYK content (specifically TIFF, but most probably JPG, as well) and embedded profile will be converted if there is a profile conflict so the CMYK values will be passed through in case there is no embedded profile or if the embedded profile matches the Publisher document CMYK profile. What I mentioned in my previous post related to PDF/X-based exports behaving differently, I now could not reproduce, neither in version 1 or 2 apps, so perhaps it was just a glitch (I have now tested solely Windows versions, though). EDIT: CMYK JPGs without a color profile or matching color profile seem to behave similarly as TIFFs so they get their CMYK values passed, and converted when there is a conflict (except when using PDF/X-1a, where all embedded CMYK profiles are discarded). CMYK PSDs without a profile or with conflicting profile however seem to behave differently so their color values get converted, and a PSD file without a profile will get the working space CMYK profile assigned when placed, rather than the document CMYK target (which seems to be a bug). Version 1 and 2 apps seem to behave similarly here (but I have so far only tested Windows apps). I suppose the difference is related to former being handled as "documents" which, when opened, create a new document (with specific canvas size), while the latter are placed within an existing document.

You can paste SVG code as code in Affinity apps if you first create a text frame (pasting SVG code directly on canvas will cause rendering of the code as graphics). If you have enabled in Preferences copying items in SVG format on Clipboard, you can place graphics from Affinity apps onto Clipboard in SVG format and paste it rendered as graphics into apps that support that (like Inkscape), and on the other hand, paste the same data as code e.g. in Visual Studio Code. This works at least on Windows.

Multiple notes: extrude objects, trace tool, calligraphic pen and strokes, true vector brushes, vector, hatch and PS patterns, automatically spaced dashed lines, etc... Though this was in 2004, MXa (11.02), here running on Windows 11 Pro:

I assume that this is what happens. I do not think that the behavior is properly documented (e.g., whether this only happens when opening a document with a conflicting color profile and converting, or if the same method is used globally whenever conversions are needed). Anyway, there are no image-specific settings (either for making sure that an image really has the desired color profile and changing it if needed, nor for image-specific rendering intent), so there may be situations where you want to convert to target CMYK (when known) to guarantee best possible conversion. The Resource Manager basically shows the color profile (either embedded or an empty string if no color profile is embedded), but I am not entirely sure that placed images without a profile actually get assigned with the current document profile, or if the need for conversion is examined only when needed, e.g. at export time or when rasterizing images on canvas. As I just tested this with multiple CMYK profile reassignments, it seems that placed images marked with no profile export correctly (without color changes), while images with conflicting profiles get recalculated values so at least it seems that there is no need to refresh placed content after a profile change (neither in current versions 1 or 2). At some point I think that placed image content without profiles used to be tagged with document profiles and were not always properly updated when the document profile changed. Btw. I just noticed that when placing raster image content (at least TIFFs) with an embedded CMYK profile and there is a conflict with document CMYK target, the raster images are handled similarly as AI files with conflicting CMYK content and get recalculated color values -- but not when exporting by using PDF/X-based methods! I had not noticed that before (because I very rarely place images in CMYK mode, and if I do, always convert to required target). So there is frequently a new oddity to learn about (as mentioned, Adobe apps by default discard all CMYK profiles, PDF/X-based methods are not a special case). @loukash is just kidding... I did not know anything about PDF intricacies before entering the Affinity environment, and still know very little, but I have just learned about differences in production methods between Adobe and Affinity apps. I think that the latter make us all kinds of PDF gurus in the long run. Which is not an entirely bad thing 🙂