lacerto

Subtract as a compound operation to get it non-destructive. Erase always rasterizes on export. test_compound.afdesign test_compound.pdf

You can also use the Resource Manager to select in one go all child images of selected picture frames and then delete the images, as shown in the clip below: unpopulate_selected.mp4 Note that picture frames do not need to be expanded, I only expand them here to show that "Locate in document" function basically switches current selection of picture frames (made e.g. with the mouse) to selection of images within picture frames.

I am not sure if I understood correctly, but if you select images within picture frames from within the Layers panel, you can unpopulate the parent picture frames simply by pressing the Del key (or choosing Delete from the context menu of the Layers panel). If you only have images within picture frames, you could first select all images in the document using Select > Select Object > Images and pressing the Del key to unpopulate all picture frames in the document.

Ok, thanks, did not check but wrongly just assumed.

Just use some negative tracking (or kern character pairs that are problematic):

Hello @Josh9856, and welcome to the forums. This is a common issue in graphic design apps and related to antialiasing. Some apps can deal with the issue in context of export by automatically overlapping inner and outer parts of these kinds of objects so that the gap is covered. Affinity apps unfortunately cannot do this so to avoid this, some manual work is required. Most often these issues would not show on printed design.

Who knows if this is a regression or an intended change not just been implemented in full? IMO Publisher and Designer kinds of apps should behave differently than fundamentally raster-based apps like Photo, but Serif clearly thinks differently.

Frustratingly, this continues to be an issue also in 2.0.4 Windows versions (I have not been able to reproduce these kinds of problems with macOS versions, not with 2.03, nor with 2.0.4). It would be interesting to learn why Windows versions keep on having problems with basic Boolean operations? V2 apps obviously use different code than v 1 apps, but is this a library issue or something related to proprietary code not just yet being "in synch" between the OS versions?

IMO the primary role that DPI document setting in Publisher (and Designer) had in 1.x versions of Affinity apps was setting the resolution for objects that will be rasterized on canvas (similarly as the "Raster effects" DPI setting in Illustrator). The setting would also determine the default for resolution to be used when needing to rasterize objects when exporting (this can be overridden at export time e.g. in context of PDF export). IMO v2 apps (Publisher and Designer) behave incorrectly when resizing physical dimensions of the document when document DPI is changed. This did not happen with v.1 versions (even when the document unit was px), and I cannot see why this has changed. Personally I see this as an indication of fundamental problems in trying to keep alive the idea of one global workspace and document object model. This seems to be an eternal source of confusion both for developers and users alike.

I agree, especially when having K-only button available in CMYK mode. Rectangle shapes stay non-antialiased on export no matter how resized, and even downsampling issues [or issues related to upscaling of an antialiased rounded shape like one below] can be avoided should it be needed to avoid blurred (antialiased) edges: monochrome_simulation_v01.afpub monochrome_simulation_v01.pdf Yes, well done, even if I have not so far myself found much use for the feature, perhaps for some effects: Finally true vector brushes 😆 This one is pretty high on my long list of convoluted work arounds: Raster based "Vector brushes" accessed via Designer Persona, rasterized and vectorised in Publisher... A roundtrip via Photoshop's Create workpath on the Paths panel with customizable Tolerance settings (below 0.5, 2 and 6px) is not bad, either, and would allow some interesting QRCodes:

Works on my Windows 11 Pro and Affinity apps v1 and v2 (including Designer), similarly as when using e.g. VectorStyler. The numbers must of course be typed by using the numeric keypad, but this does not seem to be the issue since this works for OP with other apps. NumPad + 7 works, too (though I do not know if this is somehow OS specific).

You can use Excel sheet as data source but need to use TEXT() function to format data as text (note below that formatting notation is regional, so below the arguments are separated using a semicolon, the decimal is given with a comma and hour with a "t" (for "tunti", Finnish for hour)). English notation would be TEXT(A2, "h:mm:ss.000"). TIME() function would return rounded seconds, but e.g. NOW() returns an unrounded value. If exact values are wanted to be returned with TIME(), you would enter something like =TIME(0;12;32)+0,24/24/60/60., or when using English regional settings, =TIME(0,12,32)+0.24/24/24/60)

