frindley

@stokerg Yes, my Tab key has the same effect. Fortunately I almost never want to hide the UI. (In fact, on occasions when I've accidentally touched the Tab key and hidden the UI I've sent myself into a panic! 😀 )

@jmwellborn Or you can leave your mouse wheel set to scroll. A jiggle of the wheel will still resolve the issue and you can then use the mouse instead of the vertical scroll bar (which helps avoid the bug occurring at all). It doesn't solve the problem of the horizontal scroll bar as trigger: I've been trying to use the grabber hand for sideways movement instead.

@stokerg Yes! In addition to losing cursor visibility, I've also noticed the following immediately after I use either the horizontal or vertical scroll bar: • If I have View > Show Text Flow checked, then the visible frames disappear • the frame and handles of any text box or object I try to select with the Move tool are invisible. (I know that the selection is happening, because the object shows as selected in the layers panel, I can move the "selected" item with the arrow keys or by dragging the mouse, and the cursor changes accordingly if I hover over where I know the frame handles to be.) I can get cursor and frame/handles to show by: zooming in/out as you suggest, OR by randomly scrolling using the vertical scroll wheel on my mouse. I've been doing the latter since it's much less disruptive than changing the view size.

Thank you @stokerg that's excellent news. I did search this Forum for a similar report but didn't find anything – evidently I was using the wrong search terms. Meanwhile, for others who end up here: the problem only occurs when I close the publication using the red close button. If I use File > Close or CMD+W then the Pages thumbnails disappear as I would expect. So that will be my short term solution.

Publisher V2, MacOS Big Sur In brief: I close a publication but without quitting Publisher; the spreads thumbnails in the Pages panel don't disappear; if I accidentally double-click on one of these phantom thumbnails when resuming work, it causes Publisher to hang and I have to force quit. The following behaviour is occurring in all/any of my current publications; it didn't happen in V1. It happens whether Hardware Acceleration is turned off or on. RECIPE • I close a publication I'm working on (by clicking on the red button in the working window's traffic lights), but don't quit Publisher. • Do other things in other apps… • Later, I click on the Publisher icon in my dock [or use cmd+tab] to bring the app to the foreground and continue working • An empty Publisher window appears but the spreads thumbnails from the recently closed project are still visible in the Pages panel • Now… if I unthinkingly double-click on one of those thumbnail spreads (as I would if the project were actually open) in order to work on that spread, it sends Publisher into conniptions: I get the beachball-of-death and, in the dock, Publisher shows as "Application Not Responding". Waiting a short time doesn't help; I have to force-quit Publisher and restart. The Problem Report that Apple generates indicates "Event: hang" plus a lot of technical detail that I don't know how to interpret (although I do see "SpreadGridView" in there) • Finally, if I scroll in the Pages panel before attempting to double-click anywhere in it, then the phantom thumbnails disappear and the panel is empty, as I'd expect with no document open. (And double-clicking in this now-empty panel causes no problem.) This bug isn't a deal-breaker: If I'm paying attention and open the document I need before attempting to work in it 🤣 then all is well. But it's kind of difficult to ignore those lingering page thumbnails. And obviously this behaviour shouldn't be happening.

But this is the problem! When you open an existing document and then go to save as (e.g. to create an updated version of it), instead of automatically taking you to the folder in which that existing document lives – which is what users expect and would like because it's both logical and what other Mac apps do – the app offers you the latest used file path (i.e. the location in which you most recently saved a document, any document), which might be for some entirely different project. Or to put it another way: I'm working on Project A and I save it to Folder A. All good. Then I go to Folder B and open Project B. Work on it a bit; want to save it as Project B_v2. At which point Affinity automatically offers the location as Folder A because that's where I most recently saved something, anything. And if I'm not paying attention, which can happen, I end up saving Project B in Folder A and then wondering why I can't find it next time I need to work on it or share it. The logical thing to do would be to offer the location as folder B because that's where the Project B file came from.

Not necessarily. In my case, I’ve found that changing just the very largest (in MBs) of my placed PDFs will make the most significant difference to the exported file size. Smaller PDFs can probably be left as is.

