lacerto

I would create this as a CMYK document and iƒ possible, select the correct target profile at this stage. The RGB profile that would be used for the document would then be the one you have defined in Preferences > Color, and by default it is sRGB. I would then place all raster image content (photos, etc.) as RGB files. You would not see full sRGB gamut while working in Publisher, but would get the images in native sRGB once exported to digital PDFs. If you need certain native objects, fonts, etc. to be defined in RGB, you could define the color values in RGB color model (using the Color panel), even if their appearance would be adjusted to simulate the current CMYK target. If it is important to see the full sRGB color gamut while determining the color values, you could temporarily switch to RGB mode (as said, just switching the color modes does not change color values as long as you do not have (Pixel) layers). At that point, you could also have Soft Proof adjustments to have an approximation on how specific RGB definitions look in different CMYK color spaced or in grayscale. You could alternatively of course create the document in RGB mode (and select sRGB as the document RGB profile). But as mentioned above, you would at some point need to specify the actual target CMYK profile and most probably change it from the default profile determined by Preferences > Color. That is a bit tedious process, and there are rather strict steps that need to be taken to not cause inadvertent CMYK conversions at the time the production PDF is created (as mentioned, CMYK conversions WILL happen at export time, in case you use PDF/X-based methods, or the default press-based export methods, that explicitly use the CMYK color mode). The additional restrictions as for applying coloring on grayscale images (not having the important K-Only button available), etc. might also be a reason why working with a CMYK document might be more useful and straight-forward, despite the narrowed RGB color space while working (but not when producing). As for determining CMYK values for native objects (shapes and text), the most important thing is to use K-100 (and C0 M0 Y0) for black text. For other objects, I would use RGB definitions, which would then be converted to optimal CMYK values according to the CMYK target that you would know at the time of production (you could use another document in RGB mode to see the colors in full color gamut, or temporarily switch to RGB color mode). I would initially choose a generic CMYK profile (like the default US Web Coated v2) that has TAC limit around 300%). This way, if and when you change the CMYK profile and you have any CMYK definitions or placed CMYK content, you could most often just "Assign" the new profile so that CMYK color values do not change. But if you have lots of CMYK content and clearly different target profile (e.g. newspaper targeted profile that needs to have low TAC), you would need to use the convert option when choosing the new profile, and then change the black text color (now changed to four-color-black) back to K100. There are some additional considerations, mainly related to placing CMYK content that has embedded profiles. When you place these kinds of files (e.g. AI files), InDesign by default discards embedded CMYK profiles and just passes through the native CMYK values, so does basically the same as when placing PDF files. Affinity apps, however, would leave CMYK color values unchanged only if the placed AI file does not contain an embedded profile, or if the embedded profile matches that of the document target CMYK profile. (For PDFs placed for passed through the native CMYK values would always e passed through). This might cause some headache whenever a CMYK document profile is later changes, as I am not convinced that the placed CMYK mode files will be correctly updated to have information about changed conditions so that color values would not get incorrectly converted when creating the production PDF. I am sorry for providing (likely) "too much information", as your situation might be much simpler than described here so you would not need to take into account all the aspects described here. But simplified instructions might be harmful, too. The best advice I can give is to use a tool that can check the produced color values from the PDF itself. If you do not have anything better, opening the production PDF in Affinity Publisher (or Photo, where you can also use the Channel panel to view separations, and view histograms) would make it possible to view the color values of objects and pixel layers (even if you could not check things like overprints).

No, it is still there. Using different pressure curves gives different artifacts. E.g., the one shown in my screenshot has filled inner shapes (which might be useful to produce kind of broken typewriter effects), but having a bit different curve might keep inner shapes open but produce odd ray-like artifacts extending far beyond the character shapes. I'll check if dashed lines could fix this. If the kinds of shapes that are shown on canvas could be produced, this would be a great feature. I have not tried this with true pressure so the curves that I have tried have all been mouse-drawn curves.

Yes, shape effects can naturally always be applied on curves. I was primarily looking for ways to do equivalent to what was asked by OP (when using a special font with rough edges) that would retain at least editability of the text (even if the effect itself is rasterized, as it is when using a bitmap fill in character strokes) but could ideally also be exported as text (searchable if possible, or editable as an embedded native feature).

