lacerto

This is an off-topic post considering that OP wished to produce same size “pixel” ellipses in a grid using 16 or so different gray shades to depict an arbitrary raster image exposed by the ellipse mesh serving as a clipping mask, effective production of which in Affinity apps @loukash showed above. In this scenario the quantization (16 graytones out of full grayscale or color image) could then be produced e.g. in ways shown above by @Lisbon. But I wanted to add a few words to show that raster and vector formats are not necessarily opposing production methods (even considering versatility and editability), and that hybrid production is not anything new. The old school method to create something similar would be producing a halftone, in which case the maximum number of gray levels would (and can intentionally) be determined by a ratio of image DPI to be halftoned and screen density (LPI) used for halftoning (denser screen rendering more details but less gray tones). Photoshop allows doing simple (but true and accurate monochrome) halftoning using six different shapes (including ellipse) and a user-defined frequency and angle. These kinds of halftones can then also be colored and blended and used combined with other graphic elements (both raster and vector format) to achieve different kinds of artistic effects. Many vector apps (already FreeHand, but to mention two that still support this, Xara Designer and CorelDRAW) that feature PostScript printer control allow production of true PS file separations with custom screen and halftone pattern definitions [the format of input graphic could be anything, even if in this context a grayscale raster image]. Opening PS print files with e.g. GIMP as monochromes would allow saving PS halftones in common raster formats to be used for diverse aesthetic purposes. Note: Image By Felipe Cespedes | Pexels Additionally, many other apps, like Illustrator and Affinity apps (in Photo and in Publisher via Photo Persona), allow creating halftone effects that simulate true halftones, as shown above by @h_d. Windows users of Affinity apps can also use G’MIC plug-in’s many halftone effects. Inkscape can additionally produce vector halftones on base of user-defined or created shapes, which are easy to create and manipulate afterwards (as clone objects) and that can also be conveniently imported to be used in Affinity apps via Clipboard. Vector-format halftones could also be used as true halftones in screen printing, though when used in context of large surfaces, the file sizes can become big and there is no practical benefit of using vector instead of raster halftones. olddog_newtricks_v1.afdesign There are also dedicated apps like Vectoraster (macOS only) that allow creating vector halftones with all imaginable parameters and then exporting them as PDF, SVG and EPS formats (in addition to common raster formats). Olddog_newtricks_5mm.pdf Olddog_newtricks_0.8mm.pdf (Note how the size reflects the density and complexity of pure vector halftones, so comparing to monochromes, the common misconception of vector graphics as something math-related and therefore compact can easily be demonstrated here.) Vector and raster formats have always gone hand in hand, which is more or less self-evident as both formats must typically be rendered to raster devices (translated to pre-defined picture element grid), whether printed or shown on screen. Which method to use much depends on tools that are available and workflows that each user is accustomed to use, but learning about new, alternative and more effective ways of achieving same (or similar) results is of course always useful.

