lacerto

I had a closer look on this, and the linefeeds are not actually stripped, but simply just do not take effect. So my assumption on them being stripped to avoid issues in processing text streams was wrong. So, in version 1, this is what happens (CR = control code 13, hex OD, would probably work on macOS, while LF = control code 10, works on Windows), both in actual text boxes and labels previewing data in the Fields panel: ....while in version 2 (this, too, from Windows), the line feed codes are clearly part of the text stream but just do not have the line feed functionality: As shown above, the LF control code, when entered manually in a text box, still works fine, so it seems to be a deliberate act of ignoring the effect when line feeds are part of the data merge feature. Perhaps it is some kind of glitch, after all.

I think it has been reported. Hard-coded LFs and CRs might be something that cause problems e.g. within CSV files so maybe they are now deliberately ignored/stripped (earlier they were not).

As you have "Points" in the initial screenshot of your post [implying that a PDF file might have been opened for interpretation], I'll show one scenario where this kind of RGB-CMYK confusion can easily occur. It basically involves placing an RGB-based PDF for passthrough in a CMYK document and exporting it to PDF. One might imagine that this results in a CMYK converted colors, as it would do when doing a similar thing in InDesign. But in Affinity apps an RGB based PDF would be passed through as an RGB file even when creating a CMYK export from a CMYK document (and disregarding the value of "Convert image color spaces"). Perhaps your printer has been seeing something that was produced like this? Your posts, however, might be results of your checks, performed by opening the original RGB based PDFs in Affinity Publisher (or any other Affinity app) -- thus interpreting the contents. If you open an RGB file in a CMYK document, or later switch an RGB Affinity document to CMYK color mode, and then export to CMYK PDF, the resulting PDF will be in CMYK mode (as your posts are) -- all RGB 0, 0, 0 blacks (e.g. in barcodes, that might initially have been monochrome bitmaps, which in Affinity apps will be converted to 8-bit RGBs) will be four-color blacks -- as they are in your post attachments. cmyk_export_still_rgb.mp4 I am not saying that this is what has happened, but just showing one explanation for issues that are frequent on this forum. Having a tool like Adobe Acrobat Pro (perpetual license or subscription), pdfToolbox (more expensive, but operates on multiple platforms with the same license), or in a more limited way, PackzView (free but license only given for professional use), is highly recommended...

Data Merge no longer recognizes any line break input (Excel-based, or hard coded Chr(10) or Chr(13)). The only workaround I know is using any custom code, e.g. <br> and then use Find Replace in Publisher to replace occurrences of <br> with the desired line break (e.g. both line and paragraph break are supported as codes in the Replace box).

While syntax highlighting works in Visual Studio 2022 for Mac (without needing to do anything extra), I was wrong to assume that formatting would be copied onto Clipboard on the macOS version of the app, as it is (by default) on Windows version. It is NOT, and the feature is not available on the macOS version of the app. Visual Studio is also quite limited, especially on macOS, because language support is poor, so using Notepad++ (as I did on the video clip above) would be much more versatile and powerful. On macOS using Xcode would probably be the best (free) choice to get syntax highlighting in a page layout app. Note, though, that e.g. Pages supports HTML formatting so it would be possible to use VS Code and copy its language specific syntax highlighting onto Clipboard and paste it formatted into Pages..

The issue with VS Code is that its syntax highlighting when copied onto Clipboard is HTML formatted, not supported by Affinity apps. On Windows there is Notepad++ (free) which can copy formatted, syntax highlighted text either in HTML or RTF, and it supports dozens of languages. RTF formatted text on Clipboard is supported by Affinity apps (as it is in most other page layout apps). As for macOS, Visual Studio (available up to 2024) is free and also supports RTF format when copying syntax highlighting onto Clipboard. formatted_code.mp4

I have never done anything directly related to packaging (if custom CD-ROM/DVD covers do not count), but perhaps they scan VAT registers, indicating true professional activity, and public company registers implying involvement in the field of graphic design (e.g., in Finland, there are public codes that indicate this). I do have a nominal company web site, too (even if using national suffix), so that might be something that they check, as well.

I am not sure if I understood your question -- certainly everything 32-bit still runs on all 64-bit Windows platforms, including Adobe Acrobat X, etc. There might be occasional glitches with activation when running modern CC-based subscription software concurrently with legacy perpetual license based Adobe software on the same computer, but these kinds of complex situations can still be resolved either by cleaner software provided by Adobe, or live, by help of their chat support personnel. The actual issue, and reason for incompatibility, is basically Apple, not Adobe. [EDIT: As for Adobe, I have understood that actual activation support is only available for CS6-based apps; this, however, is not a technical limitation based on Windows, but an Adobe-chosen restriction.]