Once there is scripting support (probably Javscript based), scripting becomes more useful as a specific script could then most probably be invoked with appropriate content as input and also location for output. Before that I would use scripting for these kinds of tasks only if there is massive repetitive use for an operation, or if there is already a script created for the task. So typically I'd look for support in graphic apps that can exchange content with Affinity apps, free ones, like Inkscape, if there is nothing else available. E.g., for this task, Inkscape has split text functionality that can separate a Clipboard passed text block by line, word or letter to separate text objects, which could then be copy pasted back to Affinity apps and finally distributed horizontally and vertically as needed. Formatting would be supported, as well:

As for roughening edges of text, there is some promise in Affinity apps, as using pressure stroke, as shown by @loukash above, and possibly using bitmap fill on the stroke of the letters might work, even if pretty tedious to apply. a) When using bitmap noise, care must be taken to apply the "Nearest" option to avoid blurring, and at export time downsampling should be disabled to avoid mid tones in PDF output: b) When using pressure, the biggest problem seems to be to produce a kind of a stroke that will not produce artifacts when exported: roughened_text_ad.pdf The benefit of Affinity applied effects is that text is retained as text when exported to PDF, and that the effect can be applied as per character. Pressure profiles can also be saved (at least temporarily). In Illustrator, where Roughen filter can be applied to text frames (but not to selected text), the effect in PDF exports stays so working is very predictable: roughened text_ai.pdf ...but the exported PDF does not retain text as text (but does retain editability as text in Illustrator, if that export option is used when PDF was exported). It seems that roughening effects in VectorStyler can only be applied on artistic text; export predictability seems to be pretty good but it is difficult to produce consistently roughened shapes, partly because effects are applied directionally, so lots of experimenting is required, and possibly applying the same effect with different parameters multiple times. But as mentioned, the parameters can be saved as styles. In CorelDRAW noise and distort filters can be applied on artistic text but are not applied as per character which makes them pretty useless in text content. Roughener shaping tool can be used selectively but that would be quite a tedious job. As for applying roughening to shapes (like triangles), Illustrator is rather limited but there is no match to its consistency and general behavior, but if the kind of diffused results are wanted, applying raster-based effects would probably be more appropriate. [BTW. The referred "Afans Filters" are nothing but APhoto Live Filters exported to assets. They do not work properly (not all effects actually produce an effect), and when applied, will rasterize everything on the page (even vector objects placed above the filter), unlike when applied as live filters as per object in APhoto or Publisher (via Photo Persona). So if live filters are wanted to be smuggled into Designer, it is best to just edit the .afdesign file in Photo, apply the filter there and then continue editing the file in Designer.]

Or still more accurately: "Use document profile" means (when CMYK is selected as color mode in the control above): use the current CMYK color profile set for the document (which is by default one defined in the Preferences > Color when the document was created, or one defined manually last time the document color mode was CMYK). This option will then pass through all CMYK values defined for native objects, and will convert all native RGB values to the target CMYK (also when using PDF/X-3 and PDF/X-4, whereas Adobe workflow does not, as by default it would pass through all RGB values, with appropriate profiles for later conversion; Affinity apps will convert native RGB to CMYK in any case when using PDF/X-3 or PDF/X-4; and when using non-PDF/X-based export, will convert all native color values either to RGB or CMYK; there is no "do not change" option). Defining an explicit ICC profile at this stage signals to Affinity apps: use THIS profile instead of the document profile to recalculate color values, even if the current document profile is the same as the explicitly defined one (resulting in recalculation). Possible conversion of color values of placed content (mainly raster images) is determined by "Convert image color spaces" setting (but e.g. placed .AI color space will always be converted, disregarding the value of this setting). However, PDF content placed to be passed through will never be converted (unless becoming rasterized), e.g. not even when exporting placed RGB PDFs to CMYK and forcing conversion of image color spaces, or exporting placed CMYK content to RGB. This kind of behavior can make it very hard to produce properly to multiple color spaces (pure CMYK or pure RGB)-- or PDFs for optimal late color conversions with correct source and target profiles (i.e., mixed color mode PDFs, and correctly converted placed and native CMYK content).