Note that EPS is no longer supported in current Word versions. I tested this and noticed that having a 96DPI Designer RGB document and copy pasting as SVG (the appropriate Clipboard option needs to be checked in Edit > Preferences > General) works pretty well at least on Windows and up-to-date Office-365 version of Word. Exporting to WMF and converting text to curves works also fine but placed graphic needs to be manually resized. Leaving text as text left artifacts. EMF exports would import fine, but would fail when subsequently exporting to PDF. I did not test this on macOS, but as WMF is not available there, would imagine that SVG is the best vector option there. However, on macOS PDF format might also be supported, also via Clipboard (on Windows Word I could not make PDF imports work properly, perhaps it requires some extra modules installed if it is supported, at all). VectorsForWord_v01.afdesign VectorsForWord.afdesign (requires v2) vectors.docx vectors.pdf UPDATE: I now tested this on macOS, and there PDF format works very well both when pasted via Clipboard and when placing Affinity Designer created PDFs in Word. The PDFs are also placed in their correct sizes in Word documents and export without problems. On the other hand, it seems SVG is not a supported Clipboard format between Affinity apps and Word. UPDATE2: Exporting to PDF and placing them in Word on Windows works fine, too, even if it seems that objects need to be resized (it appears that they are placed at 300 dpi resolution no matter what the nominal resolution used at export is). In Word, the PDFs need to be placed by using Insert > Object (under Text group) > Create from File (instead of placing a picture). Word can also place an interpreted and editable PDF if a PDF is placed as Insert > Object > Text from file, but there are probably many kinds of errors in interpretation. UPDATE3: PDFs placed in a Windows Word document are actually low-res rasterizations! It is a shame, and totally absurd that Microsoft has not implemented similar support for PDFs as there exists on macOS versions of Office apps! So in a nutshell: on macOS, vectors can be exported to Word in PDF format, and can be used both via Clipboard and as placed graphic [to be passed through]; on Windows, vectors can be exported in WMF format (text as curves) and placed in a Word document (resizing typically needed), but not transferred via Clipboard (this is not supported by Affinity apps); or: copy pasted in SVG format when enabling the appropriate option in the Preferences. But exporting to SVG files and then placing in Word has several flaws and does probably only work with very simple drawings.

The first 26 of Affinity Photo blend modes and their typical uses are described in a nutshell in this Photoshop video: The remaining six are discussed in the PDF notes linked above by James Ritson. This 52-page PDF is pretty good compilation that also gives information on ways these effects can be used. The documentation of Affinity apps could certainly be more informative, but the blend modes are fairly similar in different apps and their basic operation is well documented in free sources like ones mentioned in this thread. It is obviously also quite a demanding task to write a comprehensive yet easily understandable description of blend modes (without copying much of what has already been mentioned in other sources).

One possibility would be creating list as Word tables (e.g. in Word or Libre Office) and then sort the columns in descending order after having been flown in Publisher: But here the usual table resrictions would apply (no long tables, and splitting a table would require manual editing).

I really cannot see the point of reporting this as a bug [assuming that the bug is not hiding the image conversion commands in macOS versions of Designer and Photo, rather than not making these commands available in Windows versions]! Removing a useful and well-working feature (basically a key feature, considering how essential the difference between image and pixel layer is in all Affinity apps) as a bug would be counter-intuitive, and highly ironical: certainly easier than fixing real bugs and turning them to features! I can understand e.g. text frame related limitations in context of revenue generation model (as teasers to get more features by purchasing a sister app), and can also understand to some extent hiding specific features or controls to avoid clutter, but personally I'd prefer a model where purchasing more would simply just make the teaser features like this and e.g. Live filters (within Layers panel) available across all apps, directly and not just via Personas, especially if all that it takes is to not hide a button in a panel, or a command in a context menu.

Yes, precisely. My question was, why not (other than in Publisher, where it has existed for some time, though I am not saying that from the first version of Publisher), and not in versions 2, either. In the quoted context, I was referring specifically to macOS versions.

Perhaps "always" was too much to say as I have not been here as long as you two. Or maybe it depends on the OS version as I think you both use pretty old macOS versions (or did you just fail to scroll the menu low enough)? Or who knows, maybe it is related to having both v1 and v2 installed on the same computer (at least the menu commands appear even if v2 version apps are not concurrently running). Nevertheless, the point is, why, once again, a completely unnecessary workaround, and why aren't the direct menu commands implemented on Windows versions of Designer and Photo. Image layer has other uses, too, like direct coloring; I am not saying that there is no workaround, just wondering why they are so eagerly defended and more direct methods seen as some kind of unnecessary newbie clutter?

Yes, that would be ideal. There is more specific Direct2D API related documentation available but it is very technical. I would try to learn more about the blend modes reading descriptions related to Photoshop blend modes. While the effects are not necessarily identical they nevertheless overlap with ones in Affinity apps so the descriptions may useful when learning about possible or typical use cases of specific blend modes. E.g. sites like this: https://www.bwillcreative.com/blending-modes-in-photoshop-explained/

