Lorox

That border layer above my type is actually a rectangular shape with a smaller rectangular shape clipped to it which is set to "Erase" in order to make the inner area transparent. The distinction you make between a none filled layer and a zero percent opacity filled layer makes sense (and could make a differene). What I'm missing, however, is the option to generally prevent any other layer except the one activated/chosen in the layers palette to be activated by clicking anywhere on the canvas thus restricting any editing I might do to the previously chosen layer (which to me just seems a sensible thing to wish for and which – thanks to a little checkbox – hadn't been a problem in PS at all).

It may be a dumb question, but my searches unfortunately haven't got me an answer so far... In Affinity Photo I have a layer with some type below some other layers – especially one creating just a border of limited width all around the edges. Even if I select the type layer first in the layers palette in order to edit the text, any double click directly on the type (to get "into“ the text) it's always the layer above (the one with just he border) which gets (auto)selected. I remember that in Photoshop there had been a checkbox just to control this behaviour: you could turn off "autoselect layers" and any layer you wanted to edit had then to be selected first in the layers palette. I find this option extremely helpful when working with complex files. Obviously you could lock all layers you don't want to edit first, but that is – obviously, too – way too much hassle. So: is there really no such an easy option to turn autoselecting layers off in Affinity Photo??? I suspect I missed something – it cannot be, can it?

You're perfectly right – thanks a lot for pointing this out! I hadn't actually noticed this up to now... There's that little button/icon with two drops in the „Ansichtsoptionen“ (view/display options) window which you have to click and then you get that slider at the bottom of the window where you can set the percentage of the coverage you don't want to exceed. If there are spots where there's more ink coverage you'll see them highlighted in (more or less) orange (although I liked that garish RGB-green in Acrobat Pro better for this purpose). I didn't have any problems with PACKZVIEW running on Mojave 10.14.6 either.

Hi Bobster2 and – of course – Lagarto, thank you very much for doing these quick summaries on the current state of things. It's highly appreciated!

Having used PackZView for quite some time now I have to confess that I've lost touch a bit regarding Lagarto's "PDF Output Preview" app. Sorting this out reliably just from all the to and fro posts in this thread doesn't seem quite the easy task as well (at least to me). Could anybody possibly be so kind and just state in a few concise words what the current state of affairs is? Is "PDF Output Preview" just a regular MacOS app now which can be installed like any other app or is there still the necessity to take some preliminary (or even geeky) measures to make it work (say on macOS Mojave which I'm currently running)? Which version is actually recommended? Thanks in advance to anybody who may take the time!

I’m sorry Dazmondo77, but it looks like I cannot really follow what you are doing in that video by just watching. Guess I 'd need some more explaining...

Yeah, you're right a total ink coverage warning (as you can set it in Acrobat Pro) would be really helpful in PDFTRON Webviewer once the elements in your design are many and interacting with one another other than the “normal“ blend modes. And – of course – when (especially colour) pixel images are in the mix which you just cannot check every area of manually. Could you possibly elaborate on what you mean exactly with that ”160% global rich black and blend ranges” as cited above? How could one actually use that to check for total ink coverage in Publisher?

"The individual“ – he's got a name: Krisna – just demonstrated how to get the effect he wanted (and which I was actually looking for, too) and he very specifically used the tools Affinity Photo (or Designer) is offering to get done what he was after. Given this specific angle of interest it just doesn't matter what the intricacies/advantages may be when using the supposedly "ACTUAL layer fill“ in Photoshop for colorgrading photos with that Vivid Light technique. This having been said there is actually no point whatsoever in throwing – metaphorically – a "you do not understand it“ at someone's head (or at mine for that) who just presents a solution to some very actually common design problem. You can't even accuse him of using the wrong vocabulary as he's using exactly the wording Affinity/Serif are using in their apps’ UI, rightful or not – as it has to be for everybody to be fully able to follow the process. You possibly don't have to a profound understanding of complex Algebra to sum up your day's expenses, but you can very well show someone to correctly add numbers and get the right result nevertheless... Sometimes it's just wiser to keep focused on the actual problem at hand than putting it in a context it doesn't need to be put into here and now, even if it means to better keep one's own enlightened thoughts to oneself. A man on a mission may possibly find this difficult, however...

