lacerto

You're welcome! Good to hear that this seems to work for you. As mentioned, if the size continues to be a problem, you could probably afford increasing compression without issues. It is interesting to hear about different print/press workflows. I have been following your posts for a while and thought that your project, with lots of large images, and texts often white on black background and over images, might be one where traditional K-only black text, or even CMYK-based job, might not be important, so quite the opposite, producing an all-RGB print job, even without converting to 8-bit images, appears to work well and without requiring intermediary steps (big steps, because the sheer amount of images). I suppose many printers could accept RGB 0,0,0 (body) text, as well, and just let prepress software convert it to K100, while similar black in graphic objects and larger areas would be converted to rich black (with optimum results, because the conversion was left to printer).

As Affinity apps basically always convert native elements (text, shapes, etc.) to CMYK whenever a CMYK PDF is created (even when this is not necessary), it is strange that RGB output is created. Therefore delivering a sample page (preferably of both an Affinity document and the created PDF) would save time, simply to double-check the readings, and see that there is just not some confusion. There are multiple reasons why production of a press PDF might fail and why original color values change, as proven by countless posts on the forum trying to explain why expected output is not achieved (or why native object color values get incorrectly interpreted or read).

I tried with the settings you used (producing RGB based PDF using PDF 1.7, which does not convert placed 16-bit RGB APhoto images to 8-bit) with the exactly same settings which just used PDF 1.4 as compatibility setting (which does this conversion), and that reduced the size of the produced PDF from 6,317KB to 2,685KB just for a document with one such image. If your printer accepts everything else in your production file (having basically all in RGB), then this is the method of reducing the file size. You might also try adjusting the JPG compression (quality), especially if you have big images, since if you have plenty of pixels and good quality images, you can typically afford to increase compression significantly without noticeable (visible) deterioration in image quality. EDIT: Note, too, that APhoto format of a 32-bit CMYK image is not comparable to JPG compressed version of 32-bit CMYK image that you get as a result of export. When I exported the same image, mentioned above, converting it to CMYK, the resulting file size was 2,555KB, so even slightly smaller than a 24-bit RGB image.

it is because your PDF export is probably based in PDF (for print), which uses the document color mode (in your case RGB) and not specifically CMYK based export. Unless your printer has asked you to create specifically an RGB-only production file, you should choose a "PDF (press-ready)" based export method, or at least explicitly specify "CMYK" as the Color Space, and "Use document profile" under ICC profile: This kind of export would use the document CMYK profile, which, if you have not explicitly defined it at any time during the document history, would be the one that you had in force at the time the document was created, under File > Preferences > Color. The default in Affinity apps is U.S. Web Coated v2, which works ok with regular coated media. You should ask your printer, which CMYK profile they prefer to use. Anyway, if your images are really all Affinity Photo documents, what this setting means is that all your RGB/16-bit placed images will be converted to CMYK (32-bit images, that is, 8 bits per channel) using the document CMYK color profile, even if you do not explicitly check "Convert image color spaces", For other kinds of placed images (JPG, PNG, TIFF, etc.) the color space would stay RGB. For these kinds of images to become converted from 16-bit to 8-bit RGB images, you should choose PDF/X-3 export method (which would as a side effect cause flattening of transparencies). EDIT: To keep transparencies and RGB images, but force them to 8-bit, you could also choose PDF 1.4 (Acrobat 5) from the Compatibility list shown above (so basically keep your current settings but just change Compatibility to PDF 1.4). I recommend that you ask your printer their recommendation for production method. What you need to do much depends on this. [E.g., some printers may prefer to have all RGB production file, in which case there is no point in converting anything to CMYK.]