At least on Windows, these effects look pretty much standard built-in Direct2D blend modes. https://learn.microsoft.com/en-us/windows/win32/direct2d/blend The Photoshop blend modes [as far as they overlap] are probably also similar if not identical: https://photoshoptrainingchannel.com/blending-modes-explained/

Yes, a totally unnecessary limitation, requiring workarounds like editing in (read: purchasing of) Publisher, or exporting a selection and then placing it as an image, grouping etc., especially as macOS users have always been able to use a direct menu command in all three apps. I hope there is a good explanation (as it is definitely not related to "differences" in OSs).

It seems that very good questions In CorelDRAW, I got what I to some degree expected to get: ...so topmost the two linear gradients with stop values from RGB 0, 0, 0 to RGB 255, 255, 255 in two different angles, the rightmost having an orange background. Then in the middle these shapes placed above each other, the topmost shapes having Logical AND blend mode applied. The leftmost bottom shape has Normal blend mode (orange not affecting), and the rightmost bottom shape has AND blend mode. But the ANDed gradients are what I basically expected. The bottommost shape shows the Multiply blend mode. But VectorStyler ANDs the gradients quite differently (I made sure that RGB values are used in both apps). : ...so the diagonal ANDed gradients in the bottom left would show very different result (and somewhat similar as in your example) from that created by Corel. If the bottom shape has AND mode applied, as well, the rightmost triangle quarter most of the composite would have transparency be transparent and show underlying colors, while the CorelDRAW created shapes would show slight orange stripe showing through only on the left edge of the shapes. So, while the principle of Boolean blend modes is clear enough, I have no clue which one of the apps blends correctly in complex situations, or if it is just a matter of interpretation. But there does not seem to be much predictability, so using logical blend modes seems to be much more guess work and experimentation than using other blend modes. Especially as there are additionally issues with production to PDF (or more generally retaining the vector format) and CMYK color space. UPDATE: I later double-checked the above created blends in both apps, and noticed that I had made errors in the Corel versions: when re-created, the blends were similar as ones created in VectorStyler. But the top right diagonal ANDed blend (on orange background) stays essentially different in these apps. I am still not convinced that the differences between the apps (or different sessions within the same app) could not just be rendering anomalies, e.g., considering the method gradients are actually created e.g. diagonal gradients as separate lines with varying gray shades vs. a higher level raster operation, rather than my own blunders.

I am not sure if I understood what you asked, but the difference between Multiply and Logical AND was described in my post above. The other logical blends are applied similarly by Boolean logic. If you apply Multiply and Logical AND on diagonal gradients (RGB color mode), you get the following: The kind of stepwise seemingly random and abrupt grades that are common in blends achieved with logical blends applied on gradients, is, I guess, one of the reasons these blend modes might be used, but as mentioned, they were at times used frequently e.g. to create masks and screens programmatically. All blend modes are basically transparencies; adding opacity basically just adds one more variable to the calculations.

Depending on how the table-like data would subsequently be used in Publisher, I would probably first try data-merge with image paths, but otherwise importing a tab-separated text flow from a Word document with placed images might be worth an effort. Table grids, if they are needed, could be placed on a master page using e.g. a true table. On Windows at least, an Excel table with images can be copy pasted into Word and then converted to tab-separated text flow, including images, like this: tab_sep_images.docx This could then be formatted and auto-flown in Publisher:

Thanks, I missed that. VectorStyler, too, seems to have similar issues exporting the logical blends to PDF. It seems e.g. that AND gets always exported as Multiply, both when exporting to RGB and CMYK mode PDFs, and when copy pasting via Clipboard from VS to Corel (color definitions and blend modes etc. are retained, but And just gets converted to Multiply). Direct raster exports however honor the logical blend values. One possible scenario for experimenting with logical blend modes and retaining vector format would be doing the blending in VectorStyler, making a copy of the blend group, applying Boolean Division, and then copy pasting the blend color values using a color picker to the divided (flattened) vector shapes (the blended color values are unfortunately lost when dividing), and finally copy pasting to Affinity apps.