This reply actually appears unnecessarily rude to me: as Krisna points out very clearly he is specifically concerned of the use of layer opacity vs. fill opacity as far as layer fx are concerned. What he demonstrates in his video is EXACTLY what I was looking for: making the fill of some text or graphic completely or partially disappear while maintaining the applied fx with their original/full opacity. I've been using this in Photoshop forever to good effect and just was at a loss where to set the fill opacity (as it’s not obvious – especially coming from PS – that it's actually there but you have to look in the fx settings to acces it). Different people do different designs and accordingly have different needs, when working with tools like Affinity Photo. It's completely OK when these differ from the ones you may have. So it seems quite impolite to state that someone "doesn't understand“ what he's explaining just because his angle of looking at the topic isn't the one you're used to looking from...

For and a half years later this still hasn't been fixed – frankly: it's a bloody shame! Sometimes I wonder if Serif really does want us to go back to the Big A’s apps that we thought we had left for good... Often it's the small things which make the big difference!

This drives me mad, as it is such a basic need designwise to have a stroke's dashes (or dots) align to the corners of its shape! I hate to say it, but to me it's just either bad code/programming or it's just not caring about what designers need to make good design when this appears to not having been thought about. Seems like you’ve been able to do it in Illustrator and InDesign since the Middle Ages and this feature just has to come to Affinity Designer and Publisher ASAP!

Although I meanwhile do like to work in Affinity Designer (as well as Photo and Publisher), it still is a major disappointment to me that there are no real vector brushes in Designer. I've been working in Illustrator for 20+ years and I've always thought it's amazing what you can do with real, resolution independent vector brushes there (like vector based scatter brushes which encorporate random values for several properties from a predefined range etc.). I actually took it for granted that a new and promising vector design app like Affinity Designer would certainly take it from there and offer this functionality as well... So this is one of the things I really do hope will get addressed in future versions (but somehow I'm not overly optimistic...). Nevertheless, I guess it would make a big difference for a lot of designers and illustrators.

Same with me. I wish, though, I had purchased Photo and Designer directly from Serif as well. This way I'd have all the disc images to reinstall an earlier version from if needed. Unfortunately you cannot do that if you got the apps from the Apple App Store (as far as I know)... Given all the trouble from the 1.10 and 1.10.1 versions reported here and elsewhere that's quite a point I'd say.

After reading and hearing about all these bugs and problems with the 1.10 and 1.10.1 versions I'll stay with 1.9.3 for the time but I'd suspect that in your case maybe the file gets opened with another than the original colour profile (which had the 100% k Black) and the involuntary conversion then changes the definition of „Black“. For my use I've actually created a global colour pallette where there's a dedicated 100% K and respective K-only grey tints...

