lacerto

I wonder if there is any design point in constructing symmetry this way, or if this could be some kind of a residue from converting from quadratic B-splines. It seems odd, though that italics versions do have these adjacent nodes combined. And glyphs of course often have superfluous nodes close to each other (though perhaps not so often quite as close as in Gotham), but do not normally show these kinds of artifacts (I tested a few simulating hand writing with lots of nodes -- and additionally inserted a few very close nodes myself -- and they worked ok with heavy outside outline). I thought first that the problems could have been caused by combining outside outline with scale transformations (especially negative scaling), but they happen also with unaltered glyphs.

Since the problem only occurs in (most but not all) upright styles of this font family, a cheesy quick fix would be using italics and then use unshear character attribute to straighten the glyphs. You have manipulated the font quite a bit so perhaps this does not hurt... gotham_italic_unsheared.pdf

The error seems to be related to the way some glyphs are constructed in this font: Affinity apps do not seem to be able to handle correctly shapes with two adjacent nodes in situations strong outer outline is applied (the error can be reproduced also after these glyphs have been converted to curves). It seems the error can only be corrected by combining the adjacent nodes manually or by "fixing" the font by doing the same in font editor.

I have version Version 3.201 Pro OTF version from Hoefler & Co. installed and no duplicate versions and can experience the same issue when used with Affinity apps but not when used e.g. with InDesign.

JPG compression is complex. Just to illustrate how it can be, here is a 2000px x 2000px TIFF as a pure grayscale with only black color and transparent background, and colored 8-bit version of it: Fineliner Scribble Lines_gray.tif Fineliner Scribble Lines_color.tif These files have then been exported as RGB JPGs with 85% quality from Photo and Press-ready PDFs from Publisher using Bilinear and Nearest Neighbor JPG compression (downsampling not needed) both to RGB and CMYK. Files with "ID" show exports from InDesign using "Auto" and "Maximum" JPG compressions. As can be seen, Affinity Publisher does just well exporting JPG compressed PDFs when exporting without color conversions, since both CMYK conversions and handling a true grayscale file or composite grayscale as a composite gray result in big file sizes. This is because solid colors, including transparent (or white) parts, are kind of dithered disregarding the resampling method, similarly as when exporting from APhoto. It should be noted that Photoshop does the same unless legacy Save for Web with maximum quality is used, but then the file sizes also become massive (over 7MB, when 85% quality produces sizes in the same category as Photo above, about 3.5MB), and the original lossless ZIP packed TIFF only takes about 200KB. It is strange that when the same files are exported from Publisher (in RGB or pure grayscale), or from InDesign also in CMYK, the JPG compression produces such small file sizes. Fineliner Scribble Lines_ID_Auto_Max_gray.pdf Fineliner Scribble Lines_ID_Auto_Max_rgb.pdf Fineliner Scribble Lines_ID_Auto_Max_cmyk.pdf As can be seen, there is no impression of "dithered" colors, and transparent/white space does not contain stray pixels. EDIT: I did not examine the contents of the PDFs but it could of course be that JPG compression does not happen at all with the small PDF export file sizes but the apps just pack the original slim TIFFs whenever they can. EDIT2: JPEG Compression quality certainly does have an effect: Here is the Publisher file in case someone is interested in testing this more (it consists just of an embedded Grayscale TIFF colored with a gradient rectangle): Fineliner Scribble Lines_Screen.afpub --and here is the CMYK export made from the equivalent InDesign file: Fineliner Scribble Lines_Screen_ID_auto.pdf Note that Publisher created PDF exports are much better when CMYK conversion is not performed, but still not even near the 38 KB file size achieved by InDesign. So clearly it is not just brute force compression that matters but analysis of the files to be exported and choosing the best method depending on this. EDIT3: InDesign seems to be able to retain the grayscale bitmap and the vector gradient colorizer as separate elements when exporting. But it does a good job also when just compressing with JPEG (Auto) and Maximum image quality the same image as a flattened bitmap (260KB): Fineliner Scribble Lines_Screen_ID_bitmap_auto.pdf This file, when compression is set to none in InDesign, will have the same file size, about 21MB, that Publisher produced with JPEG quality set to 100. As shown, exactly the same quality can be achieved with 260KB.