As I tested this with 16-bit APhoto documents placed in a Publisher file, these images (placed linked in a Publisher document) were always converted to 8-bit images and CMYK when exported to press-based CMYK. However, e.g. TIFF based 16-bit RGB images were exported as 16-bit images (even if the Publisher document is 8-bit). The easiest method to fix this is probably use "Convert image color space" option when exporting a CMYK production PDF, that converts them to 8-bit CMYK images. Just make sure that you have the correct target CMYK document profile active in the document, and if not, that when you apply the correct target CMYK profile (via File > Document Setup > Color), you use the Assign option to not cause conversion of existing CMYK color values to a new target profile. Another possibility would be using e.g. PDF/X-3 export method (without forcing image color space conversion), which would keep the images (e.g. JPGs, PNGs, and TIFFs) in RGB format but reduce the bit-depth to 8-bit/channel (max supported in PDF/X-3). But this option would flatten transparencies. Using external editor like Adobe Acrobat Pro would also allow you to convert 16-bit images to 8-bit as a standard single fixup.

This behavior is identical in InDesign and QuarkXPress, so pretty much "an industry standard" when using a facing pages layout. If the printer does not want inner bleeds, or if an automated preflight rejects a job with inner bleed, or if they just bother you, you can set the inner bleed to 0 using File > Document Setup > Bleed.

Difficult to say. This specific version is taken from Apple-provided supplemental fonts, and might be in some ways defective, or crippled in purpose. There are 10 stylistic sets that have widely varied swash lines, some of which extend clearly beyond the specified ascenders and descenders, and basically this is not an issue since line spacing of this font should ideally be set manually anyway, seeing how descenders and ascenders overlap and whether this creates visually disturbing artifacts. I have no idea why Units Per eM value is 400 in this font, far from being sum of ascender minus descender, but as this is not required in typography specs, it can be expected that these kinds of anomalies exist. Interestingly, the stylistic sets (and swashes) are not exposed in the macOS version of this font, but e.g. Pages can use them pretty cleverly.

Considering that your end product is a sprite, it may well be that what you need is to have a non-antialiased bitmap, rather than anti-aliased. If so, you can turn off antialiasing for bitmap exports by using the Layer Blend options (accessed by clicking the Cog icon at the top of the Layers panel). ' Above the View mode is changed to Pixels (Retina) to see the effect already on canvas. Instead of just forcing antiallasing off, you can use the Coverage Map to have effect on how exactly the object will be rendered (considering whether an edge pixel will be turned on or off), but in your case forcing off is probably what is needed.

I have understood that line spacing can be calculated in multiple ways, Apple apps often using hhea table's ascender, descender and lineGap values, while Windows apps the now generally recommended (and a required) OS/2 table's sTypoAscender, sTypeDescender, and sTypoLineGap values (while the legacy apps can still be using usWinAscent and usWinDescent). While em is normally equal to sTypoAscender - sTypoDescender, the OpenType specs clearly advise that line spacing should not be calculated directly on em, but by using sTypeAscender, sTypoDescender and sTypoLineGap: https://learn.microsoft.com/en-us/typography/opentype/spec/recom#tad E.g. FontLab 8 correctly cites this practice in its documentation: Considering the variation in real world, I would rather say that Adobe and Quark chose the practical and more user-friendly method of determining the default line spacing than letting it be based on a way it "normally is" or "should be" calculated. But saying that Affinity apps calculate the line spacing in a way that "other apps are supposed to be doing it" (and specifically stating that Affinity apps do it according to OpenType specs), or that the reason why there is variation is because Adobe and Quark chose to ignore the typographic specs, is simply just wrong. UPDATE: In Glyphs documentation there is good discussion on complexities and different "strategies" a typographic designer needs to consider when determining "vertical metrics" of fonts they design: https://glyphsapp.com/learn/vertical-metrics