I seem to have demonstrated the workflow poorly since this is not what happens here. The document was created initially in RGB mode so it got its RGB profile selected at that point. At the same time, a document always also gets a latent (implied) secondary (in this case CMYK) target profile, and this will be the profile defined in the Preferences > Color. In my case, this would be ISO Coated v2. I show on the video, how I change the underlying ISO Coated v2 to PSO Coated v3. This needs to be done so that I first switch the color mode from RGB to CMYK without changing the CMYK profile at that stage (it would result in change of color values). After the color mode is switched, I go and change the CMYK profile to PSO Coated v3 by using the Assign method, so that none of the color values change. After that I finally switch back to RGB mode so that I can demonstrate how to export from an RGB document a PDF/X-4 document so that CMYK definitions are retained. They do not change because the document is exported explicitly in CMYK color mode (and NOT the document color mode, which is RGB, and which Affinity apps cannot use, so this option results in using factory default US Web Coated v2, and changed color values). Additionally, the CMYK color profile must not be explicitly selected but left as "Use document profile", which is now PSO Coated v3 (if PSO Coated v3 is explicitly selected, I noticed that there are minor rounding errors, showing that color values are actually recalculated instead of just left at their existing CMYK values). I do not understand why the color profiles cannot be selected and assigned/converted simultaneously similarly as in InDesign and CorelDRAW, as this is quite complex now.

Here you go, but targeted explicitly to PSO Coated v3, as shown in the clip below (the initial latent CMYK target is ISO Coated v2, as per my system CMYK default): pdfx4fromrgb.mp4 Note that you need to ensure that your underlying (implied/latent) CMYK target profile is correct. Also, when you export to PDF/X-4, you need to change the target color space to CMYK (from the default "As document", which would actually use factory default US Web Coated v2 as the target profile), and then choose "Use document" for the CMYK target profile; choosing explicitly the target at this stage MAY result in retranslation of colors even if the target matches the implied CMYK target (recalculation will happen and there may be rounding errors)! Note that in version 2 you no longer even can choose RGB color mode as the target, which is correct as much as no matter what you choose here, the color mode of the export file will be CMYK, which you can easily verify with the attached file that has pure RGB swatches defined. The point is: it seems that Affinity apps cannot produce PDF/X-3 or PDF/X-4 so that RGB definitions in native objects are retained, nor can they produce a mixed-mode PDF where document color definitions in RGB or CMYK for native objects are retained ("do not change" kind of export PDF). In addition, while non-PDF/X-based exports with RGB definitions are naturally possible, then all native colors will be in RGB, also the explicit CMYK definitions that are wanted to be kept (like e.g. official corporate colors with CMYK definitions, which to certain narrow extent could even be unreachable in (s)RGB color gamut). [Placed image content can be in mixed mode naturally, but that is a separate matter.] Additionally, as shown in this post, if you intend to work in RGB color mode, you need to be careful to not create a conflicting CMYK export, causing all CMYK definitions to be recalculated (as seemed to have happen when you exported your PSO Coated v3 in RGB color mode). Affinity apps are a kind of a PDF high school...you need to know much more than when working with Adobe apps, and when uncertain [and working with Adobe apps], you could just ask the printer to get step-by-step instructions. pdfx4_rgb_implied_psocoatedv3.afpub

What I mean here is that you are free to define your native objects in RGB, and when produced to digital documents (to RGB), these values will be retained for richer colors. I also mention that in Affinity environment native RGB definitions are not necessarily retained even if they are wanted to be retained (as by specs when exporting to PDF/X-3 or PDF/X-4, which is what happens if you export from InDesign). I am not sure that I understood what you mean here or how you produced the PDF you attached. You should be able to use CMYK definitions in an RGB document and then export to PDF/X-4, and these values will be retained. You just need to take care when exporting to PDF/X-4 that you specify CMYK as the export color space (since you cannot avoid Affinity apps from converting native colors to CMYK anyway), so if you leave it unspecified or used the document color space (document color mode being RGB), Affinity apps will use the factory default US Web Coated, which results in kinds of converted color values shown in your document. Your document however shows PSO Coated v3 so something else has happened in your export (could it be macOS related; I tested this now only on Windows and with v.2.0.3). EDIT: Perhaps you specified CMYK, and then also specified the profile? The profile must match your document CMYK target: ensure that it is what you want by switching to CMYK and seeing that it is PSO Coated v3. Then cancel and make sure that you specify CMYK AND document color profile, and you should be good. Attached is a PDF/X-4 document that shows pure C, M, Y and K and that has been created from an RGB Publisher document and that will show the underlying CMYK color profile as output intent when viewed in Adobe Acrobat Pro. cmyktest_pdfx4.pdf