If the print shop does not really need to open the PDF in Illustrator, they could possibly do printing from a PDF that has the printable and non-printable parts separated as so called "PDF layers" (or OCG layers = optional content group). Affinity Publisher and Designer can export their native layers (layers that have "(Layer)" appended to the layer name), as PDF layers when creating a PDF (the option is by default selected when exporting using "PDF (for export)" preset), but can be checked separately from the "More" options page when exporting to PDF. But if the print shop really insists on having an .AI and separate layers for the image and vector, the only solution I know that really works, without needing to use Illustrator, is to place the image and vectors in separate Layer layers in Designer/Publisher, and exporting to PDF using the option that export Layers and then open that file in CorelDRAW or Xara and export to .AI. Just renaming a PDF to .AI does not work because Illustrator flattens all PDF layers: it only retains the hierarchy of native Illustrator layers. CorelDRAW and Xara retain hierarchy of PDF layers up to first level, and can then also export these layers in .AI format so that Illustrator reads them. Xara for some reason converts a CMYK document to RGB but if that is not a problem, and the fact that this app is Windows only, this might be a kind of a solution (perpetual license around USD50). CorelDRAW is also available for macOS, and perpetual license is available, but the app is expensive both when purchasing a perpetual license, and when subscribed, so this is hardly an alternative to getting Illustrator. That CorelDRAW can truly write and read .AI (to some extent at least) is probably based on some kind of agreement between Corel and Adobe to share their proprietary file formats (both importing and exporting). Xara is probably just hacking away what it can, and at times this may be helpful, but it is not always robust. One possibility might also be placing the image and vectors in separate layers and export to SVG. This means that RGB only is supported, but the job could at least be opened in Illustrator as organized to two layer-kind of groups (not actual layers, though) so that the image and vectors are in separate containers from each other. But while this could be a technically valid solution, it of course is not the same as what was initially required by the print shop. You might possibly resolve the problem also by changing the print shop to someone more flexible and pragmatically oriented one...

This tool only works with Pixel layers (rasterized images).

For me the tool works exactly the same on Windows and macOS so changing the tolerance setting using the Tolerance Box (typing in new values, or scrolling the mouse wheel etc.) does not alter the existing selection, but dragging with the mouse on canvas does. Personally I find the biggest issue with this tool that it does not support antialiased selection.

I am not sure if I understood you question but if you place high-res images and export without allowing downsampling, the placed images will retain their native resolution, and accordingly allow upscaling to benefit from the high-res images placed in the job. Below a high-res image is placed in Publisher but the behavior is exactly same in Designer (when upscaled 10 times the effective PPI of the image would be about 300dpi, which means this image could be looked at close range when upscaled to 50 x 50 cm): I Note that when you export, the default quality of JPG compression is 98 in Affinity apps. It produces huge sizes, compared to the same document exported from InDesign with exactly same settings (InDesign using "Automatic (JPEG)" and image quality "Maximum" compression settings): I had to decrease the compression quality to 70 until I got the same file size InDesign created with "Maximum" "Automatic". Examining the results in this specific situation showed no significant differences in quality but I have tested the compression quality settings sometimes earlier extensively and 70 is not a setting that can be used uncritically as a general setting so it works perfectly fine in situations like this when there are lots of pixels in the source images, and no resampling, but would produce all kinds of artifacts in many other situations. Not having an automatic analysis of the most suitable compression / quality rate for each image to be exported is a big time waster. It means that to be on a safe side, it is probably wise to use the default (98) compression quality if the document contains multiple images of different sizes and properties.