It is a possible cause, though I do not understand why it should happen (which is of course just a "common sense" argument, and ultimately based on ignorance). The issue is there also when producing PDF/X-3 based exports (from Affinity apps), so whenever transparency flattening is forced (and within Affinity apps, this only happens when using PDF/X-1 or PDF/X-3, as plain PDF 1.3 that would do that, is not supported). As for PDF/X-3, supporting mixed color spaces (and basically allowing generic ICC-based color processing and multiple embedded ICC color spaces), complex situations can arise, but within PDF/X-1, everything should be resolved already in the source and nothing left for interpretation so basically having a profile intent -- even if an erroneous one, as with recent Affinity apps with strange misspelling and false MD5 hash tags -- this should "in principle" be irrelevant for rendering, because only native color values should matter. But I am definitely out of my breath here, so I am reasoning just based on comparison with what works, so as you mentioned, perhaps Adobe software, and more generally RIP software, even if not by Adobe, safely just drops something that does not make sense, like references to non-sensical, misspelled ICC profiles.

I have tried to compare the internals of the two PDFs that you provided, but not with results that show any obvious difference that could explain the anomaly in PackzView. I was suspecting that there is some difference in use of mask when knocking out the shadow effect, which could explain the strange omission of the shadow and the black plate in PackzView rendering, but the only difference so far I have found is that the name of the intent ICC profile, and its MD5 hash tags, deviate from each other in these versions. -- Which basically IS odd since the profiles are supposed to be exactly same. The size of the transparency flattening (rasterization) is also different: 733px vs. 730px. These are screenshots of PDF/X-1a verifications run in Adobe Acrobat Pro 2020, both files passed through without errors.

I have a bad habit of editing my earlier posts, but as I mentioned above, I tried to reproduce the issue in 2.1.1 (macOS) Affinity Publisher Designer with the file you provided, but could not produce a similarly crippled version with an issue with the shadows. As for "transparency" and "overprint", I merely quoted Adobe Acrobat Pro information as for lack of these properties in the referred production file showing the issue. So it might be something system/hw-dependent (but probably not a specific setting) that causes this, but for some reason only shows in PackzView (and might be a trivial view-only issue, as you hoped). I have experienced a couple of other problems with the latest versions of PackzView, and these, too, were such that do not show in Adobe Acrobat Pro. Have to look back my recent posts to check if it might have been something related, and which could help explaining also this anomaly. UPDATE: Sorry, I examined poorly your production file, and now that I created a PDF/X-1a:2003 file with defaults from Designer 2.1.1, can also create consistently this issue. I have not been able to pinpoint the difference, yet, but perhaps it is related to compression. Anyway, the file with issues passes without errors Adobe Acrobat Pro v2020 PDF/X-1a:2003 verification test.

I think there are issues with latest versions of PackzView: As you can see, it fails to show the shadow, and the black plate. The files show identical in Adobe Acrobat Pro 2020. Neither file has overprints or transparencies, and both are DeviceCMYK. EDIT: Something has changed, though, because the file produced by an earlier version still shows correctly. EDIT2: I cannot reproduce the issue from macOS version of Designer 2.2.1. Perhaps there is some specific setting that causes this? OR: Hardware (display), OS specific issue: I am running macOS Sonoma 14.1.1 in native Apple Silicon mode, no disabled performance settings.

As suggested by @kenmcd, this is likely a result of having multiple fonts with identical names installed on the system. Especially legacy Type 1 Gill Sans (from Adobe Font Folio 8, supplied by "Monotype"), and Apple supplemental TrueType versions (supplied by "Agfa Monotype") have fully identical names: Gill_Sans_Multiple.mp4 Without a name conflict, embedded TrueTypes with sub sets (Apple version) should appear in Acrobat font list with their trademark names (specifically with PostScript names, e.g. GillSans-Bold), instead of generated names. Using trademark names in their supplemental fonts, and thus preventing installation of [or more accurately, proper use of] commercial versions of these fonts (often from the same manufacturer), even when Apple supplementals are hidden and cannot be accessed, is a common issue on Macs. Gill Sans, however, can still be accessed up to Sonoma, and commercial OpenType versions now have additional IDs like Gill Sans MT (basically still the same font from Monotype).

Sorry, I did not check the results. It seems that to achieve what I tried, a specific fixup including embedded files should be used, instead. But as confirmed by your printer, there is no reason for this, as the job is basically DeviceCMYK, despite the apparent conflict with the sRGB blending mode shown at the top of the job. I could not see any significant difference between the files provided so if there is any, it is probably just a viewer-related difference and not significant in production.