Not really, you are describing very old workflows. A typical workflow would be placing RGB content (images), and also use RGB color definitions for native objects if desired (e.g. to guarantee wider gamut for digital production). When you work e.g. with InDesign, and choose Press document, you have dual color space and document target color profiles both for RGB and CMYK, and you will see placed content in full color gamut. You are by no means restricted to keep your initial profiles (which you will always by necessity have) but can either assign or convert as needed (and if converting, will have CMYK based swatch colors redefined without loosing current color assignments). So you are by no means "bound", even if every document necessarily has initial target color profiles defined. Basically the same applies in Affinity apps even if the "secondary color space" (CMYK if you work with an RGB document, and RGB if you work with a CMYK document) is not explicitly chosen as per document (but will be determined by defaults in the Preferences), with the important difference that CMYK mode will restrict your working color gamut. So in Affinity environment there is really a practical difference (even if you can freely switch from CMYK to RGB or vice versa, without causing color conversions, as long as you do not have "Pixel" layers: you typically do not, in Publisher). So if full color gamut is important to your workflows, you might consider working in RGB color mode (note though that you would not get what you want e.g. with spot colors and with Lab color mode; and if you intend to place 16-bit content, will get very large production files). There are also many caveats in Affinity apps when producing to multiple color spaces, one of them being handling of black (and gray), as Affinity apps do not have the kind of context [Black] that would produce K100 for CMYK color spaces and RGB 0,0,0 for RGB. And as mentioned, using CMYK targets with Soft Proof adjustments does not give as good simulation of the target color space as using the CMYK mode with the appropriate target, and their global use is convoluted. Press, PDF/X-3 and PDF/X-4 modes also do not retain native RGB color definitions, which may or may not be important in pure late binding workflows, so there are things to check (especially making sure that the underlying CMYK color profile is correct as it will be used for all these conversions) when trying to reproduce workflows used with different ecosystems. In Affinity apps PDF/X-based export modes also have serious limitations as regards placed PDF content, so if your production workflow is dependent on either, make sure that you will not have inadvertently rasterized content. Working in RGB color mode also has restrictions related to working with spot colors, e.g. the "K-only" button that can and needs to be applied to correctly apply spot inks and tints -- and regular coloring -- (making RGB and Grayscale images handled as true grayscales) would not be available in RGB color mode. You should also understand that you cannot assign CMYK color profiles at export time without causing conversion of all CMYK color values (also ones in placed content, unless the values are marked to be passed through, and most importantly, all native K blacks), so there is no late "keep values" option available to be used for making kind of cosmetic target changes to near ICCs at export time (even if you can switch to CMYK mode and then assign a different CMYK profile from the one assigned as the workspace default). Note too that in context of placed content the embedded CMYK profiles are not discarded so if there is a conflict with the (underlying) CMYK color profile, all color values will be converted accordingly (no matter how "late"). Despite of what is mentioned above, you could probably produce the kind of pure RGB workflow based "late binding" documents that will get converted only on RIP, but it won't be smooth as choices you need to make when exporting PDFs differ from ones you would make in other page layout apps, and documentation will not help you. So Adobe Acrobat Pro or another prepress tool will be needed. At least you should be sure to get a ripped proof.

It now does correctly simple transparencies ("opacities") also against whites (previously only against non-white), but still does not seem to resolve blend modes (only tested on Windows, though, but if memory serves, the support for blend modes is scheduled for a bit later version). But always well worth sending bug reports

Do you mean dissertations, documents with equations, etc? We have done dozens of them with InDesign, just using proper tools like MathType. Sources have been written in various ways, most often though using Word, but also with different kinds of LaTeX editing systems (typically on Linux). We normally just batch export equations from Word to EPS documents and then use scripts to make inline replacements in InDesign. No need for resizing and very little need for manual adjustments, and the layout can contain hundreds of equations. These are robust workflows and make it possible to create sophisticated technical publications without needing to use tools like FrameMaker, but getting proficient with workflows involving scientific text and miscellaneous technical elements naturally takes some time, and proper tools, and often also scripting skills. Publisher certainly is not a tool that I would dream to use for anything like this. No, but just copying from a PDF text elements like this: gives you this: a) When PDF is produced from Publisher, doing the kinds of silly tricks shown in this thread: _28417+6b23 b) When produced from InDesign, using just kerning: 81 + b3 _ 24762 c) From a PDF when using inline equations produced with MathType and used as inline EPS/PDF/WMF equations: 81 + b3 24762 More complex equations could not of course be copy pasted at all, but then again, you also would not get mixed character orders etc. And you can use search to successfully find character string sequences within fractions, equations etc.