Just different RGB profiles, I suppose. But I still do not quite get how Affinity apps handle colors, and especially grayscale conversions. Basically the conversions stay visually "symmetric" whenever the source color can be produced with the destination color space (even if largely different source color values can naturally produce by value if not identical then very similar and at least visually very similar destination colors); after this stage is achieved, conversions in either direction are mostly rounding errors but the color stays essentially "the same". But this does not (necessarily) happen when grayscale values are involved, even when using the default D50 (or Gamma 2.2). The color lock is also confusing because it can produce kinds of confusing display puzzles shown in the clip I posted, hiding the true color vales of objects. InDesign has similar dual color model support for objects without a lock, so it retains both visual and value symmetry between color models as long as values are not manually changed (= even just retyped the same values or touching the sliders), so a mere switch of the model does not actually perform conversions even if the active color mode of the object does change (InDesign creates temporary swatches for ad-hoc color definitions and assigns objects colors by using them). Illustrator (as does Photoshop), on the other hand, has a dedicated document color mode and does not allow conflicting color values so even if colors can be defined in any color model, they are immediately converted to the document color model. This, too, effectively prevents such UI confusions demonstrated in the clip. Affinity apps basically try to implement the different color handlings of Adobe apps across all three apps (probably because of the common object model and serialization), which then results in these kinds of oddities. But who knows, these things are not documented so we just need keep on guessing.

0:51 and 1:04 appear to show the K slider at 100% and RGB values in R40 G40 B40 (8-bit scale). But I might have overlooked something (or perhaps watched the wrong clip!) In most cases these are rounding errors so keeping the lock on and just switching the model gives "accurate enough" conversion value in current profile environment. But grayscale conversions (if using something else than D50/Gamma 2.2; or if using an RGB profile that differs significantly from sRGB), both when actually converting, or checking values, can give highly misleading readings or perform significant inadvertently done conversions just after one switch.

I usually convert them to .mp4 but just forgot it this time. Now it has been converted.

Difficult to say without knowing the underlying color spaces that have effect on profile-based display values (that are not necessarily conversions, but "would-be-values"). Affinity apps are basically created on assumption that sRGB and D50 (Gamma 2.2) are used as RGB and Grayscale profiles, if they are not, odd things can happen both when showing color values in another color model ("would-be-values"), or performing ad-hoc-conversions and when actually converting color values. Here gray rectangles with identical RGB values have different visual appearance, and rectangles with different RGB values have identical visual appearance. There is no symmetry when converting from RGB to Grayscale, and Grayscale back to RGB (while there should be). confusedcolorvalues.mp4 I noticed this a while ago when playing with Dot Gain grayscale "profiles" (borrowed from PS). They basically work ok when converting from RGB to Grayscale, but when converting back to RGB do not give the same appearance so the conversions are not symmetric, as they are in PS. So e.g. R128, G128, B128 gives G36 (64% gray value in PS) when having sRGB and Dot Gain 15% as the color profile pair, but to go from Grayscale back to R128 G128 B128, you would need to use G50 (G36 would give R92 G92 B92). In other words, having the color lock of the Color Panel turned off, switching a few times between Grayscale and RGB models would make mid gray R128 G128 B128 become nearly full black. I am not sure what happens in OP's situation but as K100 gives R40 G40 B40 when using ISO Coated 300%, the RGB profile certainly isn't sRGB so perhaps something similar happens here. EDIT: Similar inaccuracy happens whenever switching or converting using the Color Panel also when switching between RGB and CMYK, but typically they are rounding errors and mostly insignificant unless performing multiple conversions (e.g. inadvertently switching color models multiple times while having the lock off).

One additional note I forgot to show on the clip: to move an existing guide with the Node tool, grab it from the ruler area (you cannot select it from within the canvas).

(In all three apps) Use the Node tool and appropriate node snapping option with selected curves to have guides snapping at desired nodes. nodesnapping.mp4 In Designer (or Designer Persona of Publisher), you can additionally use the Point Transform Tool to use additional snapping aid.