lacerto

I do not think that there is a realistic way to control that. There are many factors that affect the actual width a specific amount of pixels measure on a computer display: ...and the ultimate variable is the user and their preferences: dpirelativity.mp4

It is not an actual preflight tool but a great PDF editor and a good accompanion to e.g. Packzview, and the same (perpetual) license can be used on two of the three supported platforms.

I ran a test on using merge (concatenation / collecting to a new document) functionality of qpdf and PDFtk vs using replace functionality of of PDF-Tools when using PDF/X-1a source files, and could not have the former two to keep PDF/X-1a compliance. I am not sure if these command line tools have replace page or delete page mode so that the replacing pages could in a way be placed in an existing PDF "shell" without losing the essential document features, but it does not appear to be so. Just extracting pages from another document does not appear to transfer these properties (this might be something that would be carried in the future when using PDF 2.0). Anyway, PDF-Tools (and PDF-XChange coming with PDF-Tools but which can be acquired also independently) can do this. Unfortunately it is available only for Windows. It would be good to know if there is something equivalent on macOS that can do this (or if there is an online service that can do this platform-independently) -- offline tool would be preferable (and I wonder if PDFtk actually uses Internet in conversion, as it appears to take some time and has an Internet address in PDF producer box). pdf_editors_merge.mp4

No, it is still more complex 🙂 When having a PDF placed in interpreted mode, a placed PDF with DeviceCMYK colors (no profiles embedded) will get assigned with the working place CMYK color profile as defined in Preferences > Color (which by default in Affinity apps is U.S. Web Coated v2, but which I have set on the video clip below to ISO Coated v2), and if your document CMYK color profile (where you place the PDF) is different (like on the video clip a new document is created with ISO Newspaper CMYK profile), there is a profile conflict and your interpreted K75 will get accordingly converted to four-color black! The way ligatures and OpenType features are interpreted is a kind of a typographic horror show so thanks for pointing it out! Now we know that if the source PDF has anything that really matters typographically, interpretation mode should never be used (it is really odd that the source document settings are completely ignored, yet you cannot affect the way ligatures and OpenType features get interpreted by using the settings of the hosting document, either). But when using the Passthrough mode, you get the native K75 at PDF export no matter what your profile environment is (and no matter which kind of embedded profile, if any, the placed CMYK PDF uses). And you get the correct ligatures and OpenType features passed through, as well. The video clip shows behavior in Designer 1.x but it is identical still in Designer 2.4.0 (Windows versions only tested): ligatures_color_interpreted.mp4

I am not sure if it is 100% up to the etiquette, but as long as you're basically doing these kinds of things in purpose of helping users of Affinity apps (instead of trying to sell something, or mention the competition to harm Serif), it has been kind of ok to mention 3rd party tools (sometimes also competitive) that are useful when creating documents with Affinity apps. Adobe trio very often gets mentioned on the forum because that's where many users of Affinity apps come from, and often expect (rightly or wrongly) identical results when using similar tools, operations and workflows. It benefits the users of Affinity apps to understand the differences and describe, often with direct comparison with an Adobe app, what they need to do to get expected results. Personally I think it is a clear forte of this forum to allow at times blunt comparisons and even harsh critique against the Affinity apps. They have so many strong points (often superseding the competition), and they are in continuous development, that it is definitely worth to stay persistent and learn to use these apps thoroughly -- sometimes it means, learn to use them "properly" (in a different way that they were designed to operate), sometimes learning workarounds (mostly easy ones but sometimes tedious).

Personally I would do this kind of job by using a PDF editor and merging press-prepared documents, just replacing specific pages (page numbers saved as a list) and saving the opened CMYK PDF with a new name, meaning that the resulting file will have identical properties, but just have specific pages replaced with grayscale versions. One such tool is PDF-Tools. In the following the replacing file and page ranges have already been defined into a custom batch job, which also changes the initial view to scrolling facing pages with a cover page and sets the magnification option to fit page: mixed_pubs_xternal_tool.mp4 Using a PDF editor has the benefit of not needing to play with page positioning, print marks and export settings because these things have already been done in the source files.

