Lorox

Like @Alfred's hint to Find & Replace this may be an OK enough way to deal with the issue when you have not so extensive files with just a few instances of missing fonts. It will help you out then, I guess. And yes: sometimes you will want to check where exactly one or the other of those missing fonts are used in your document and only then decide on whether or not substitute/replace them. My initial complaint, however, stemmed from my experience of being an InDesign user for many years and thus being used to ID's simple "no fuss" way of being able to – documentwide – just assign substitution fonts for missing fonts found while opening a file (or at any time via a missing fonts dialog). Applicable usage cases might be replacing an OS provided version of – say – Helvetica with a third party „Helvetica New“ or replacing an older TT version of a font with its more recent OT version. In ID a thus substituted/replaced font became the "officially" assigned font for any related text element in the document once you saved it. As this is exactly what I normally want(ed) in such a situation I've always appreciated this way of dealing with it. Obviously, it might also be helpful if you could make yourself to consistently apply custom text styles (character and paragraph) to all of your text elements. Having set up (and actually applied…) these you could simply change (and thus substitute/replace) any font documentwide later (be it actually missing or not) just by editing the text style it's used in. But then again, this might not work with documents you'll receive from other users who maybe don't like to use text styles at all… and honestly: even against better knowledge I myself tend to just format individual text elements on the fly more often than not when in the more artist/designer mood (as opposed to the more systematic "production" mood)...

Another thing I wouldn't have thought of… Thanks for pointing this out!

@lacerto Thanks a lot for your interesting take on the Noise subject. I wouldnt't have thought of going to the Live Noise Filter in the Photo Persona under these circumstances – it's certainly worth a try in the future!

@lacerto Thank you very much for your insights! Actually, those four RAL color swatches in the "HH Grautöne RAL-like" palette had been created first according to some info about the (approximate) CMYK values of several RAL-colour tones. And yes: according to the charts which I had consulted, the last in line of these swatches ("RAL 9007 Graualuminium") should be just 60%K and nothing else. However, the guy at the printer’s was a bit anxious that a larger flat area in the "design"printed as monochrome tint of just ONE printing colour (K here) might be more delicate and any subtle flaws (should there be any) e.g. with the printing head for K might possibly result in visible "scanlines" or the like whereas an area of grey colour mixed from all 4 CMYK colours might be not so easily damageable. So I created – just visually – a full CMYK equivalent of that 60K tint (resulting in 23/19/18/45). However, I forgot to add it this version as an extra swatch to my "HH Grautöne RAL-like" Document Palette and just used that mix directly on the square behind the number... To further make it a bit more "fuzzy" I later added 50% Noise (with that slider in the "Colour" Palette) to it (the square, that is). [Aside: Those 2 "pre Noise" versions of the colour – K only and full CMYK – are visually undistinguishable on my system, in Publisher as well as in e.g. PACKZVIEW. Also in Acrobat Pro on my old iMac. Provided, though, all apps are using the same CMYK color profile. If you add that 50% Noise the two versions of the colour will look a bit different – but I guess that should be expected given their different "mix"! In "Preview"(not using profiles?), however, there is a visible difference, even with no Noise added.] Supposedly simple things can obviously get quite complicated… Anyway: as those different print runs which I mentioned have been done with the very same PDFs of the files (which, as we have seen, eventually even have that grey area as a rendered and identical image in them) it still seems strange enough that the colours in the prints should visibly vary on each iteration and PDFs which printed this way the first time print differently the second time. I cannot quite see, what influence anything that has or has not happened before outputting the PDFs in Publisher should have at this point in the process… It's the same PDF that's beeing printed and yet the colours differ! So meanwhile I really tend to think – as I said before – it's probably something with the printer itself (or its RIP).