That colour separation feature of the PDFTRON Webviewer demo actually provides 99% of what I usually check with my PDF files before uploading them to my online printers‘ service. So this is in fact valuable information! It might very well do the basic PDF checking for all those who for some reason or other cannot use the PACKZVIEW app (which of course is more comprehensive – but you possibly may never need the majority of the more specialized features it's offering). So let's hope the PDFTRON Webviewer demo will stay accessible on the web for a while...

For my personal workflow I’ve found this actually much less important than I originally thought (the bleed issue HAD been irritating to me, too). As things are I find myself now doing all final layout stages in and exporting all my PDFs for print from Publisher. No need for Artboards (possibly) not showing bleed there as there are Pages instead which generally behave as they should – all kinds of views possible there. As the apps are (and have always been) so reasonably priced and – furthermore – are so convincingly integrated I don't really see why NOT to use Publisher (and not Designer) for finally putting together print ready artwork. Here you've got all the visual control you need. Using Designer just to create the (vector) assets and having Publisher as the app to do the proper layout in seems quite a nobrainer for me these days. Copy and Paste, the Assets panel and the Affinity Studio Link make it – at least for me – easy and convenient

I'm tempted to agree, if it were just for Photoshop... but the seemless integration of Affinity Designer, Photo & Publisher is quite another thing for me as a designer creating all sorts of print products. I've been sort of reluctant to really switch to the Affinity apps after decades with A**** CS, but meanwhile all new projects on a more recent Mac (with quasi-recent MacOS...) are done in Affinity – and it's really enjoyable most of the time! It just feels more „modern“ and effective in many ways than the PS/AI/ID workkflow I'd been used to for so long. Quirks like this one with 1-bit bitmap TIFFs let me wish, though, the developers at Serif had listened a bit more to designers in the real world when deciding on certain features to include in their apps. I daresay there possibly are more users needing 1-bit bitmap TIFF support in their everyday work than there are who actually do the (albeit interesting) astrophotography stuff – although this is pure speculation on my part. Similar things might be said for features/tools missing in Designer that were/are just standard in AI and which I do miss along with those PS things... But then, there'll be Affinity v 2.0 sometime and I really hope my going back to the old Mac with CS5 will be even more rarely needed than these days.

I'm not sure if I understand this correctly – does "Use DPI" apply then to just that (or those) resolution PNGs or is this a global setting for rastering in that PDF? If the latter would apply then any other image of originally lower resolution would be (in terms of "dots", though not visually) output at 1200 dpi (or whatever) as well, wouldn't it?

Yeah, that's really surprising as it's such a basic need many designers have with their layouts resp. the material going into them. I felt the same way, when I happened to have the same problem... Let's hope for version 2, then! (Fingers crossed)

Possibly 1-bit BMP works similar to 1-bit TIF in XPress – but transparent PNG (like emarillo writes) maybe just doesn't? Don't have any QXP on my machines so I cannot try...

Absolutely so!

Mmhhh, I haven't actually read anything about version 1.10 except these performance boosting measures that have been taken. Now that we haven't got 1 bit bitmap support, ARE there ANY new features or improvements on given ones in this update after all?

Exactly! Provided you've established these Character and Paragraph Styles in the first place... (you certainly will benefit from past good practice here, but I guess we might all be a bit sloppy every now and then...) If you haven’t seen to your text formats in time and you've applied fonts just directly to Art Text or Frame Text on the whole (or even partially), however, you have to go from one instance of a specific font usage to another until you've covered the entire document. And more often than not there still are some “invisible“ uses of a font as for spaces or “empty“ lines which are best sorted out as well...

Rightly said – even more for me with just CS5 as latest version... You can can only spare your legacy Mac the heavy duty work, just do the odd little job once a while and hope it'll last a few years more then. Actually, I've begun to go through my old InDesign project files and export those which might be needed for an update or as a base for future jobs to IDML in order to be able to directly open them in Publisher. So far the greatest inconvenience is the substitution of some old fonts originally used. In InDesign substituting fonts has always been a quick and easy task while in Publisher it tends to be quite a nuisance as you just cannot do it for good in Publisher's Font Manager panel. I really do hope this will get an overhaul in the future to make it as efficient as InDesign’s corresponding panel has been so far.

Thanks to you guys! The font in question (ITC Conduit, PS Type 1) actually exported to PDF without any problems, but Publisher’s Glyph Browser did look exactly as empty as it did with ITC Korinna in Lagarto’s screenshot. As you mention it: I did have problems with exporting to PDF once with another (old) PS Type 1 Font Family (HTF KnockOut, if I remember correctly). When in the Export dialogue you could see the ”Estimated File Size" check wouldn't be completed and no PDF would actually be produced. I didn't find any way to fix this except swapping the font (family) to another similar one. (Way back in InDesign and with an older macOs the KnockOut font had worked just fine, however...) So far, however, only old PS Type 1 fonts seem to have been concerned and maybe it's actually wise to use newer OTF fonts whenever possible and to check PDF export in an early stage anyway. Currently it's certainly a pain in the a** to change/substitute an extensively used font in Publisher when you didn't consistently assign text formats in your document... Lastly I don't imagine the actual choice of your Font Manager is vital to these problems – as far as I see they all (under the hood) work in a similar way when it comes to how fonts are activated or not. But that being said, I'm using Font Explorer X Pro and it has been working fine for me so far.