That takes 4 taps. A quicker option, is to find the icon that looks like a grid with a © symbol in it. It will be at the left of the text entry autocorrect panel that's visible at the bottom of the screen when you're editing in a text frame. Or, if you're working with the on-screen keyboard, it will be at the top left of the keyboard. Tap on that and you'll be taken to a panel with buttons for the various breaks and also, as you scroll right, for fields, maths and other special characters, non-breaking hyphens, etc. All useful stuff The line break button is the first one in the panel. So that's two taps. It appears you'll need this panel for certain other special characters, such as non-breaking hyphens, non-breaking spaces, soft hyphens, etc. for which none of the regular keyboard shortcuts appear to work, as well as for various kinds of spaces of special widths (em-space, hair-space, and so on)

Wouldn't agree with this. Saving and exporting are two very different functions and it's appropriate and useful to keep them distinct, as in fact does Publisher's major competitor, InDesign (if you're comparing with other software). Saving is related to the working .afpub file as a whole. (Ditto saving to a package.) Exporting on the other hand is not "saving in a different format" so much as pushing out specific versions or portions of that file for particular use cases, e.g. • selected high-quality PDF pages/spreads for client proofreading and approvals • PDF edition for online publication • PDF print-ready file for a printer • JPEG/PNG/TIFF files of selected pages for use as images in different contexts, e.g. for a portfolio or presentation • etc. When I export I'm assuming that the saved source/working file that I have open is not changed in any way.

+1 from me The unconventional and unintuitive file-saving behaviour is a constant source of frustration and misplaced files. Especially when I'm working on multiple projects for different clients in the same day/week. I'm astonished we've all been putting up with this for years now. Publisher is so good in so many ways, it's a pity that a flaw like this causes unnecessary friction when, it seems to my non-developer eye, it would surely be easy to fix.

One possible solution or factor to consider [and which I now see that Jens has mentioned above]… At the moment I'm designing a series of books that typically include 2 to 3 full-page ads supplied as PDFs exported from InDesign. These ads are relatively complex and large in their own right (10–20MB). I found that changing the setting for these placed PDFs from "pass-through" to "interpret" reduced my "small" PDFs from 36MB to a much more acceptable 3MB with no loss of quality.

@Jens Krebs Agree – it's shitty indeed and I too would want to be testing the saving and exporting functions if I were actually considering investing in QuarkXPress. Fortunately, between the Affinity suite (which I love) and the Adobe suite (which I am also using for now because I'm a design student and may need to keep because some clients…), I have no need to return to Quark. But yes, Markzware's free preview option is certainly adequate to provide a reminder of the work done – although with plenty of flaws and oddities, which is to be expected I suppose. But if I actually need the files at some point then it's more than AUD330.00. Not a priority in my budget right now. My main regret is that my workflow 15+ years ago didn't routinely involve exporting to PDF, even if just for archival purposes. I have a handful of PDFs from that time, but it wasn't how we supplied work to printers back then – everything was packaged up.

Sadly, as of April 2022 at least, this doesn't work. The 7-day trial version of QuarkXPress 22 disables all types of saving and exporting. Yes, you can open existing files but the trial is literally just a way of "playing" in the software and seeing what it can do. You can't save anything you create/edit nor can you downsave or convert to PDF, etc. I'm guessing Quark discovered quite a few people were using the free trial strategy as a way of bringing over previous projects into either Adobe or Affinity. It does look as if getting the Markzware conversion tool for a year is the most realistic – if very expensive – way of converting old Quark files for future use or reference. I have 70 to 80 such files (all created pre-2006), which I want to be able to access for my reference rather than necessarily work with again. Have to decide whether converting them is worth the cost (it would end up costing about AUD4.00 per file, which actually doesn't sound so bad…).

Thank you! I'm a complete novice with Photo (I've been using Pixelmator Pro and even my skills in that app are rudimentary) so I hadn't realised the possibilities of editing multiple images in a stack. Will try this out.

I have a scenario in which a number of headshots of individuals by different photographers and of varying quality “as photos” – some originally colour, some black and white – have to be placed in an Affinity Publisher document, all to be printed as black and white (within a full-colour design). My concern is the range of tonal properties and subtle differences in greys that result. What's the most efficient/reliable method for ensuring that the placed photos are as well-matched as possible? In particular, is this work that should be done in Affinity Photo or other photo editor before placing in Publisher, or is it better to make conversions and/or adjustments in Publisher? What adjustment tools are best suited for achieving a good visual match? (I realise there are many ways to create a black and white photo from a colour one.) And are there any underlying settings or anything else I should be aware of that would help ensure a good match?