No, they do not. Bitwise SRCAND mode is one of the basic operations of the BitBlt function in Windows API, and typically used in the process of creating transparency masks in sprite animation, and I am sure that similar Boolean operations exist for other operating systems. Read this Wikipedia article to get a grip on why and how they are (or were, before proper alpha transparency) used: https://en.wikipedia.org/wiki/Bit_blit In addition to Corel software, you can use apps like GIMP and especially G'MIC plugin to apply these kinds of experimental blend modes on image layers: a) Source (layers in GIMP) -- afterwards, result of G'MIC procedure already available in Layer #3: b) Blending Layer and Layer #1 using G'MIC Blend (Standard): While G'MIC plug-in does work with Windows versions of Affinity apps, this specific filter, however, does not, because it assumes layer-based operations, and with Affinity apps, only flattened pixel based layers can be used. So if you wish to experiment with Boolean blend modes, and do not have Corel apps anymore, exporting to PSD with layers, and then opening them in GIMP, and applying G'MIC blend modes might be one possible route worth an effort.

I had a brief look on Corel Logical AND blend mode, and basically it seems to produce identical blend operation as Multiply, though descriptions are different. The differences come obvious when using complex color transitions like gradients. Blend modes are always problematic as far as the app cannot force blending color space and preview it expectedly (and only a few apps can). E.g., results can be significantly different depending on whether colors are (or even can) be calculated in RGB or CMYK color space. In addition, the active color profile is clearly a significant player since blends might be rendered in display color gamut but exported to narrower color space. How blended colors look on screen might be significantly different from what is ultimately produced. Vector-based blends cannot necessarily even be produced without rasterization and transparency flattening (done on canvas or at export time), and if such blend modes are printed with live transparencies, one cannot be certain about results (or the method that will actually be used when flattening the blended colors). Here is a simplified comparison of basic C, M and Y colors in RGB values multiply blended in sRGB, sRGB imported to Adobe RGB and changing the blending color space from RGB to CMYK, using InDesign: And here is a comparison of using the same color definitions in CorelDRAW 2022 RGB primary color space (with sRGB as document color profile) using AND (top row) and Multiply (bottom row) transparency blending modes. As can be seen, with simple solid colors [full channel values], Logical AND produces the same results as Multiply (note how Corel blends the colors using the display color gamut rather than the document color profile, which was sRGB; the difference is clear especially in blue --blend of full cyan and magenta -- and the center piece which would basically be black when using full channel values), but when blending gradients (conical one in this case). there are differences the reason of which is not obvious (well, not at least to me) and results of which are not predictable, and if producible at all, then in RGB color space. But when I tried this with other similar blends, I failed to produce blends created with AND blend mode even when exporting to pure raster formats, and even when not restricting the output to sRGB. [The principle of applying Boolean AND, OR and XOR on binary representations of channel values is clear, and differs from Multiply, but why the results are typically kinds of gradated shades of multiplied blends is odd.] Anyway, here is how the blends viewed above in Corel workspace show when exported to sRGB raster formats: Here is how they show when exported to RGB PDF supporting live transparencies (left), and to CMYK, transparencies flattened and rasterized: blendmodes_rgb.pdf blendmodes_cmyk_flattened.pdf Based on this, I would say that using custom blend modes might be useful for experimenting when used strictly in RGB color mode (and rasterizing the output), but to get more predictable results, it is wise to settle with “standard” blend modes.