You're welcome! Yes, any fonts that have OpenType fractions can be used with RegEx (or even without RegEx, using find+replace multiple times for different fraction scenarios) and using character formatting to apply fraction formatting (optionally made to character style). Having additionally the context-sensitive trigger, as in e.g. Helvetica Now and Meta would allow applying formatting selectively (only in selected range or columns), and also in situations where RegEx is not available (e.g. if Publisher is not installed, or when working in apps that do not support RegEx, Find and Replace, or applying formats automatically on found instances; e.g. Designer alone would not support these operations, but still does support OpenType features). As far as I know fonts like Minion Pro, Myriad Pro and Arial (the last mentioned it seems that only on Windows), or Helvetica species other than Helvetica Now, do not support contextual OpenType fractions so fraction formatting would be applied also on the integer part if it is selected. Needing to perform find and replace selectively (confirming found instances one by one) would make formatting quite ineffective so there might be point in getting a font that has fraction formatting as a contextual feature. As long as Affinity Publisher does not allow limiting the search to a specific or selected range, such font feature would be very useful. The clip below demonstrates a situation where fraction formatting cannot be applied globally (because that would also change "fraction" in dates and font/leading markings), and where formatting is then applied selectively (column-wise) first to Minion Pro (does not work because integer part is formatted as well), and then on two fonts that support contextual fractions: Helvetica Now, and Meta Serif Pro. contextual_fractions.mp4

This illustrates a situation that you might have: a) Internal macOS version (part of TrueType collection): b) Legacy Type 1 font, this one is from Adobe FontFolio 8 (which still can be installed on most recent macOS): If I try to install this font using Font Book, it warns about a duplicate being in process of installation. As you can see both fonts use identical family name and style group with identical sub style. Many apps only read this information and accordingly would get confused font menus when enumerating available fonts. Adobe apps might have been able to handle these conflicts without problems because they read those additional names to identify and group the fonts correctly. But as this is a Type 1 font, modern Adobe apps no longer support it, and Affinity apps are helpless in differentiating these fonts. The easiest method would be simply disabling the conflicting styles of the non-Apple version using FontBook. It would be possible to convert the Type1 versions and use non-conflicting names, but this would be a pretty big job (and besides, I assume that against the original license). As Type 1 fonts are deprecated and more and more apps (and e.g mobile OSs) stop supporting them, it might be a good idea to get a new version of Helvetica Neue. Unless you want to have exactly the same design, I would recommend getting Helvetica Now from Monotype, as it is a superb font with lots of fine features. The MyFonts version is from Linotype and is basically an up-to-date OpenType version of the old Type1 font, but the package you referred only contains 16 styles while the original FontFolio 8 or 9 version contains 51 styles so there is a good chance that you will not get full support for opening all your old documents with the replaced versions, despite of identical design. In any case you would need to map the "missing" fonts of the old documents with old versions of Helvetica Neue to the new fonts with slightly different names. EDIT: The Apple built-in OpenType TrueType flavor contains 14 styles. It you do not need all styles of your current non-Apple version of Helvetica Neue, just using the Apple versions (instead of purchasing a new Linotronic package only containing 2 styles more) would probably be the most practical solution.

You can PM me to tell some details of this other font. Depending on a bit on details, it might be an easy task to prepare you a version that works fine on you current system, without causing conflicts with the internal macOS version. R/I/B/BI refers to Windows kind of four-style menu names which need to be consistently created to make super families like Helvetica Neue work. I think that Affinity apps and apps generally on macOS basically ignore this system and have other means that help grouping fonts. But name conflicts occur all the same, but for other reasons than confusion of four-style menu names. As I have the macOS versions installed, I could have a peek on your font and see what it takes to make a fix.

I think that it is worth investing in a modern OpenType like Helvetica Now, which comes with contextual fractions, and also some intellect as for excluding certain specific glyphs from ones that autotrigger inserting OpenType fraction formatting. This font family has also multiple styles so it works well whenever grotesque type is needed. There are probably serif-style fonts available allowing similar functionality but e.g. Minion Pro [at least the version I have] would also apply integer figures separated by zero-width space or non-breaking dash with fraction formatting, so it could not be applied en masse, similarly as on the clip below, but would require use of the kind of RegEx formatting shown in the video. Anyway, if there is need to separate an integer figure from the fraction part, this font would allow using e.g. zero-width space or non-breaking dash [or another similar dash] as a separator, and both could be entered while typing by making these glyphs available with a keyboard shortcut. So when using this method, all fractions can be autoformatted both when applying OpenType fraction formatting afterwards (e.g. to whole table), and while typing. If necessary, existing regular dashes or spaces could be find-replaced with versions that will not auto-format to fractions. fractions_bestmethod.mp4 Note that you should disable the auto-correction feature of the Preferences, that automatically replaces entries like 1/2 or 1/4 with fractional codepoints. OpenType fractions are a completely separate thing so this automatic feature should be disabled when using them. I am not sure if Google fonts nowadays comes with anything as smart as Helvetica Now -- if anyone knows, please inform! UPDATE: Meta Serif Pro would be an example of a serif font that has similar OT fraction feature as Helvetica Now. Probably many other FF fonts has, as well (e.g. Signa Serif and Signa Slab Serif do), of all versions. Helvetica Now supports both proportional and tabular figures (including fractions), all Meta fonts support additionally OldStyle and Lining versions. Meta fonts are included in Adobe Fonts.