Yeah, I actually could have thought of that… And yes, the rectangles with that grey Noise fill have obviously been rendered as images to their respective PDFs. And: when I copy one of those images to one of the other files and place it just over the image there in "Difference" blend mode it is showing 100% coverage (with just a bit of 99% flickering) in every single CMYK channel, which seems to prove that the images are virtually identical in each PDF... The original grey colour is 23C/19M/18Y/45K with 50% Noise assigned. I'm attaching one of the signs as .apub & PDF. As I said before: the other .apub ones had all been derived/copied from such an original via "Save as…" with just the number changed each time. Meanwhile I almost tend to think that maybe there actually has been some issue with the (foil) printer at the printers' shop as in different print runs colours changed with different ones of the PDFs. When the grey images in the PDFs are virtually the same in any one of those PDFs I cannot see why they should print differently were it not for some flaw in the printer itself (or its RIP). Sign_0_180x180+3_grey-NOISE.pdf Sign_0_180x180+3_grey-NOISE.afpub

Maybe someone can shed a light on this: I recently had some files for a signage project printed and my printer encountered mysterious problems because one of 5 signs showed a slightly but noticeably different shade of grey as its background when printed than the others. The grey in question was a CMYK fill (consisting of all 4 base colours in different percentages) with a 50% Noise in the colour stettings. However, all 5 files had been laid out totally the same – in fact the element containing that grey fill had been the "same" in all of them (just handed on via files created by "Save as…“ from the original first file. The first thought had been that maybe one of the files had been damaged/corrupted in one way or another thus producing a different shade when printed, but when they printed all files again, it was a different one of those 5 files than before which was printing a different grey than the others. So far my printer is clueless as to what may be reponsible for these inconsistent results from basically identical files/elements – they said they never had encountered something like this before… Is there a possibility that the process of random generation of "Noise" of a certain percentage on a fill is somehow preserved in the PDF used for printing? Making the RIP produce slightly different shades in different print runs? I actually would have thought that these "Noise" fills were rendered as rastered pixel content when exporting to PDF… or don't they?

Exactly. One wishes, though, the guys at Serif would take a closer look at it as it's got quite a few features we'd love to see in AD. (And it's got those for ages as it seems…)

Every now and then I tend to feel a bit sorry about not having given Inkscape more attention – the app has so many features we've been waiting for forever as Affinity users. If it weren't for Inkscape’s often (at least for me) cryptic UI, it being RGB only and its long time sluggish performance on Mac I'd certainly be a somewhat regular user...

I actually noticed that effect when I first experimented with exporting those supposedly balanced dashed lines to PDF. With open paths the first and last dots seemed to be more or less mangled. Sometimes dots on sharp corners also looked a bit "funky"...

Me, too! The aspects you’re listing are definitely worthwile. I remember that I always liked to use the ”(Pixel-)Stroke on path“ function in Photoshop (maybe that's kind of what you're hinting at with your 3rd point). According to my experience being able to actually combine advantages of vectors and pixels on the very same object in a design often opens interesting creative ways.

Yeah, actually the preview does look OK but the output PDF is definitely lacking the "Balanced Dash" setting – it's positively gone when you open the PDF again with Designer and take a look at the stroke panel… I'll attach the PDF here. corner_dotted-line_balanced-dash_designer-vs-pdf_2.pdf

I just found that post by @Hangman (posted March 14, 2024 in https://forum.affinity.serif.com/index.php?/topic/200826-pdf-export-of-dotted-line-different/ ) saying: "Balanced strokes up to and including 2.5 pt are being exported as unbalanced strokes". "Balanced strokes above 2.5 pt are being exported as expanded strokes". My stroke is 2 pt whereas GarryP's stroke is 5,9 pt – which might explain that his PDF is OK because of just that and mine isn't (and that the version of AD or AP might not be crucial after all).

Thanks to y'all – @Pšenda for pointing out via Google all those other posts concerning the issue and @GarryP for pointing to v 2.6 (Presently I'm still on v 2.5.6 and I'll certainly check again after updating my apps to v 2.6 – I hadn't found the time yet…). I'll attache a screenshot of my Export settings, nevertheless.

In principle you're right, of course. Nevertheless my understanding is that those users really needing 1-bit TIFF support do so because they actually want to (or just have to) use those high resolution bitmap files (for whatever reasons – but there most certainly are some which are totally legitimate). If they were happy with their 1-bit images just being converted to paths they'd probably already had chosen other tools available which can just do that (e.g. Inkscape) and then placed the resulting vectors in Publisher for final output.

I'm not sure if this (if you mean some sort of on the fly "conversion of 1-bit TIFF to path" to deal with it) will actually meet the needs (as to pixel perfet accuracy) of those users really needing the 1-bit feature.

Just yesterday I notice that while some paths with a dotted stroke looked perfectly (or as intended) in my Publisher docoment/file they didn't transport correctly to PDF at all making the option of a "balanced dash“ as offered in the stroke panel effectively useless… – please see the attached screenshot. What's going on here? Obviously it doesn't really help workflow-wise if for a workaround you'll have to revert to two separate strokes again which have to be carefully aligned at the corner... It will look OK, but that's not what we expected when we got the ”Balanced Dash" option, I guess.

It hadn't seen it this way so far, but once you think of it, this actually seems plausible. Even if you'd certainly like to have a couple of helpful options for best results with a decent tracing tool (as there are e.g. in AI) it's probably related as to its basic functionality.

Although I've meanwhile adopted some workarounds which sort of do the job for me most of the time, I'd rather agree: 1-bit TIFF is such a basic image format in prepress surroundings that Serif's "stubborn" resistance to add support for it to their apps is really annoying. And being forced to resave existing 1-bit TIFFs in another format to be able to keep using the image somehow isn't exactly funny.

As far as I see it – and with my settings for print production PDFs – the 300dpi grayscale photo image will be rastered at its original 300dpi (thus using its full visual information) and the 600dpi image (assumed to also appear at 100 scaling in the layout) will be rastered for output at 375dpi (as that is the threshold set in my PDF for print export setting beyond which images will be downsampled). Obviously some of the information present in the original 600dpi version that's originally been placed in the layout file will be lost in the process. However, as raster dots for a given print raster (say like the standard 60 lines per cm) can only have a certain number of "atomic" dots that are no more divisible (dependent on the RIPs resolution) and in relation to the chosen line density can only display/convey a certain range of tone (shades of Black with grayscale images) it is only natural that with an "oversized" grayscale image’s resolution the visual information present in that image can only partially be transported to the final print anyway. Accordingly there is a natural threshold of the (factual) resolution of grayscale and colour images which, when surpassed, will no longer yield any visible advantage/improvement of the quality of the final printed image. Also, finer rasters (say 120 lines per cm) are having smaller dots with less tone range, but there will be more of them in an area of fixed size as they are packed more densely – the smallest possible "dot" will be either black or white/nothing (i.e. having only 2 possible tonal values). With 1-bit-TIFFs – as far as I know – there used to be no line raster imposed over their internal pixel raster so any their pixels get assigned directly to a certain number/array of the pixels in the RIP's natural raster either as full ON (> Black) or OFF (>White/Transparent) – according to their position. I hope I haven't forgotten too much of what I used to learn about this (or tried to, at least…), but it's been quite a while since then. So anybody who might know better is certainly welcome to add his or her – possibly more present day – expertise…

Ah, sure… you're right. I completely forgot about that. So the PNGs will actually/generally be rasterized to the global resolution as set in the file properties dialog, whereas 1-bit-TIFFs as we knew (and loved) them by default had kept their "own" resolution as defined by their file and – possibly – their scaling in the layout. BUT: wouldn’t it be some sort of solution to just turn off the downsampling of images with a resolution above a certain value in the Export dialog? (Given you don't have any other "normal" big images which then would be left way too big in the PDF). My 1-bit-TIFFs in the InDesign days used to be about 1200dpi factual resolution as placed and (possibly) scaled in the layout file, which has generally been sufficient and not caused them to be perceived as jaggy when being looked at in a "normal" way. As to rasterization: I think back ih the day I've learned that actually ALL content in PDF gets rasterized eventually, albeit to the maximum resolution the RIP is putting out, which then used to be around 2450dpi. So anything with a resolution above that will be sort of downsampled anyway... (meaning, too, that in the printed result you cannot really see a difference between vector curve and a curve from a 2400dpi 1-bit-TIFF). Or am I getting something really wrong here?

I still do think 1-bit TIFF support (like we used to have in InDesign or – back in the day – in FreeHand) would be a nice and helpful thing to have. However, with a bit of hindsight I’d like to add that with recent designs/projects (even those basically being updates/redesigns based on IDML-files out of InDesign) switching to grayscale PNGs (using Affinity’s "K only" option) has worked pretty well. Of course, if you're working on a legacy file (like an IDML from InDesign) that has them, you'll have to convert your original 1-bit TIFFS to grayscale PNGs having just black pixels on a transparent background. Bu this is actually just a matter of seconds in Affinity Photo. When you leave everything else (size and resolution) as it was you'll then just have to "relink" the original 1-bit-TIFFs in your file via the Resource Manager to the new transparent PNGs (or by ”Replace Image" in the context bar) and you are good to go. At least this has so far worked fine for me...

No, I was saving (or at least tried to save) to my internal SSD. If I remember correctly "Save as…" produced the same alert when I chose another location on my internal disc (e.g. just "Desktop"). However, when I saved to another computer via LAN it seemed to work at first – but it turned out that Publisher could not open the resulting file... (said something like: "no valid [data] format"; can't really remember) As this all hadn't ever happened before in years of using Publisher I – of course – tried to think of what these specific files had in common: both were originally IDML files exported from InDesign, with both of them I initially had to relink up to 3 images and with both of them I had at one time exchanged/relinked 1-bit bitmap TIFFs (from the original InDesign way of doing things) to Grayscale PNGs (with transparent background) which were then assigned a CMYK colour in Publisher (using the “K only“ feature). However, in one of these Publisher files these PNGs had later been exchanged for native vector graphics, so there was just a regular linked CMYK-TIFF left. When that failure to save occured, I also copied the content from the affected file to a fresh Publisher document (which actually could be saved). Strangely though, I noticed that just by that copying all these elements the stroke width of one rounded rectangle had miraculously changed from 2pt to 4pt and the font size in one frame text element had also doubled for no apparent reason. Another thing: After copying the content from Publisher to a fresh Designer(!) document – just to try things out – literally all previous organisation of elements using groups and layers was completely gone and everything in the layers pallette was just basic curves, rectangles etc.. It was still looking OK, so all of the stacking order of things had obviously been preserved, but all the structuring, which had been there in Publisher, was gone. As the Affinity apps are said to have the same data format internally this has been a bit surprising to me.

I forgot to add that "Save as" – after that alert had appeared – didn't actually work neither...

I've recently been working on two files (both originally InDesign resp IDML files) in Publisher 2.5.6 (on Mac with Monterey) and after some time of making several tweaks I then haven't been able to save them and instead got the alert as seen in the attached screenshot. I had been able to open the files from their IDML versions with no problems at all and they were looking faithful to the InDesign originals as well. While working on them I repeatedly saved them as to save changes made so far. After exporting preview PDFs for my client I I finally wanted to save and close the Publisher files for the day but actually couldn't and the alert you see attached popped up. I had saved quite frequently before and after relaunching Publisher the files could actually be opened normally and could be saved (and "saved as…“) again as well. So fortunately nothing has been really lost. But it's quite embarrassing, nevertheless, when after working for some time on a file you get that alert when you want to save the current state... I had never before encountered something like this and I'm quite a loss for possible explanations. What's that "lock file“ the "control" of which had allegedly been lost, anyway?

You got to tweak the lenght of the stroke (especially the end node) and you have deactivate the „Balanced Dash Pattern“ checkbox aside from setting the phase to 2 (see screenshot). But it’s almost easier to replace the mutilated circles by hand than to fiddle with the values until it sort of fits… Nevertheless, your idea is appreciated!