Your problems are probably caused by having non-PDF/X-based or PDF/X-1a-based PDFs placed for passthrough, and exporting using any PDF/X method. These kinds exports are typically rasterized by Affinity apps. If you have non-PDF/X-based placed PDFs that you want to pass through, the best choice to succeed is choosing "PDF (press-ready)" that by default uses PDF version 1.7, convert color spaces to CMYK, and deselect profile embedding. This will create a Device-CMYK PDF with native color values and original fonts embedded, and respects overprint attributes, etc. [EDIT: and passes through all kinds of PDFs]. If your placed PDFs are all PDF/X-based [EDIT: and you need to use PDF/X-based export method], you should choose PDF/X-4, to make sure that export PDF uses the same or later PDF version as placed PDFs. Converting to EPS might work, but then it is good to know that overprint attributes are not honored, and spot colors are not supported. These are Affinity-specific limitations (and fonts left embedded would automatically be converted to curves, too). Letting Affinity interpret placed PDFs, especially if fonts have been converted to outlines, might work, but then you need to pay attention to possible color profile conflicts, because interpreted (CMYK) PDFs will be assigned the working color (CMYK) profile, not the document color profile (and never discarded and just passed through, as by default happens when working with Adobe apps). And if there is a profile conflict at export time, all CMYK color values will be recalculated (causing e.g. K100 blacks becoming four-color blacks).

If you select "Black" from the Apple palette, it will be RGB 0, 0, 0. If you select the black well (one of the four "factory" wells in the Swatches panel), then its color value will depend on your document color mode. For CMYK, it will be C0 M0 Y0 K100, for RGB and Gray, it will be R0 G0 B0. Why you see RGB hex #231F20 as your color value in the Color panel, is caused by viewing the ad-hoc translation of the C0 M0 Y0 K100 black to RGB Hex, according to your current color profile environment (probably from U.S. Web Coated to sRGB). As long as the lock on the left of the sliders is turned on, this is just a calculational translation of the CMYK value, but if the lock is turned off, then each time you switch the color model within the Color panel, the app actually converts the color value of selected objects into another color space, according to your profile environment. blackwells_apple.mp4 Unfortunately there is a bug in macOS versions which causes that the true color values are not immediately refreshed when you release the lock, so you need to de- and reselect an object to display its true color value in the Color panel. On Windows the true value is shown immediately as the lock is released. As for the "best black" to be used, it really depends. If your project is a four-color job, and the object where black color is applied is not small-size text, you would be good to use RGB 0, 0, 0, which would be converted to "rich black" (four-color black) at export time or when printed, which would be the darkest that you can get. You would want to use rich black also when needing to overlap areas of black on top of objects with other colors, since just overlapping K100 typically results in overprinting where the black color looks uneven in parts where it overlaps different colors, and where it is printed alone on the paper. On the other hand, if it is small text, or something where there is a risk that small misregistration of CMYK colors causes slightly but distinctively blurred edges, it is best to use K ink only. The same is of course true if you are going to use commercial press and you have agreed on using black ink only (e.g. to save in costs).

Note that depending on the screen width and configuration of the context toolbar, the Lock Children option might be hidden in the overflow dropdown control of the context toolbar. Note too the functionality of having locked children: it affects not just scaling but also other transformations, like moving and rotation. lockchildren.mp4

The actual value of the black well in the Swatches panel depends on the document color mode. Note too that color picker of the Swatches and Color panels always displays the color values in document color mode (so not necessarily the actual color definitions). Understanding the function of the lock button in the Color panel is crucial when working with color definitions in Affinity apps. blackwells.mp4

However, there does not seem to be means to explicitly select the source of the color profile in a (common) situation that there are multiple with the same name available, but there might be order of preference even if possibly not documented anywhere. I would imagine that the highest order is given to the user, app and version specific library folder, so if there is a profile with a specific name there, and multiple profiles with the same name in other places on the system, the one in the user, app and version specific folder would be used -- and the other profiles with the same name would just be ignored. If this is true, a user concerned with a specific version (e.g., one recommended by the printer), could affect, which of the multiple profiles with the same name would be used. And if a user does not care, they would probably just be happy not needing to see the trouble of finding one on the Internet.

Try if it makes any difference to export to SVG using "SVG (for export)" preset. When opening an SVG file in Inkscape or Illustrator, both "Layer" type containers and regular group type and other kinds of named organizing containers are retained (even if objects enclosed are often placed in group containers not existing in the original design).

If fiddling with the hardware setting does not help, try if running the app in Rosetta mode does.