I used the same trick. IMO it is really a convoluted "solution", and if the document needs to be distributed also digitally and copying is allowed, change of character sequence (especially in any scientific context, e.g. formulas, or just figures), could cause serious issues. I would personally use it in print-only context, and in isolated cases. If a document has lots of these, using a different kind of fraction notation, or a special font as shown above, would be the way to go (or if at all possible, using a different app).

What is your purpose of applying a Soft Proof adjustment? I ask this because if your document color space is CMYK and you already have the correct target CMYK profile applied, then what you see is the closest approximation Affinity apps can show of how the printed document will look like (it is like having permanent CMYK target soft proof turned on in Adobe apps, except that you would not be able to have a realistic preview of spot colors or even CMYK colors that are out of sRGB color gamut). If you have an RGB document, the CMYK profile that you pick in the Soft Proof adjustment gives a less accurate simulation. On the other hand, if your goal is to have a preview on how a CMYK document with RGB images linked/embedded or containing RGB color definitions will look like in (s)RGB or different CMYK color space would look like, then you could not use Soft Proof adjustment for this, and you would get best approximation by producing PDF documents in required color modes and viewing them with the correct simulation profile. If you do not have pixel layers in your Publisher document, you could also switch between different color modes (RGB and CMYK), or assign different color profiles (e.g. coated, uncoated and newspaper ICCs) within the same color mode, without causing change of color values (just causing change in visual appearance of colors). Personally I can see only one good use for Soft Proof adjustment within Affinity apps, and that would be when using an (s)RGB document and designing a color scheme that should have reasonably similar visual outlook both in RGB and CMYK (or at least being able to quickly see the difference), or when using any color document mode and wanting to preview the colors in grayscale (e.g. to see if there is enough contrast between color definitions, and adjust the values if needed).