The reason for this behavior is -- as was already shown by anto above -- that you are using baseline grid (at 12 pts) to align the text lines. Showing the grid helps understand the problem, so here is another video demonstrating the issue. Using a baseline grid means that when you increase the amount of leading so that it exceeds the (multiple of) baseline, the leading will be increased to next multiple of baseline, so in this case to 24 pts. To avoid the problem, you can turn off baseline alignment as per paragraph [or as per text frame, as shown in anto's clip], or turn off document baseline grid (which would then affect all paragraphs, which would thereafter use the true leading settings set for the paragraphs (in this case 14,4 pts, or 120% of font size, according to the default paragraph leading; or the overridden leading, specified for a character range, by using the leading setting of the Character panel). baseline_grid.mp4 Note that text frames and tables can additionally be aligned to a separately set up baseline grid, independently from the baseline grid set for the document, and which can also be defined to be ignored as per frame or table.

Thanks for pointing this out. I did not know about different kinds of 2D codes (and I suppose the only kinds I have ever generated have been QR codes). The inventor of QR has this info page (do not know how objective information it provides): https://www.denso-wave.com/en/adcd/fundamental/2dcode/2dcode/ As for offline tools, at least Inkscape can produce Datamatrix codes (which I suppose the specific 2D code of this post was)...

This SVG file is a good demonstration of problems related to transferability of advanced vector graphics features like fills and outlines containing transparent gradients. While Inkscape does a good job in exporting these features to a PDF file (attached below), the original SVG file contains Inkscape specialties that do not transfer perfectly to other vector graphics apps like Affinity Designer, CorelDRAW or Illustrator (very old CS6 tested only, though), even when exporting from Inkscape using plain SVG format. So instead of using the native or simplified SVG format, it is sometimes better to export and import using the PDF format (or sometimes possibly even EPS): kinefx-transformfrompath_cropped.pdf Partially the problems are related to another app (like CorelDRAW) not supporting natively a specific feature (like gradients or “fountain fills” as they are called in CorelDRAW, in object outlines [strokes in Affinity apps]), and partially to complexity related to transferring a feature that has been converted to PDF back to native objects trying to retain all aspects and attributes of the original objects. As for this specific image, Xara Designer seems to import original features otherwise most accurately but has odd polygonal artifacts in imported circles with gradient transparency in strokes. Direct copy paste from Inkscape to Affinity Designer via Clipboard works also well but has inaccuracies in some details. So this specific design could be transferred to fully editable vector design, retaining most if not all properties of the original design, by combining different elements rendered in different apps (or converting individual elements to native elements and reapplying equivalent formatting parameters), but it seems that there is no other app that could perfectly open the Inkscape created SVG (neither in “Inkscape SVG”, “Plain SVG” or PDF format). This file also shows why native implementations are required: they allow advanced features, more effectively and intuitively operating control over complex features, etc. , even when not extending the standard. While they can be successfully produced in vector formats like PDF, editability can be transferred normally only partially. This also explains why there are such modifications as “Inkscape SVG”, “Photoshop EPS”, or “Illustrator EPS”, “Xara EPS”, “FreeHand EPS”, etc., indicated by the following list of import formats of Xara Designer 19 (note how many extended EPS formats are very old and version specific, so one may well ask how "standardized" EPS has ever been): Anyway, extended EPS formats are not necessarily expressions of evil mind and aspiration to monopoly 😉

Yes, it seems that only partial fixes. Version 2.0.3 fixed the specific case related to Boolean Add shown in this topic; let's hope the next release fixes the problem with Boolean Subtract which appears to be related because it is one where version 1 apps worked well (no matter if the curves were a "curves" or a "compound" object). Meanwhile, "Boolean Co-operations" still seem to be a valid (and only) work around. Let's hope fixing one case does not result in breaking another as these issues somehow seem to be regressions related to rewriting the Boolean operations. E.g., divisions seem to work much better now, not leaving superfluous nodes and artifacts, but then these kinds of macro operations working well in version 1 have become an issue in version 2.

The error seems to be fixed in versions 2.0.3 (though I have not tested all operations extensively); but there are improvements.

Kenmcd can give details about situation with variable fonts, but I think that as far as co-operation goes, it is not realistic to expect to be able to exchange editable data between Adobe and Affinity apps. The reason for inadequate exchange of information between AI and Designer in this specific case was not so much because of Affinity apps do not support variable fonts, but more because there is inadequate information to exchange editable data, including variable fonts -- even if they were fully supported in Affinity apps. Only parts that have been saved from within AI as PDF stream can be read in Affinity apps (or vice versa, saved in Affinity apps and opened in AI) and this excludes most of native features, and whatever can be read is editable only with restrictions. This applies also other apps, since AI file format is proprietary and not publicly documented. Some apps have slightly more extensive AI support, partly by mutual agreement of file format exchange (e.g. between Adobe and Corel), partly because efforts (more or less inadequate) to interpret (de-engineer) native AI file format (and also write it back, to some extent). But at least I do not know any non-Adobe app that can read and write AI file format, even close to feature level of current CC versions.

Here's the same file for version 1. StarsFromXara_v01.afdesign Xara Designer (or still more affordable Xara Photo & Graphic Designer) is such software, but it only runs on Windows. And it has its limits. In practice there is no other way than using Illustrator, to avoid constant frustration.

This is mostly true. Though you can try to use apps like Inkscape (free), VectorStyler, Xara Designer and CorelDRAW, that can do a bit more than Affinity apps trying to interpret proprietary Adobe Illustrator specific features that can be saved not only in (Illustrator) EPS files but also in PDFs saved by using Illustrator (when opting to save by retaining Illustrator editable features). Affinity apps also do not support the complete PDF and EPS feature sets so sometimes parts that get rasterized when opened in Affinity apps are actually not proprietary Adobe features, at all, and can be opened in some other apps as editable features. Sometimes it is also difficult if not impossible to export features from the other tools further in formats (mainly PDF) that are editable in Affinity apps. But e.g. when I tried with the other of the above attached star files, I could open it in Xara and then save from there in PDF format to be successfully opened in Designer and then saved as Designer file, and it seems to work quite well. Then again, I could not do the same for the other file (it failed to open properly already in Xara Designer). StarsFromXara.afdesign

Please find attached a fixed version of your Designer file. The three images that you had in the job were CMYK files with four-color blacks. They might initially have been 1-bit monochromes, which Affinity apps do not support, and if opened or placed in Affinity apps, will be interpreted as RGB images. When converted to CMYK, they will become four-color blacks (according to conversion based on underlying profiles). In a CMYK document placed RGB and CMYK images can be forced to be handled as grayscale images (K-Only button on the toolbar, when image objects are selected). When doing so, pure RGB 0, 0, 0 images will become Grayscale 100% (or G0 or B0, as they are labelled in Affinity apps). True grayscale images will have the K-Only button turned on when these kinds of images are placed in a CMYK document, which forces them to be processed as grayscale images at export (internally these files are handled as RGB files). I converted these three images to grayscale images. I left the QR code as 22 x 22px. It stays that way, when exported, but will just be resampled when processed, duplicating pixel values without antialiasing. If you open a PDF with this kind of an image, it will be antialiased when opened in Affinity Photo (but if you open and interpret a file that needs to be rasterized/rendered in e.g. Photoshop, you can choose to turn off antialiasing). If you view the PDF in something like Adobe Acrobat Pro, you should see the image sharp and non-antialiased. The file exports exactly similarly on Windows and macOS. In the attached PDF (exported on Windows), all black values are now either DeviceGray values or DeviceCMYK values with mere K values. Why the problem appeared to become "fixed" by rasterizing is that when you rasterize an image layer on canvas, the rasterization will be done at the document resolution (which was set to 1200dpi in this document), and accordingly the low-res 22 x 22px image will be upsampled (using bilinear algorithm, which is not optimal when upsampling this kind of image, as it should be done using the nearest neighbor algorithm). This, indeed, is not necessary, so you can leave upsampling to RIP. (Why the QR Code appears so pixelated in your screenshot is probably caused by viewing an antialiased 22 x 22px image at close range (antialiasing done by the viewer app); had you printed the original exported image, you would have had nearest neighbor upsampled four-color blacks which would probably have worked without problems, but less than ideally as these kinds of images should typically use black ink only.) sample_fixed.afdesign sample_fixed.pdf