I do not see any other way than what I showed in my post, but that, too, may require some preparation (like switching between K100 <-> Gray/RGB black), and handling of placed PDFs (= need to use Interpret mode to have their color space changed to RGB and Grayscale). and also post-processing, like manually changing page boxes from trim to media/bleed page by page, and handling non-symmetric bleeds (which Affinity apps cannot deal with automatically). The video clip below shows the procedure of creating a mixed mode publication, after you have created your all CMYK and and all Grayscale versions. The building blocks are attached, including an RGB version that has black text as RGB 0, 0, 0. mixed_colors.mp4 But basically the method shown could be used pretty effectively to get fully professional output. Hopefully Affinity apps at some point will have InDesign [Black] intelligence which keeps K values in grayscale exports, and auto-converts K100 to RGB 0, 0, 0 in RGB exports -- and that Publisher has its page box bugs and usability issues related to the page box and K-Only button fixed -- these fixes would make creating mixed-mode print jobs very smooth. color_and_gray2_allcmyk.pdf color_and_gray2_allrgb.pdf color_and_gray2_allgray.pdf color_and_gray2_mixed.pdf

Thanks for demonstrating this new feature! This appears to be a genuinely new ((if not unique) concept and while it appears to be pretty resource-heavy, I must say I was impressed by the implications and the promise, also considering PDF 2.0. Maybe we are on verge of experiencing something truly new in multi-purposing and creating alternative PDFs -- my brain hurts already, and I sincerely welcome the pain caused by having to expand a bit my (age-old) professional universe 🙂

Sometimes there are manual overrides that do not get easily changed, and forcing a style definition can have consequences where you lose one attribute when forcing another. Affinity apps especially typically need to have local formatting secured with character styles because simply just reapplying the same style might cause losing local formatting. If the task is easy enough (look for text with RGB 0,0,0 fill and replace it with CMYK 0,0,0,100, or vice versa), it is basically a one-click job to have it done. If there are swatch assignments, it could easily be done that way, too (and if assignments are global, this would probably handle tinted blacks, as well). But I have not tested this much in practice so you might well get good results with styles. Select same and select all by type feature (available in 2.x version of Publisher) can also be very useful in jobs like this.

Thanks for sharing, this is odd, but good to know. Basically you should just use the Passthrough mode if you want to retain all features of the original file. Just remember the so called "PDF compatibility rules" that are in force within Affinity apps, so that placed content will not be rasterized. Note that when you have Passthrough mode, the shown content is rasterized on display so you cannot use the color picker to verify the color values of placed content. You need to export the PDF and then examine the color values to make sure that the native values have been retained. EDIT: Note too, that the color picker always shows color values in document color mode so in case your document color mode is RGB, you would see K75 values of an interpreted PDF converted to RGB, according to your current profile environment. Attached is a DeviceCMYK K75 dummy PDF, which was placed in a Designer 1.x document as passed through and then exported, and the original color values are retained. devicecmyk75.pdf devicecmyk75_placed_exported.pdf PS. What you mention about ligatures and OpenType features in interpretation mode is interesting, I'll check the behavior.

Using adjustments only results in having four-color-gray on "grayscale" pages, so if you print commercially, this is not a solution (at least if your goal is to save in printing costs). I would do this as follows: Prepare your color document in CMYK mode. You can use RGB definitions for native shapes and colorful text if you want to benefit from the full RGB color gamut. Specify all black text that needs to be in K-only using CMYK color model, and CMY set to 0. Export your RGB document. [OR: If you want your K100 blacks as RGB 0,0,0, wait until you have converted K blacks to RGB blacks.] Export as "All pages" a fully colorful CMYK document using the document CMYK profile. If you have bleeds, include them but do not include any print marks. If you have placed PDF in color, mark them to be exported as "Interpreted" (instead of "Passthrough"), since in Affinity environment color space of the "passthrough" PDFs is retained (because Affinity cannot perform that kind of deep modifications in placed content, similarly as e.g. InDesign or QuarkXPress). If you want to have K100 text on the grayscale pages to become K100 (instead of dark gray having something like 87% blackness)m change the color definition of K100 text to RGB 0, 0, 0 or Grayscale 0 (they are practically a same thing within Affinity apps). You can do this in one go using the format option of Find Replace tool. Now export "All pages" by specifying explicitly "Grayscale" as export color mode and choose "Grayscale D50" as the color profile (if you do not have anything more appropriate available). Here, too, if you have bleeds, include them but do not include print marks. Prepare an empty Publisher document that uses the same format and CMYK color profile as your original CMYK publication. Now place the grayscale version of your PDF in this document, expand the placed content suggestion on the left column so that you have all pages shown in the list of pages to be placed, then select them all, and on the empty page of the hosting document, click in the exact middle of the page of the hosting document, or draw a page rectangle of the size of the document (including the bleed, if applicable) on the hosting document so that all pages from the grayscale PDF version are placed in the new document. If you have bleeds, change the Page box for each imported page so that page crop is set correctly to include bleeds. If you do not have bleeds, then the default "Trim" crop option is correct. Publisher is buggy at the moment and might have placed the pages inaccurately (specifically if you just clicked in the middle of the page instead of having drawn the page rectangle) so you need to check that placed pages have been positioned correctly. Now that you have grayscale versions of all pages placed, use the Resource Manager, and for each page that you want to have in full color, replace them one by one with the all CMYK version of the publication. Publisher will automatically fetch the correct destination page from the replacing PDF so if you select page 4 in Resource Manager and replace that with the all CMYK version, page 4 from that document will be chosen. Now export the document using the same CMYK settings using PDF (press ready) preset, which is the most flexible export method and will not rasterize any of your placed PDF content. Do not include ICC profiles because all your CMYK pages will be DeviceCMYK, and all your grayscale pages "DeviceGray". Attached are PDFs of a simplified project. The placed content has RGB image, RGB Photoshop image with transparency, placed CMYK PDF, native RGB shapes, and K100 text placed on each of the four pages. color_and_gray_allcmyk.pdf color_and_gray_allgrayscale.pdf color_and_gray_mixed.pdf The weak point of this method is needing to have PDFs with color content set in Interpretation mode since that might result in e.g. font replacements and other interpretation errors. That would not be a problem in the referred "other" application, at least if your "other" is the "other" of mine. Another possible weak point is if your printer requires e.g. PDF/X-based preset method, since Affinity apps have a thing called "PDF compatibility rules" which e.g. means that a non-compatible placed PDF content will be rasterized. And rasterization results in having four-color conversion and accordingly ruins the grayscale plans.

Yes, basically objects (shapes, text) where you define color values (and model) with internal tools. Whatever color model you use to define a color value for a fill/stroke, gradient stop etc. attribute for these objects, the definition is saved as a native value and used when you export so that the initial gamut is fully exploited. Often design principle might actually be opposite, to produce output that is visually coherent both on digital and print media.

Because Affinity apps cannot keep color "numbers" (= InDesign feature), it is not recommended to export using a non-document target profile, because this results in conversion of all native color values (which are in "conflict" with the new target) -- meaning e.g. that all K100 values are converted to four-color-black. If mere change of CMYK profile is wanted (without conversion of color values), the recommended method is to choose File > Document > Color, and use the Assign option when choosing an alternative CMYK profile. If the current and new CMYK profiles deviate strongly from each other, "Convert" option should be used, instead, but then the K-only values need to be done again. Affinity apps also do not convert swatch definitions so all swatch assignments are lost in context of conversion.

It is often difficult to reproduce transparency flattening related issues because print-time rasterization can be handled in different ways by different devices, but Affinity apps have been notorious of producing jobs containing mixed color objects (especially if containing mixed color profiles) with transparencies poorly. I have run some initial tests with version 2.4 apps and it might indeed be that there are now some improvements, and measures taken in direction where mixed mode exports and especially mixed transparency blend modes are tried to be avoided, so it is possible that just sending a PDF that has been re-created with the same setting that you have used so far, now works. However, without preflight tools that make it possible to properly preview PDF internals, and make fixes if needed, flattening transparencies (using PDF/X-3 or PDF/X-1 export methods) is a good way to ensure that what you see (when viewing an exported PDF) is pretty much what you will get on paper.

It should be your principal workflow to always place photos and other RGB images in RGB color mode and just have them (automatically) converted to CMYK at export time, using the correct CMYK color profile. You can have your press-oriented document in CMYK/8 color mode and place and define native shapes in RGB and then convert to CMYK (CMYK document color mode does not mean that the app automatically converts colors to CMYK when placed or defined; Affinity apps allow kind of dual-color environment, similarly as e.g. InDesign). There is typically no need to convert images to CMYK beforehand.

You basically cannot, if your job also has color content. You could have RGB 0, 0, 0 black exported to RGB black for digital purpose and K100 (actually gray 0) for press, but then you'd need to export the press job using grayscale mode, and that would not work with native color RGB objects (which would be in gray). There is no equivalent of "[Black]" swatch of InDesign that exports as K100 in press exports, and RGB 0, 0, 0 in digital exports so if you want to have that, you need to convert text black for both purposes (which is not necessarily a big job since you can use e.g. Find / Replace to convert all K100 text to RGB 0,0,0, or vice versa, in one go; or use text styles, which, though, is less reliable way to do it). As you are going to export to press, too, I would choose CMYK as the primary color mode and define text as K100, and all native art in RGB (that is perfectly possible, since Publisher will keep your RGB definitions without converting them to RGB (just remember to have lock turned on in the Color panel if you use that to define object colors). You would naturally also place all your images in RGB color mode. When making the final digital export, you would then convert K-100 black to RGB 0, 0, 0. There are benefits of primarily using CMYK color mode, e.g., to have the "K-Only" button available, which would let you have your grayscale images automatically processed as grayscale (or control the conversion/non-conversion manually for each image) when exporting to CMYK, instead of being converted (typically inadvertently) to four-color black. Keeping the job as CMYK will also make your press-related exports more relaxed, considering the need to have the optimum CMYK document target profile applied, as you would not need to make document color mode swaps just to make the right CMYK color profile assignment.

Hi @rzolau, and welcom to the forums. You mention that you drag and drop your PDFs onto a Designer artboard. This is equivalent to using File > Place, and using the default placement mode, which is "Passthrough". Please check that this mode is shown on the context toolbar when you have the placed PDF selected. On the other hand, you also mention that you can select the "imported" text, specify formats like ligatures, etc., and this implies that instead of placing the document, you have actually opened a PDF for editing? It is crucial to know which way you have your DeviceCMYK PDF brought in Designer, since the advises vary depending on what you have done. Also, please ensure that you are viewing the resulting PDF with an app that does not show recalculated color values. E.g. Adobe Acrobat Pro might use a simulation based on target ICC profile and show translated color values, in case the viewed PDF has embedded ICC target, and in this case the simulation profile must match the embedded target profile. As for your second question, if it is a document that has been placed for passthrough, all native formatting is retained and whatever you have active in the hosting document, only applies to text that you have created in that document. As for interpreted or opened PDF, I would assume that formatting of the source document is used, but I have not examined this thoroughly, and know that certain settings, like overprinting attribute, is not correctly read by Affinity apps, so there is point in checking all these kinds of formats when not just placing for passthrough.

Yes, sorry, I was confusing. I misunderstood what you had done: I thought that you had created COLRv0 table instead of an assumed COLRv1 table, and totally lost the track and forgot that the original font was based on an SVG table. It seems that Affinity apps always export PAL/COLR based font as curves instead of embedding it, which does not much matter when exporting symbols like emojis, but is a clear minus when exporting alphabetic content.

Try exporting your PDF using PDF/X-3 or PDF/X-1a. Both of these formats will flatten the transparencies included in your placed PDF content, and should fix the problem. The problems other people are experiencing are related to print-time flattening of live transparencies. They often get flattened with miscellaneous issues.

In which way do you need to "fix" the scores? If you open a Sibelius-created PDF v1.4 file in Publisher, you need to have all Sibelius notation fonts installed on your computer to have Publisher render the text (and notation) correctly. If you place a Sibelius-created PDF 1.4 file in Publisher, and leave the placement mode at its default value ("Passthrough"), you should make sure that you also export using PDF v1.4 or later non-PDF/X-based export method, since all PDF/X-based export methods will rasterize non-PDF/X-based placed PDF content left in "Passthrough" mode. If you let Affinity app to "Interpret" placed content (which the "Fix" operation of Publisher Preflight does), you need to have all fonts embedded in the placed PDF installed and make sure that the fonts also get correctly mapped. Whenever you place PDF content for "Interpretation", you cannot edit the content, so if your intention was to edit the content, you need to open the Sibelius-created files instead of placing them. Note, too, that Sibelius files are in RGB color mode. You should ask your printer if it is ok to have them in RGB color mode (where black is RGB 0, 0, 0). This is important, since if you export interpreted ("fixed") placed RGB PDF content to CMYK, all RGB 0,0,0 content will be converted to four-color-black, which you probably do not want. When you export "passthrough" content, the original RGB color mode is retained (unless the content gets inadvertently rasterized), but this may be unacceptable to the printer who expects the file to be in CMYK color mode (and using K-ink only). There are ways to do a properly created K-only PDF export from a Sibelius RGB content, and it basically involves exporting to Grayscale color mode either Interpreted content, or opened content (or opening the content and converting everything to K100, and then exporting to CMYK). What needs to be done much depends on what you need to edit, and what your printer expects.

Yes, but only COLRv0 version of Gilbert (the font that you created). COLRv1 The SVG version shows the b/w fallbacks on canvas, but when exported to PDF (with Affinity v2 apps), embeds the font and the exported text stays as text (selectable/copyable, and searchable in the PDF, which may be important factors when using a color font that has alphabetic content).

One further thing that I forgot to mention: the feature where PDF export creates color versions of b/w fallbacks of an SVG OpenType color font, is Affinity app version 2 feature. In v1 version apps, exported fallbacks stay black and white. SVG exports, however, are rendered in color (at least in Firefox) also when exported from version 1 apps.

No, I ensured this now by first uninstalling the original Gilbert, and only having the v0 version that you created installed. When exported (tested from Affinity apps), the font is converted to curves (in my attached version above where I used both SVGv1 and COLRv0 versions of Gilbert, and the COLRv0 shows as if being Type 3, but I think this is false, but it is not selectable text, either)- So when checked in Adobe Acrobat Pro, no fonts are embedded, and the exported text is converted to curves (the font is not embedded in the your PDF, either): --while when exporting the original SVGv1 version of Gilbert, the font is embedded and the text can be selected (and searched) in Adobe Acrobat: gilberts.mp4 ...and when COLRv0 font is used in VectorStyler, text is encoded strangely, so when "Gilbert" is typed, the following is shown: These things do not happen with the original SVGv1 Gilbert, and as mentioned, this behavior is identical on macOS and Windows (and when the original Gilbert has been uninstalled). I was wondering if COLRv0 might have been limited in this way, not allowing embedding (but always been converted to curves), and also, if some apps, like Pages on macOS, might ignore COLRv0 versions and only support COLRv1 and up (because it does work with SegoeUI Emoji, which I assume is COLRv1)? VectorStyler false encoding seems to be specific just for VectorStyler.

The bottommost version in the PDF is an export from COLRv0 Gilbert and the topmost from the SVGv1 version. The upper version can be selected as text and the lower version cannot. I am not sure whether "Type 3" is correct, because in other instance the v0 version of Gilbert (v0) exports as curves: gilbertv0.pdf I also noticed that in VectorStyler (macOS and Windows) there is something wrong with the encoding ("Gilbert Color SVG OTF" is the text typed in here): I also noticed that In Pages the v0 version of the font is not listed in font menus, at all. Do you know if these are something that can be expected with v0 version? Or could these be results of having v0 and the SVGv1 version of Gilbert Color (even if with different full name) installed on the same system?

Is it this that causes export to Type3 (not selectable glyphs / text) -- vs. a situation when exporting the SVG versionCOLRv1? colorfonts_example_v02.pdf