Affinity apps, as you mentioned, restrict negative kerning to the bounding box of the preceding character, which is a serious flaw. So whether you can achieve what you aim at much depends on the font, but would still not work other than with single figures, if even then (as in the screenshot below where "1" is very narrow and underscore character long (a workaround would be scaling down width of the underscore character to make it the same width as the figures). InDesign does not have similar limitations: If a workaround requires separate constructions, it does not work well in situations where any kinds of edits need to be done affecting the text flow and/or formatting, so unless fraction formatting cannot be used, a kind of a special font shown above might be a possible solution.

It indeed can be that. My laptops are rather basic, and power duplication became sluggish when producing the kind of 0.8cm full width and height ellipse mesh, though I did not probably do duplication in the most effective way. I also noticed that trying to clone ellipses in Inkscape was very slow (and might make the app unresponsive) when trying to produce meshes with hundreds of ellipses both per row and column (in Inkscape max 500 copies is the limit for either). I ended up creating the mesh in CorelDRAW where the creation of the ellipse mesh was fast and effective and then imported this as an EPS file into Affinity Designer. Today I wrote a Python script that creates color or grayscale coloring bitmap with the width and height based on number of ellipses wanted per row and column, and then creates 30px (roughly 8mm at 96dpi) ellipses. In addition to coloring maps (that can be used as bitmap fills in Affinity apps in context of the Gradient Tool), the routine also saves the results both as PNGs and SVGs (vector format). The script was written in Python 3.10.5 and the SVG output requires installation of Cairo library. import numpy as np import math from PIL import Image, ImageDraw bcolor = True #bcolor = False # improve by allowing e.g. filename, cols, rows, circle diameter, # number of quantized colors, color/grayscale output and bg color as arguments # cropping method could also be added (this routine center crops) if bcolor: im = Image.open('bulldog.tif') # Can be many different formats. else: im = Image.open('bulldog.tif').convert('L') # Converts to grayscale w = im.width h = im.height cols = 46 rows = 63 ratio = cols/rows nw = w nh = h left = 0 right = w top = 0 bottom = h if w > h: #landscape nw = ratio * w nh = h left = (w - nw) / 2 right = left + nw else: nw = w nh = ratio * h top = (h - nh) / 2 bottom = top + nh #center crop im1 = im.crop((left, top, right, bottom)) #create quantized coloring ymap for ellipses newsize = (cols, rows) im1 = im1.resize(newsize) im2 = im1.quantize(16) if bcolor: im2 = im2.convert("RGB") else: im2 = im2.convert("L") grays = [] i = 0 for x in range(im2.width): for y in range(im2.height): thiscoord = x, y grays.append(im2.getpixel(thiscoord)) #print(i, x, y, grays[i]) i += 1 if bcolor: im2.save("bulldog_color.png") else: im2.save("bulldog_gray.png") diameter = round((80 / 254) * 96) #print(diameter) imgw = cols * diameter imgh = rows * diameter coords = [ (x, y) for x in range(0, imgw, diameter) for y in range(0, imgh, diameter) ] #print("Length of coords array", len(coords)) if bcolor: imgfinal = Image.new('RGB', size=(imgw, imgh)) else: imgfinal = Image.new('L', size=(imgw, imgh)) draw = ImageDraw.Draw(imgfinal) g = 0 for (x, y) in coords: draw.ellipse( [(x, y), (x + diameter, y + diameter)], fill=(grays[g]) ) g += 1 #print(g) #Optionally show in default photo app #im2.show() #imgfinal.show() if bcolor: imgfinal.save("bulldog_ellipses_color.png") else: imgfinal.save("bulldog_ellipses_gray.png") #now create vector image import cairo # creating a SVG surface # here geek is file name & 700, 700 is dimension if bcolor: strFile = "bulldog_ellipses_color.svg" else: strFile = "bulldog_ellipses_gray.svg" with cairo.SVGSurface(strFile, imgw, imgh) as surface: ctx = cairo.Context(surface) ctx.rectangle(0, 0, imgw, imgh) #background ctx.set_source_rgb(0, 0, 0) #fill with black ctx.fill() r = diameter/2 g = 0 for (x, y) in coords: ctx.arc(x + r, y + r, r, 0, 2*math.pi) #print(gr) if bcolor: red = grays[g][0]/255 green = grays[g][1]/255 blue = grays[g][2]/255 ctx.set_source_rgb(red, green, blue) else: gr = grays[g]/255 ctx.set_source_rgb(gr, gr, gr) ctx.fill() #could use this to add stroke on ellipses #context.set_line_width(0.04) #context.stroke() g += 1 The routine uses 16-color quantization in both color and grayscale mode. Source: bulldog.tif (cropped from the original by Felipe Cespedes | Pexels) bulldog_ellipses_color.svg bulldog_ellipses_gray.svg Python script would allow fairly easy addition of all kinds of variations and would be quite useful if it were enhanced with argument handling. It would be very effective in processing multiple images and whenever the ellipse mesh consists of as many elements as in the OP's example. But the Gradient Tool used with miniature coloring bitmaps as fills (which this Python routine saves, as well), using the Nearest quality option, is also quite effective and would allow easy experimenting. BTW. I did not quite get the idea of producing the kind of a dense ellipse mesh of a large image as in example of OP (considering the viewing distance which I assume to be several meters), so I continued to create examples using relatively larger ellipses that also demonstrate the effect of color reduction core clearly.

Yes, I was describing how the swatches of this .ASE palette are shown (wrapped in folder groups) when opened in Illustrator CS6, and how the individual swatches could then be extracted off the folders after having added all palette swatches from this separate palette into the app Swatches palette. After doing this tedious job, the extracted swatches could be exported to a new .ASE palette that does not contain groups. When the palette is opened in modern CC version (e.g. Photoshop 2023), which does support swatch groups, the group structure is not shown, but neither it is shown when opened in legacy PS CS6, which does not support groups), so I really cannot tell whether the folder (group) structure really exists in the .ASE palette, or if it is a matter of global color status that each of the colors in the palette has, incorrectly being read as a group flag in old Adobe Illustrator (and prohibiting proper reading of the palette in Affinity apps). It can of course be that the .ASE palette provided by this manufacturer are just incorrectly created.

