lacerto

This RegEx borrowed from InDesign forum replaces Body Text formatting (with first line indent) with Body First formatting (no first line indent) for first body text paragraphs the first time it is applied (next time it would replace the second body text paragraphs with Body First, then the third ones, etc. firstpara_regex.mp4

If there is a preceding formatting that determines the use of the following non-indented style, a regular search replace could be used to apply the required non-indenting paragraph style, like below, where "Body First" is applied after Heading 1 and Break styles. In apps like InDesign and QuarkXPress scripting can be easily used (and saved for future use) to do things like this so perhaps this explains why there are no special "flattening" styling attributes. firstpara_search_replace.mp4 As Publisher does not support scripting, you'd need to do these sorts of things manually but it would nevertheless be faster than going through the required paragraphs one by one. Btw, it is possible to apply "Paragraph Style, then Next Style" to format text blocks with multiple styles, but this does not much help here (you could apply e.g. a heading style and "Body First" in one go, but it is still slow).

But seems to be available only in macOS version (or might be a glitch there).

There is a non-subscription-based version of Adobe Acrobat Pro available, too, although I suppose that being able to subscribe just on demand (e.g. for a month) could be seen as a benefit for these kinds of tasks. Usefulness of a PDF comparison tool much depends on the kinds of documents compared (and what is compared, text only or other changes, as well), and the kinds and amount of changes between the versions, but the tools I mentioned can be very efficient (and are light years ahead of free tools). Word itself does a good job, but if the starting point is a PDF, conversion to Word is typically the weak point, and to do that well, a proper non-free tool might be needed, too (Word itself also being subscription based). If previous versions still exist as Publisher documents, it might be worth a try to just copy paste text from Publisher to LibreOffice Writer and then use its document comparison tool to track deletions and additions between two versions. But that would work only for simple document structures; if there is need to compare text in separate stories (e.g. captions, independent text boxes, etc.), direct PDF comparison is the way to go.

No. Adobe Acrobat Pro/DC itself has this functionality (ability to compare two PDF documents). If you're on Windows, you might want to consider purchasing a license for PDF/X-Change Editor, which can do this, as well -- it does not cost much, it is perpetual, and the app itself is full of useful, well implemented features.

You can use the Table panel to help you spot non-gray cell backgrounds (and stroke foregrounds), like here on page 73, as the Panel shows color definitions in true colors also when working with documents using Gray/8 color mode:

I do not think they are. But there are numerous posts on this forum that show that Publisher somehow embeds images (resulting in strangely increasing file size) even if they are linked. Perhaps something goes wrong in this kind of caching operation and these cached versions of files will be used when exporting, instead of accessing the original linked files. Anyway, it is worth a try to do that auto-re-linking of images using the trick described. I guess that in the core of these problems is the confused way Affinity apps handle grayscale, indexed and monochrome images. If you have a look on Resource Manager having your document open, there are numerous images that are reported to be "Grayscale", yet have sRGB profiles embedded. These are all actually RGB JPGs and just tagged as "Grayscale" when the document was determined to be opened in Gray/8 mode (or perhaps it was initially CMYK/8 and the mode was switched afterwards). Some may have initially been paletted images with gray values, some might have been monochromes. Neither are supported in Affinity apps and will be converted to RGB with equal color values producing gray. When you have RGB files with equal values (producing gray tones) in a Gray/8 document and intend to produce pure gray, you need to force Grayscale color mode at export time, and also check "Convert image color spaces" to make sure that placed RGB and CMYK images are actually converted to grayscale. In a similar manner, if you place RGB and CMYK images (with non-neutral colors) in a Gray/8 document, they are shown to be "Grayscale" on the canvas and in Resource Manager, but will typically be exported in true colors, even when exporting to gray color space, unless image color spaces are forced to be converted using the equivalent export setting. Conversely, when you have a CMYK document, all grayscale images are actually auto-tagged with "K-Only" attribute when placed (the attribute can be controlled using a toolbar button with this caption), to be handled as grayscale images and exported correctly when exporting to CMYK. If the flag is turned off, the images are handled as Affinity apps natively do, as RGB images, which results in the grayscale images being converted to four-color black when exported to CMYK modes. "K-Only" is available also for CMYK images, in which case only the black channel of the image will be shown and exported, when exporting to CMYK. What's more is that these flags will be left on or off if and when you change the document color mode, without having the attribute controls visible any more, and accordingly continue to cause confusion without any visible clue of the reason. I have personally not found TIFF images being handled differently from JPGs so I think this is equally confusing when working with TIFFs.

This is what I get, at least on page 65: I guess there are at least two ways: a) by replacing and choosing the same file (tedious, and I am not absolutely sure that current crop and sizing, if any, are retained), b) by moving the linked files away from their current location and then, when opening the document, answering yes to relocate the files in their new location to have Publisher auto-relink to existing files with the same name. I think that Publisher keeps multiple versions of placed images embedded in the document even if they are supposed to be linked. No one really knows why and how this happens, but somehow it seems that the previous states of these files could "explain" what you have experienced here. If you have not, yet, I recommend that you make multiple full copies of your publication as you keep on finishing it, and keep them in safe place to be able to revert to a previous version should your most recent version become corrupted.

