Lorox

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!

I just encountered a problem with expanding „dotted“ strokes as I wanted to convert a diagram I created to a „fills only“ version not having any elements which feature just strokes. It turns out that with dotted strokes which have dots at their ends these „end dots“ are not expanded correctly but end up as semi circles or even more or less weird shapes (see attached screenshot). Obviously these dotted strokes are made using settings like those seen on the screenshot (especially featuring round caps and zero length for the „on“ phase). You can actually experiment with the length of that „on“ phase (e.g. setting it to 0,05 or 0,02 – being very careful to not visibly distort the roundness of the dots too much; a value of 0,05 already produces slightly oval dots), but then either the number of dots on the stroke changes affecting the original design (while actually being expanded correctly but of course reflecting that visual change) or (with very small non-zero values) expanding still creates that mutilated dots an the ends of the stroke... Any ideas what can be done? (except actually replacing weird dots manually with circles, that is)

Absolutely correct: working/designing with "true“ vector brushes still is one of those things which – from time to time – get me back to using my old pre-subscription-era Illustrator... Also true: "Sometimes you may actually want exactly this kind of tool." (i.e. PNG brushes) – yeah, sometimes I, too, do. However, when dealing with a dedicated and more or lesss professional vector design tool (even if that "branch" is only one of Designer's "personas"), you'd actually want true vector brushes in the first place. Personally I see PNG brushes as some kind of add on that's nice to have but true vector brushes should be paramount here – keeping resolution independent vector "uncompromised". I wonder, though, if these will ever come to AD as well…

I really do object. I've been using Designer and Publisher for several years now and I've been able to create numerous layouts (mainly for print) that have turned out perfectly well having been produced by professional print services. The results have actually been excellent and they are definitely no worse than anything which I previously had been used to do in e.g. InDesign. Of course, there continue to be quite a few annoying shortcomings, quirks and possibly even straightforward bugs in the Affinity apps and I as well think the interface should be more intuitive and self explanatory in several of its "corners". And yeah, it's frustrating when you have to wait for features and improvements that are – given that competitors have these included in their apps for ages – have been requested over and over again for years by now. However, saying the apps are "completely useless and insufficient as production tools" is just not true and it doesn't help anybody. I for my part am perfectly happy that the Affinity apps have made it possible for me to generally leave Adobe behind (even if I admittedly – however rarely – have to come back to my decades old version of Illustrator now and then to do something special that's possible there, but (still) and regrettably not yet in Designer…) Certainly I'm usually "looking for smooth sailing“, too, but you always have to weigh your options and currently I'd rather give Affinity/Serif some more encouragement to finally listen more carefully to the more "professional“ members of their user base and keep improving and adding essential features than needlessly declaring the apps "useless" and going back to where I have been happy to escape... But then, that's a strictly personal view in respect to the things that I need the apps for – might be different for others.

Indeed! It seems, though, that in both cases the final result will be the same: both radii will eventually – and regrettably – be set to same value…

Yes, I have V 2.5.6 and this is how I observe it to work. The radius set for the corner node of the outer path in step 1 is kept and assigned to the corner node of the inner path immediately when entering step 2. There is no resetting to 0.

I guess so – and it can obviously be done real quickly with rectangular corners. As with non-rectangular cornes on more complicated forms it seems advisable, though, to wait with expanding until everything is actually shaped as it should finally appear while maintaining a "real" stroke. Keeping an expanded stroke of a more complex appearance in uniform width when making changes to individual anchor points of its inner and/or outer paths can really be a pain in the butt... As a matter of fact I try to not forget to keep "building forms" for construction with "regular" strokes on one or more separate layers and then work on duplicates of these forms for further elaborations including expanded versions. Always better to have something to come back to than possibly having to start from scratch. Nevertheless I wonder why that technique shown for Illustrator as shown in https://www.instagram.com/heyadamdesign/reel/DEaGGAhNbVd/ actually works in AI. Looks like in that case the radius applied to the outer path in the first step – say r1 – is sort of maintained before by dragging with the Corner Tool it is (just) increased by the same value as is set (by the very same dragging) for the radius for the inner path – say r2 – which in step 2 is starting at 0. (As it should be when considering the paths being/becoming parts of concentric circles) In Affinity, though, both of the radii seem to get the same value in step 2 (as GarryP pointed out) – to be precise: the inner radius does not start at 0 while dragging with the Corner Tool in step 2 but is immediately set to the value which has before (in step 1) been applied to the node of the outer path. This is effectively pushing inwards the center of the inner circle in relation to the position of the outer circle making them non-concentric and accordingly making the thickness of the expanded stroke vary… Did Adobe's developers just do the math better or why can't we do it in Affinity as easily (and correctly)?

I just watched this https://www.instagram.com/heyadamdesign/reel/DEaGGAhNbVd/ short video showing a demonstration of how to easily round corners to appear visually correct on expanded objects in Illustrator – i.e. avoiding visually (obviously) clashing radii on outer and inner paths. Unfortunately this doesn't work in Affinity as it does in AI although you seemingly do corner rounding in quite the same way. Anybody got an idea how to do this correctly in Designer (or Publisher) as well? That is, of course, without doing all the math you theoretically could do to determine the proper radius to each of the paths according to the thickness of the (visual – here: black) outline...

I'm all with you, guys: for me it's quite a shame that this "selection to path" feature is still missing in Affinity Photo and Designer – but so is "Autotrace bitmaps“ (or whatever you want to call it) in general. I really can't get my head around it that such an essential feature/tool for professional graphic artwork hasn’t been included during all these years. It's been called for so often and by so many users, but still no sign of it on the horizon. Makes me sort of sad and contributes to making it harder than I'd actually wish to wholeheartedly defend or propagate the switch I took from the Adobe apps to Affinity years ago. I'd go so far and say that at least v3 (and on) just has to have it to finally be taken seriously by most professional designers.