Lorox

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.

I recently noticed in Publisher (v. 1.9.3 on macOS 10.14.6) that the glyphs of an older Postscript Type 1 Font I'd used in a layout document didn't show up at all in the Glyph Browser, leaving it virtually blank. As it has been the first and only time I've experienced this, I guess this will most likely be related to some oddity or corruption of the specific font file(s). It looks like, though, that the entire font family is affected likewise. It's not a vital problem as I've changed the font later but I'm curious nevertheless if anybody else might have noticed something like this as well or even knows what specifically might be an explanation of this behaviour.

Thanks a lot for your contributions – I just happened to find the solution! Actually the the suggestion to check if the text was set to adhere to the baseline grid eventually made me check the character and – most of all – the paragraph settings: it wasn't the grid, though, but the left indent and the first line indent were set to surprisingly high values thus pushing the text (far) off the page... Obviously I wouldn't have intentionally set the left indent to e.g. 694,09pt and the first line indent to 2981,71pt but somehow these values were the default at the time. I cannot really say where those big values come from. (Is there actually a way to (globally) reset all those paragraph settings to their "normal“ defaults when no text element is selected?) What I also notice: When I reset those indents to plain 0 (zero) before I create some new Art Text they stay at 0 no matter where and how big I create the type/text element. However, when I set these indents to some arbitrary non-zero value(s) before I actually draw on the page with the Art Text Tool (and before actually typing a character, just when drawing the mouse across with pressed mouse button) I can see the values of left and first line indent change in their respective fields from the initially set non-zero value, becoming bigger as the text (to be created) increases in point size. This is strange, isn't it?