I think it used to be so that Affinity macOS apps purchased from Serif store only could read the internal Affinity app bundles for location of ICCs, and then Affinity specific user libraries under Application Support. And it used to be separate for all three apps and versions (including betas), but it seems that they are now capable to read them more globally. But if you cannot find specific profiles in system-wide locations, you might find them in these kinds of app specific locations: /Users/<user account>/Library/Application Support/Affinity Photo/profiles/ISOcoated_v2_300_eci.icc /Users/<user account>/Library/Application Support/Affinity Publisher 2/profiles/ISOcoated_v2_300_eci.icc ...etc. But all these should be locatable when searching within Finder (not sure if they would be hidden when using Spotlight. EDIT: I just tested this by deleting old user account specific profiles, and created a new user account, but Affinity v2 apps still could find profiles in Adobe created shortcut locations /Library/ColorSync/Profiles/Profiles and/or /Library/ColorSync/Profiles/Recommended, which in my situation point to /Library/Application Support/Adobe/Color/Profiles. and /Library/Application Support/Adobe/Color/Profiles/Recommended where (at least) I have many of the profiles found by Affinity apps installed. If I delete these folders (and delete them from the Bin, too), part of these profiles disappear from the Affinity lists. But e.g. ISOCoated_v2_300_eci.icc still remains, so it is possible that Affinity apps cache them somewhere whenever embedded in Affinity opened files. EDIT2: I just tested and when the Adobe specific profile shortcuts are removed, Affinity apps on a newly installed user account no longer list profiles like ISOCoated_v2_300_eci.icc. So it is clear that Adobe created locations are read, but also, it seems that once specific profiles have been used in a file opened for editing, these profiles are saved in a user-specific cache. Anyway, I think this is a feature, not a bug.

On Windows there is less junk than on macOS (since universal binaries are not needed), but still not enough to include meaningfully arranged 0s and 1s to read printer margins when tiling (here 5mm additional overlap was meant to be included). It may be printer specific whether tiling option is available via Preview on macOS (Sonora checked) but it was not for my Xerox so it seems that some further junk needs to be installed, and to avoid mental issues, little cash might also need to be spent. On Windows the free (Lite) version of PDF/X-Change might be able to do tiling, the low-cost perpetual license version at least is, and does it properly.

As @lepr mentions, you should specify the percentages in K, not in Gray (which is basically an RGB value), which will cause the kind of inaccuracies when saved as a spare channel in a CMYK image. See the following clip so see the difference: gray_vs_k_spare.mp4 I am not sure if I understood your subsequent workflow, but you can use K-values in the spare channel to load them in alpha channel and retain expected mixed color values in interaction with other layers. spare_to_alpha_to_tint.mp4

Certainly but it is also a kind of a thing of culture and quality, and not necessarily overpriced, even if not free. Be careful of "free"!

I initially shared that view, but nowadays think differently. Compare CC with Quark and Corel (practically both subscription nowadays, also Xara Designer, probably not known to you because of being Windows only), and what you get with these deals. The only CC product I personally still subscribe is Photography, at EUR 9.99 per month, and I get all versions of PS, Lightroom, Adobe Fonts, some cloud space and full Express. I think it is a bargain (on multiple devices on multiple platforms). [EDIT: But as a Windows user, I can of course still use all CS6 Master apps on latest Windows version without problems, something that Apple made impossible on macOS when barring 32-bit apps after Mojave.] I suppose functionally the thing that changed my mind and stopped me hating Adobe was years of working with Adobe fonts. I had earlier purchased a share of Adobe Font Folio 8/9 (costing about 20,000 FIM = about 3,400 EUR) for 20 users which was quite pricey at the time), and subsequently purchased a 5-user 11.1 package just for our company (a family business of 2 users) somewhere around EUR 2,300. Still much cheaper than going for anything with Monotype nowadays. All this seems like a lot of nonsense nowadays that Google etc. offer everything "free", right? But in a changed world, you often use fonts differently and not perhaps primarily for printing press, and with Adobe Fonts, you get a license to use the fonts also on the web. If you do not just prefer to nick your fonts (= not caring where they come from), it is not such a bad deal. And then there are innovative things with AI (and Adobe seeming to be doing something to get creators credited -- or perhaps I am just seeing this through pink (or actually green) Spotify-glasses, naively thinking that this does at least some good for musicians/photographers)?