When I opened the original palette in AI CS6, each swatch was in a separate folder (=group). When added to Swatches, folders would be copied along with swatches but the swatches could then be moved out of the groups and groups deleted. However when the palette was opened in Photoshops 2023, the groups were ignored and I could easily select just the swatches and export them to a new .ase file with no folders (groups). This might be a problem related to .ase file version. The later versions either can skip one-swatch groups, or old versions mistakenly read e.g. global color flag as a group flag. Anyway, it confuses Affinity import routine so that it fails to read any swatches from the file.

Another workaround would be using color (or swatch) opacity assignment for each object where halftone filter is applied.

The problem was that each color was placed in a separate folder (group) and it seems that the Affinity routine cannot read them. I imported them to Photoshop and exported the complete swatch selection to an .ase file without folder construction, and now they can be imported to Affinity apps. BenjaminMooreClassicColors_fixed.ase I suppose this is an ok thing to do because the palettes are distributed free of charge by the manufacturer: https://www.benjaminmoore.com/en-us/architects-designers/download-benjamin-moore-color-palettes

Hi @itsTYT, and welcome to the forums. The chances for improvement from Adobe created AI file (which must contain PDF stream to be editable at all in Affinity apps) are poor, since editability is severely deteriorated, but especially because clipping masks, if not already rasterized when interpreted in Affinity apps, will cause rasterization at export time. a) PDF created from AI CS6 using default export settings: b) PDF (at default export settings) created from an AI file opened in Affinity Designer: Note that this is not because the AI file would contain proprietary features: in this specific case, other apps like Xara Designer, can open the PDF stream without causing rasterizations (or can produce PDF exports where rasterizations would be grayscale masks that work similarly as smooth shading and alpha blending in an AI created PDF). As for producing smooth gradients in Affinity apps, I recall that there are posts that mention about problems like gradients showing dithering or banding even when using 16-bit channels, but if gradients get rasterized anyway, there is obviously not much point in changing the color depth. UPDATE: I just made some tests with gradients in Designer v2.03 (Windows version) and the 8-bit gradients seem to work as expected both in workspace and when exported to PDF (I disabled dithering of gradients in the Preferences but I suppose this is just a display setting anyway). But exporting to PNG (even 16-bit) produced badly dithered gradients, no matter if the source document is 8-bit or 16-bit RGB. The same PNGs produced from AI stay smooth.

Ok, I see. Yes, the easiest way would probably then just create exactly the width and height of image (in pixels) as there are ellipses in a row and in a column, and if the bitmap fill is used, then choose "Nearest" as the quality setting so that if the image needs to be scaled (as below, since ellipses that I use are much larger than those in the examples of OP), the image is not blurred: EDIT: So the document is 10488 x 14202px (369 x 500cm at 72dpi) but the image is just 13K (grayscale TIFF).

I am not sure if I understood your goal properly, but I have created a couple of posts earlier showing how Bitmap fill (in context of the Gradient Tool) can be used to easily create e.g. jigsaw puzzles, and this workflow might be useful also in your job. [The same method can be used in all three Affinity apps and both in versions 1 and 2 even if the tool names and behavior differ a bit.] EllipseMesh.mp4 I also added the required adjustments to make the image a 16-graytone version in one click. Note how version 2 apps now allow dragging images as bitmap fills directly from the Stock panel, Assets or file system. In the video the bulldog photo is a portrait image so it automatically fits in the ellipse mesh without needing adjustments, but you can use the Gradient Tool controls to resize the image as needed. Note too, in the end of the video, how separating the merged Curves object also separates the image fills. You could use the Export Persona to export all separate pieces in one go to separate files. EDIT: Using an adjustment layer to make the image grayscale will rasterize the ellpse mesh at export time so if you want to keep the ellipses as vectors, you need to create a separate grayscale image (you can use the same method and then rasterize the image and save it e.g. as a JPEG image). You would then fetch the grayscale version bitmap using the Bitmap option of the Gradient Tool.

This was the primary reason I got tired of rewriting code for my InDesign plug-ins. Location-based coding used to change so much version by version (allowing all kinds of crazy variations) so that speed of development at the time simply just exceeded my capabilities of staying tuned! Adobe documentation has always been top-notch and implementation examples informative, but this was just too much, and as scripting capabilities improved, I rewrote all my plug-ins as simple scripts (that keep on working disregarding the version, or only require some minor changes). If Serif ever reaches anything even remotely working like this in script-based object control, they will have a serious second chance!