Yes, this is what Affinity apps do. The only way that I know that can deal with this from within Affinity apps, and have the shadow effect, too, in DeviceCMYK color space, is exporting using PDF/X-1a, which both forces CMYK and flattens live transparencies (Affinity apps basically always flatten by using rasterizing). Forcing PDF/X-1a, however, is not necessarily a good idea as that easily causes rasterization of placed PDF images. As you seemed to have random RGB based images in the example projects you included, it does not seem that the printer requires strictly CMYK only. Basically your job also IS CMYK-only even if the added image causes sRGB-based blend-color space on top of the job. I do not think that this causes problems, if you choose to NOT embed any ICC profiles (embedding them is the default), as then there is no risk that false readings of translated colors (caused by including ICC profiles in situations where they are not needed, as here, when you want to pass through native color values without any ICC translations, and have everything in CMYK) confuses the printer. Btw, I think that it is ultimately the blur of the shadow effect that causes sRGB blending color space on top of the image. I thought it could have been the transparent background of the new PNG image, but I replaced it with a CMYK TIFF with white background, assigned with the document US Newsprint profile, clipped to a circle using a native ellipse shape, but that did not avoid the issue. I also tried if turning off Layer FX Outer Shadow and producing the blur with Live filter Gaussian Blur borrowed from Photo Persona, using K100 (instead of RGB based black), to make the shadow similar as the other shadows in the ad, but that did not have the desired effect, either. It is precisely this effect (RGB based blending color space covering the whole job), combined with the default setting of embedding ICC profiles, that causes much confusion, and false readings in apps like Adobe Acrobat Pro. Affinity apps do not allow user-defined definition of blending color space (like e.g. InDesign does), which would avoid the issue. You could fix this by using Adobe Acrobat Pro (see below), using Flattener Preview and choosing DeviceCMYK as the blending color space. 2. Aff rast unsupp to show drop shadow WT SNAP2007 INL_557 - TYM TS25 WT.pdf

It might be that what the printer wants is to have a DeviceCMYK print file with explicit color intent. The fact that the job seems to be based on PDF/X-4 standard additionally suggests, that possible live transparencies are wanted to be retained. To have a similar output using Affinity Publisher, you would first need to ensure that you have the document CMYK profile set to one suggested by the printer. So for coated paper, PSO Coated v3 and for uncoated paper, PSO Uncoated v3. If you need to change the profile, use File > Document Setup > Color, and either the Convert option (if your current definitions are for clearly different media), and then ensure that you have text that you intend to print in mere black ink changed back to K-only (as they would be four-color black after conversion); or, use Assign method to keep all current color values. After you have the correct CMYK document color profile, use the following export settings: a) Compatibility PDF/X-4 forces use of color intent (which the printer obviously wants). It also retains all live transparencies of the document. b) Color Space As document, keeps the PDF color space as CMYK (meaning that all native shapes no matter whether defined in RGB or CMYK will be converted to CMYK). PDF/X-4 does not require this, but as the printer instructed this, it is obvious that they want to have CMYK output. c) ICC profile: Use document profile means that the PDF target profile will be the same as the document has: e.g. PSO Coated v3. In InDesign, you can change the color profile at this stage without causing conversion of CMYK color definitions, but in Affinity apps you cannot, so therefore you need to ensure that your document CMYK color profile is the same as that of the exported PDF. d) Embed ICC profiles. This is a setting which you cannot change, but it will be irrelevant, because you are going to convert everything to target CMYK, that is, make a DeviceCMYK PDF, which is no longer ICC dependent and does not need to have profiles embedded. So there will be none included. e) Convert image color spaces: checked. This converts the placed images to target CMYK, and leaves no alternate color spaces in the document. So, you will essentially produce a Device-CMYK document that has no ICC profiles embedded (because none are needed), but the correct target CMYK color profile intent declared explicitly (for whatever reason). You can tell this by using preflight apps like Adobe Acrobat Pro: Why the printer wants specifically this kind of file, is not obvious, but as far as their InDesign-based specs are correctly given, the instructions shown above will produce what the printer expects.