The linking status might be inaccurate. When I opened the package, there were about 20 images that had "Modified" as linking status and when updating, refreshed the blurred images that were initially showed. Those operations probably guarantee that whoever exports based on your package, will not experience similar problems as you have experienced (with partially faded/missing colors/tones). These cells have Y100 M100 color definitions and then 40% opacity, while cells that have kept their gray outlook have 50% K and then 40% opacity value. I have no idea why PDF/X-4 does not make them in color but instead is affected by the "Gray/8" document color space (yet exports K values as four-color black), while PDF/X-1 and X-3 make them in color. I also cannot explain, why the resulting cell gray in PDF/X-1 and PDF/X-3 seems to be K20 (and not a percentage value of a four-color black, as it is in PDF/X-4 export). Anyway, I suppose that the intention is to have all the gray cell backgrounds defined in the same tone?

If you do the Boolean operations by holding down the Alt key (to produce compound objects), you retain editability of elements (including text) even if when exporting, the text objects used in Boolean operations will be converted to curves. When you use blend modes, the involved objects will always be rasterized (and if you prevent that by using an export option, you will lose the blend effect, as when using "Erase", nothing will be erased but the text object on which the blend mode is applied, is simply just converted to curves). sticker sketch 2022_fixed.afdesign

There might have been a problem with the update status of the linked images, since I did not have problems, either, to get e.g. the referred "bowl" image grays to display ok. But there is a major problem with the document color space (Gray/8), definition of body text black (K100), and intended export method (PDF/X-4). If your goal is to produce pure grayscale, you cannot export using PDF/X-4 as that forces document colors to CMYK (in this case the K100 of body text becomes four-color black). On the other hand, if you export forcing Grayscale as export color space (as you should when your document color space is Gray/8), the black of the text should be defined as Gray 0. If it is K100, it will be converted to RGB according to underlying color profiles and will in context of forced Grayscale export have a dark gray value of 0.15 (equivalent to K85). So as it is, with current specs there is no way to produce pure black however you export the document. To correct this, you should either change the document color space to CMYK and keep K100 as body text color, make sure the K-Only button is turned on in context of all imported grayscale images, and export to CMYK using the document CMYK color profile. In this scenario using PDF/X-4 is fine (as would any other method that exports to CMYK). OR, if you want to keep the document in Gray/8 color mode, you should change the body text black from K100 to G0 and then make sure that you export using PDF (press ready) and force using Grayscale color mode (you can additionally force conversion of color spaces but this is probably not needed as you seem to have imported images in grayscale -- EDIT: Several are in RGB color space so this option really needs to be used).

Thanks for further information. Yes, this seems to be correct. I also tested other RGB profiles (Apple RGB and Adobe RGB) using ProPhoto RGB as the source image color space and they do cause change in Soft Proof adjustment, so this could really be just the standard sRGB-profile related issue. I'll make some comparisons with other software to see if I get identical results there. N.B. I ran the tests above on Windows (11) and assume that the default sRGB profile came with the system (but will check this -- EDIT: yes, it is one that came with Windows 11). UPDATE: After some initial tests, I seem to get identical results with the 2014 sRGB profile when using Photoshop (2022), and as this is a v2 profile it should be safe to use it in place of the older v2 profile, so this really appears to be a good work around. There might be point in using it also as the replacement of the default sRGB working profile in the Preferences.

I am not sure about the point of elaborating discussion of something that I assume is already acknowledged as a bug or a feature omission, but as the attachment in the OP's post was poor in illustrating the issue of the topic, and the issue referred on Adobe forum was different (related to an illusory problem of not seeing difference between the soft proofed and the converted image, which there naturally does / should not exist -- unless working with Affinity apps where soft proofing with non-media based ICCs like sRGB simply does not work), here is a clip that shows the issue of the topic more clearly (though using a larger-gamut ProPhoto color space as the source, rather than Adobe RGB, to accentuate the difference when comparing with the expected behavior as shown when soft proofing in PS). To be able to reproduce the problem, the user should have a system that can display larger than sRGB color gamut. softproof_srgb.mp4 The color space of the clip itself is truncated but the relative difference in behavior can still be clearly seen. In a nutshell: the expected behavior is that the Soft Proof adjustment previews a different (lower) gamut color space as reliably as possible and that the preview matches the actual conversion. As mentioned in many posts before, Affinity Soft Proof seems to be useful only in RGB based workflows when targeting to lesser-gamut ICCs involving specific media (though lack of paper simulation and dithering options make it less useful than color proof of PS). It does reflect the change of color space also in context of CMYK workflows but the simulated output can be far away from the actual conversion, and is of little use because Affinity apps provide much better CMYK "soft proof" internally when having the document designed and viewed (but containing color definitions made in non-target, larger-gamut color spaces) in CMYK color mode.

If you are on Windows, you might want to have a look on the free G'Mic plug-in, which has a number of degradation filters, including this CRT sub-pixel screen generator: crt_grid_gmic.mp4

Additionally, please note that to have the note extracts placed as inline images to auto-adjust the leading, the leading of the paragraph where the image is placed needs to be defined in percentage value (as you have done in both paragraphs that will have inline images) -- (7,2 pt). If the spacing above and/or below inline image is not ideal, you can adjust it easily by using the vertical shift (in Character panel), and space below and after settings (in Paragraph panel). autoincreasing_leading.mp4 As your body text has fixed leading of 14,4pt, placing a note extract as an inline object anywhere within body text would not automatically make room for image so there you would need to use other methods, like using local overriding leading (Character panel), or keeping images as floating objects and then using image wrap options to wrap the text.