Yes, the both Helvetica Neue versions on your computer seem to have same or close to same family names (perhaps a space character is not enough to separate the names, unless the app can make a difference when enumerating the fonts). Font editors typically use the FamilyName as a base, and then other parameters to build several other names to create a unique set of font names to avoid name conflicts. Since e.g. PostScript name seems to be built based on Family name (spaces removed and style name appended by other parameters), it may be that at least certain fonts that have close to identical family names, end up having fully identical secondary names (like PostScript name). If an app enumerates fonts based e.g. on PostScript body (the first part of the name), name conflicts would happen and all kinds of issues related to this problem. I do not think that it is possible to resolve the issue unless the family name of one of the conflicting font is changed and sub names thereafter rebuilt. As mentioned, the problem is often app-specific, depending on whether an app uses multiple name fields to deduce how individual fonts should be grouped and identified. If name editing is not an option, you could try if just removing the exactly conflicting fonts from the non-Apple family would make it possible to use all sub styles of these fonts, even if from mixed families. The Font Book is probably good enough tool to do this task, as it allows just deactivating conflicting fonts without needing to uninstall them.

Yes, I was. I thought this possibility, too, and therefore tried again by placing one by one (without copying), but still could not have the pages saved. But as I did this AFTER I had initially already placed them by copying, it is possible that having initially used the copy method still had some effect on the issue. Nevertheless, I think that whenever I have used this feature before, I have always used a copy and then assigned the page, and I have not previously experienced this error (that is, in 1.x versions).

What is the source of the non-Apple version? Adobe has the family name as Helvetica Neue LT Std (at least the OpenType PS flavor) so it differs from the Apple version (which is TrueType). I have these two installed on the same system and they do not conflict (not within Affinity apps, either, and Font Book does not complain about duplicates): One potential method to fix this would be using a font editor and rename the family of the non-Apple Helvetica Neue to something else. It is of course a large family so maybe quite a nuisance, and would or course require a specific tool.

They are not necessarily smaller, but might be. It depends on details. But if the graphics is likely to be zoomed in, I would definitely use SVG and keep it as vectors, unless the size is an issue. UPDATE: E.g., in this case, the size of the SVG 1.1 file would be 1,071 bytes and would certainly be the best choice: a.svg

Yes, the new, replacing, method, is basically simpler (less options, too), but produces larger file sizes even if still smaller than AD, left: 24-bit PNG 8,208 bytes, right 8-bit PNG 5,958 bytes. The link you referred to was not too informative but just let CC-based PS users know that the legacy feature is still available so not just clickbait. Irrelevant of course to users with legacy software.

At export time, uncheck the "Embed ICC profiles". You might also uncheck "Embed metadata" though it has only a minor effect: Typically, when exporting, you might want to have the document color space already the same as the target so that there is minimum of recalculation of color values at export time. So if you are going to produce only for web, you would have the document color mode set to RGB/8 and color profile set for sRGB and just export without embedding profiles.

The actual size effect measured in bytes may be small if it is just a tag to sRGB, but it is all relative and depends on details. Left: AI/PS 4,989 bytes Right: AD 8,896 bytes (neither one contains profile or meta data). As PNG is not lossy, Adobe simply just compresses the image better. Whether this matters depends on the amount of these kinds of images, and how massively they are transferred. The effects of including profiles and meta data: If profiles are device dependent (basically inadvertently included, in case the intention is to produce for web) the effect can be hundreds of KB per image (above including a device profile that does not actually contribute anything to image colors or quality causes just dead weight of 173KB per image). So if the size is the primary interest, of course all these considerations are worth taking into account. As PNG has no lossy compression methods, there are not too many factors. One possible method to achieve smaller file size is using indexed PNG, but there what is won in size is often lost in quality: Indexed PNG, left PS size 2,799 bytes, right AD size 8,103 bytes.

...and here is the short version (that counts a hyphenated word as a word on the next line). It works even if it shows "inadequately" the found instances [not actually since the preceding space is selected and when marked non-breakable is enough to bind the preceding word, but does not prevent hyphenation]: shortversion.mp4 (As above, Windows 11 Pro, APub 2.0.3; I have tested 1.6.10 version, Win, too, and it works similarly; I have not tested macOS versions so far.)

Beats me (Windows 11 Pro, v.2.0.3): longversion.mp4