Most of the time it probably works, but is not of course the same as overprint. I probably misunderstood the "mindset" thing. This kind of talk somewhat reminds me of "having to" (whoever forces) do trivial business-oriented things in "Micro$oft way" and "think" "different" and be automatically "creative" when switching to Apple egosystem, using the exact same apps on that platform. Being forced to upgrade from Altsys/Aldus/Macromedia to monopolizing Adobe was not altogether bad experience at times when properly color managed PDF workflows were introduced (and were a bit later made non-proprietary ISO standards). For me the most attractive feature of Affinity apps has been that they feel instantly familiar because having copied as much as possible from Adobe apps, and that they additionally have some nice functional pluses that Adobe apps do not have. But talking about "Affinity" (a different) mindset (and possibly referring to things like Studio) does not make sense to me (I consider it a sales gimmick and a technological flaw in context or press production). Affinity mindset, if there is one, is "low cost non subscription". Production-wise it often means lots of workarounds, or "voodoo", as you put it. That is totally fine, considering the price, but to put it right, it often requires training in "Adobe mindset", that is, with industry standards.

If you mean a document tab within Designer, then SVG elements that are pasted do not create a document of type SVG, nor do SVG elements pasted on to an existing Designer document (even empty one) make it a document of type SVG. There is no SVG document format that Affinity apps can save back to, so when Affinity apps produce SVG code, it is always an explicit result of exporting to that format, also when "copying back" SVG code by virtue of a preference setting. So even if the menu command says "New From Clipboard", it means "new Designer document from Clipboard". The Clipboard can contain also e.g. a bitmap, yet the document created will be a Designer document, not a bitmap of the format that is pasted. Also, if you paste SVG code within a text frame, the code will be pasted as text instead of rendering it to graphics (even if inline graphics is supported). This will happen also if you paste single object elements from Clipboard, so the current code requires something more than just object tags to make a decision of trying to render the code rather than just pasting it as text. It is nice if the developers make Windows and macOS apps behave identically in context of this feature, but as mentioned, comparing with other 2D graphic design apps (especially on Windows platform), this is not a big omission. I do not think that there is a "right" way to do this kind of data exchange so it is good that the user can basically make a decision by placing SVG as code or objects based on the target container (page vs. text frame), or use Paste Special (on Windows). At some point Serif made a change that allowed font designers to paste object content from Designer in format that behaves meaningfully (e.g., in proper size) in FontLab so often when exchanging information via Clipboard (I do not recall if it was specifically related to developing SVG fonts), there needs to be some target or application in mind, and therefore need to tag content in a way that the targeted app can use. It does not need to be MIME based but planned to behave in a way that can be processed as planned in specific data exchange considering the needs of users who have requested a feature. For coders previewer plugins might be more straightforward method to check that coding works, but that probably depends on complexity of code.

I checked QXP2018, there the default is that coordinates are per Page. If they are by Spread, coordinates behave similarly as in Publisher. Moving the origin to anywhere else than top left of the spread will show negative coordinates to the left of the origin, similarly as InDesign and Publisher, and if the origin is not changed, the rightmost pages do not start from zero. I too have version CS6 but it is still the same in current CC versions. Whether app defaults vary depending on the country I have no idea. But the option that says "Spread" does what it says, and if you need "Page" coordinates, the appropriate option is "Page".

In InDesign the origin of the spread is at that lop left corner of the spread, though, so if you have facing pages, it is at the top left corner of the left-side pages, similarly as in Publisher. I do not remember how it is in QuarkXPress (I have 2018 version). Personally I often move the origin to the spine when needing to check e.g. symmetry of a (mirrored) facing-pages layout (and in this case it helps to have identical readings, (except of the plus/minus sign). In some facing pages projects page-based origin may be more convenient, though, and as you mentioned, we all have our preferences.