But what happened with this? Was there some problem with images when they were made to 8-bit using this method? Without knowing the standard workflows of the printer, I cannot understand why they do this, but generally converting to target CMYK would be a standard procedure. I assume that they are trying to resolve the problem by manipulating the production PDF file (that is, using e.g. Acrobat Pro to convert to 8-bit RGB, or reducing the file size, etc.), which are both standard procedures in Adobe Acrobat Pro, so perhaps there is some more fundamental issue that continues to be a problem? If you wish, you can tell more about the project and the printing specs using a private message (available by clicking a poster's icon) if you do not want to share this kind of information in public.

Ok, but good that they are willing to find a solution. If one ends up in a situation where the job is simply just rejected (possibly by an automated flight checker), the worst scenario is that the whole project needs to be prepared (at least partially) again. IMO Publisher does offer means to resolve the issue (without needing to edit/switch images) as it would be possible to convert images to correct CMYK space provided that the appropriate CMYK profile (and media) is known, or keep the RGB images and convert them to 8-bit by using PDF 1.4. But without knowing details and printer requirements, this is just an opinion. I hope they manage to resolve this in a way that is fully satisfactory to you...

This is totally dependent on the printer. I do not know whether it is possible for e.g. a laser printer to print to the edges of the paper, but it certainly is for e.g. many inkjet printers: For commercial printing, one would need to add bleeds (typically with crop marks) and then the job would be printed on oversized paper and trimmed to the desired width and height.

I am not sure if PDF Expert has any more functionality in the Premium version of the app, but the regular version that I have only "compares" without any intelligence two PDF documents by placing them side by side. The only other app, besides Adobe Acrobat Pro, I know that can do useful comparisons, is PDF/X-Change (Windows only), but e.g. its image comparison does not cover attribute changes: Otherwise its comparison features are pretty much copied from Adobe Acrobat Pro: Whether PDF comparisons are useful, much depends on the kind of a document that is compared. For long texts I still use the method available in InDesign, which allows story-wise export to formatted RTF documents. That includes e.g. footnotes, as well, and when having e.g. captions also in one story, this method makes comparison of long documents using Word or LibreOffice document compare feature fast and effective. For very complex documents having text parts in independent stories, I use a script to collect page-by page in user-defined order style-tagged texts which are copied with page references into a new document. This would then make it possible to extract captions, table headings, footnotes, etc. as separate text elements and compare them to original texts (including local formatting like use of italics).

If you're on Windows you can "OCR" by using PowerToys Text Extractor.

An alternative option being of course a confused reading (especially when using Adobe Acrobat Pro), caused by embedding an ICC profile in a job where CMYK values are already resolved (DeviceCMYK). Your screenshot implies that you have (correctly) used the document color profile (and NOT an export time profile deviating from the document profile, which always results in recalculated CMYK values of native objects defined in CMYK, e.g. a K100 black being converted to four-color black). BUT, the same screenshot also shows that you have not disabled the default option "Embed ICC Profiles", which makes the export PDF ICC-dependent, even if there is no need for print-time calculations. This means that anyone using Adobe Acrobat Pro using an incorrect simulation profile to review the color values of the job, would get ad-hoc translated values, instead of native color values of inspected objects. I have no clear understanding on whether this kind of confusion might actually result in having recalculated color values printed on paper, but it might, either by causing confusion in print personnel (as might have happened in your case), or resulting in wrong interpretation in RIP software (confused by mixed color spaces included, without explicit output intent profile). Therefore I would recommend checking the "Convert image color spaces" option, and unchecking the "Embed ICC Profiles" option, as this would produce pure DeviceCMYK output (similar as InDesign and QuarkXPress do when using standard press exports), not needing any embedded ICC profiles. If it is important to leave placed images in RGB color space, it would be a good idea to use PDF/X-3 or PDF/X-4 export methods, instead (which would embed all relevant ICC profiles, and intent profile, as required, for print-time resolution).

For some reason the reinstaller did not offer Sonoma. I'd have chosen that if offered. But after a direct upgrade from Ventura, no disk space was lost for the upgrade. I do not know where I had lost all that disk space but now I am basically back in a situation where I was three years ago, having about 150GB free disk space. It took me 3 years to waste it, pretty much the time Apple thinks one should spend money for a new mac 🙂 Really, no clue on what the now saved 140GB were wasted, but there is no way a cleaner could have done the same! Just to encourage someone in doubt to do the same -- just a few hours spent on the job...

It of course depends on the workload, and personal needs and preferences, but I tend to agree... I have had MacBook Air entry level M1 2020 with 8GB RAM and 256GB SSD now for 3 years. I recently got into a situation (after having upgraded to Sonoma) where I had only 10GB free disk space left and did not want to install a cleaner to mess around my system, even cache files. I backed up all on a portable SSD with Time Machine, did a clean reinstall using Ventura, which I immediately upgraded to Sonoma 14.1.1, and had about 220GB free disk space after having finished, just a couple of hours later. Now I have installed all apps back (including Affinity and Adobe apps, a bunch of other graphic design apps, VisualStudio and Xcode), and the most important documents, and have about 150GB free disk space. I already checked what I'd get for this "toy" if I trade in to a new Apple laptop: EUR512 (EUR 362 for the computer, and EUR 150 as an Apple trade in offer), so I'd basically only need to pay about EUR 600 to get a new M2, or about 800 more for an entry level M3 Pro. I am tempted, but might be able to resist 🙂 I am just writing this to let you know that you can get a well performing computer for graphic design at about EUR1,100 that you would need to pay for an entry level M2 laptop (or Mini) and keep it for years, or trade it in after a few years and still get a good price. If you really do not need a high-end super computer, settle with something more reasonable and more suitable to your budget!

At some point snow overlays were also a free asset (might have been version 1 gift, though), but worth a check at Help > My Account: