GaryLearnTech

Hi @ViktorfromCzechRep! If you can accept a small compromise, I think it is possible to do what you're after. In this example, the chapter numbers and the equation numbers are automatically generated. The compromise is that I don't think there's a way to have the equation numbers placed to the right - but if you can accept them on the left and then followed by the equation, then you’re in business. (This is a slightly simplified demo - an earlier trial version was more complex but went beyond demonstrating the basic principle, so I simplified it for now.) You need two paragraph styles: one for the chapters and one for the equations. As well as regular formatting they use multi-level numbering/lists. Have a look at the "Chapter Title" and "Equation" paragraph styles in the attached sample file. In particular, take a look at the Bullets and Numbering section of each of those two styles. In this simplified example, set any empty paragraph to use the "Chapter Title" paragraphstyle. Set your equations to use "Equation". (Making your equations red is strictly optional! I just did that to make them stand out. 😀) Does that help? (If the numbers must be on the right, I do have half an idea, but it's after midnight here so I'm stopping for today.) multi-level numbering.afpub

Hi @simongreen75 - welcome to the forums. The reason it's appearing so pixellated is because you've downloaded a really low-resolution version of the image you were after. You can tell that from your screenshot - it's only 416x291 pixels, so it won't matter which app is used to open it. I wonder if this was just a thumbnail and the site from which you downloaded it has a link you never spotted for downloading a hi-res version?

Hi @LeahKiser - sorry, I see that jump in your earlier screenshot now. I don't think it's so likely that you being on a Windows machine while I'm on a Mac is likely to be significant. What version of Publisher are you using? The difference in our experiences makes me wonder if you're on an older version? What Data Merge settings are you using? There are some slight anomalies in your data file. There are six fields for each record, but you've only got five column headers. Only two rows, as far as I can see, use the sixth field: Aug-12 (Ketubot 37) and Sep-23 (Ketubot 79). Adding a suitable column title and the associated data merge field may sort things out on your end.

I've attached the PDF version of my product (I had to go back to your earlier Publisher file to regenerate this). Every page has Monday to Sunday arrayed across the top. And I'm pretty certain that every date from June 27th through to October 2nd is correctly presented - along with the associated Hebrew calendar data, where provided. What is it that you’re missing? You're saying it's skipping data records - but you're not saying which ones. I can't see anything wrong in my file here, so I can't work out what you reckon is missing when you try it. Can you be more specific? 3Q 2022 6.26 x 9.25 Overview Pages.pdf

I believe I have cracked it, @LeahKiser. Specify your data merge as follows, in particular, the Merge Pages section at the lower right. On my Mac, the Data Merge dialog box isn't initially displayed at full height, so it might not be obvious that there's additional functionality tucked away that's critical in this instance. Hover over the lower boundary and drag down a little to reveal the options shown below. Specifying the page range consistently generates the results I think you're after, for both examples. One other thing - do yourself a favour and stop labelling your data (at least the data from your current sources) as CSV. It's not comma separated - it's tab separated. Same idea, but different implementation. I've always just called such data sources "tab delimited", but Serif describes them on the man pages as ".tsv" files, which I suppose is fair enough. Rename your data source file accordingly and the import process will go more smoothly. You won't have to manually change the Delimiter field at the top right of the Data Merge screen - it automatically defaults to "tab" if your naming convention is foo.tsv.

To illustrate @Patrick Connor's point about sales being good for business… I'm a Mac user through and through. But I've just purchased a Windows Publisher licence to better help mentor several Windows-using colleagues at work who are going to be starting use it. I'd not have done that from my own pocket at full price (even though it's an inexpensive, one-off purchase) - but taking 50% off? That made it much easier to decide.

Also: macOS Big Sur (11.6.5), Affinity Publisher 1.10.4 I got curious. What if, instead of multi-touch scrolling on the trackpad, you combined click-and-hold/drag on the trackpad with the keyboard shortcut for Document > Next/Previous Page, ie cmd-page down/up? That's a slightly awkward combination if you're right-handed, but it's do-able. You appear to still have hold of the original object's outline when you arrive at the destination page (see screenshot). However, release hold of it and nothing happens - it's actually still back in its original location. It looks as if the 'grasp' is released on the first keyboard shortcut. In which case, appearing to still have hold of it might be considered a bug, whereas the absence of the multitouch trackpad scrolling would be a feature request?

Hmmm. Bet I'm not the only one that instantly thought of this skit! 😁 (With apologies to the original poster for continuing down this unrelated rabbit hole!)

Hi @Lee D - if you reckon that those Monterey problems have indeed been resolved, it would be good to get that article you linked updated to reflect that. I'm on an M1 Mac mini and have remained on Big Sur. About six weeks back, I considered that it might finally be time to upgrade to Monterey (I finally upgraded from iOS 14 to iOS 15 at that time) - but I recalled seeing some issues discussed around here. I had a sniff around and found @Leigh's post - and, because of its "official" nature, decided to hold off. It now looks as if that one last potential barrier has been resolved and I could "safely" upgrade - and, for better or worse, would have done so when I had time a few weeks back.

This would be very welcome if/when they can bring it to a production release. There's an obscure(?) scenario where the inter-app problem is doubled. I might be wrong, but I don't think I've ever seen it mentioned here, so let me quickly explain… I'm still working from home. I'm using my own computer. To keep a degree of separation between work and personal computing (daytime vs evening/weekends), I use two separate accounts on my Mac. For the three Affinity apps, this would mean six copies of some resource content - three copies in one account and three copies in the other account. Reallusion, publisher of Cartoon Animator 4 which is occasionally mentioned here, have always taken the approach that their assets are installed into /Users/Shared/Reallusion/ on Macs (and presumably whatever the equivalent is on Windows) by default. When I first began using their software, years ago, I really hated that approach - it just seemed fundamentally wrong. But it has actually paid off nowadays, when I might want to quickly use it while logged in using my work account and still have access to all of their standard resources, as well as the third party stuff I've bought or have produced myself.

A better way to think about the relationship is not that Affinity Designer is in any way a direct evolution of the old Drawplus - rather that it is the younger sibling and maturing as fast as it can, learning new tricks and abilities with each new release.

Affinity Photo v1.10.1, Mac App Store macOS Big Sur, v11.6 Mac mini (M1, 2020) I could be misunderstanding the feature, but I don't think so. I think this is a bug. I start with a single, simple pixel layer. The original file I was modifying is commercial, so can't be uploaded here. I have reconstructed the problem for posting – the attached file "1a reconstruction.afphoto" shows the problem with a simplified version. I made simple selections and created new masked Fill layers. These masked Fill layers are layered above and below the original pixel layer. In this simple example, there are no grouped layers, layer effects, or anything else. Screenshot (a) shows the main starting image. A single layer, it has three cutouts and two coloured shapes. Screenshot (b) shows the pink and red overlay layers and the two blue underlays (if that be the appropriate word?). See screenshot (c) for the corresponding layers. All pretty straightforward so far. I then want to export the file as a PSD, using the Rasterise All Layers option so that the resulting PSD has only pixel versions of the previous masked Fill layers. (This is so that the resulting PSD file can be easily imported into another app – Reallusion's Cartoon Animator). The export completes, but not as expected. The previous Fill layers are indeed now pixel layers, but they're been merged with the other lower layers. Screenshot (c) shows the layers from the original image. Screenshot (d) shows the Fill layers have been rasterised but, for example, the red and pink overlays have been merged to produce new version of the main layer. You should be able to see this for yourself with the attached "1a reconstruction.afphoto" example. Export > PSD > More > Rasterise All Layers. None of the other options see m to affect the result. Screenshot (e) shows the expected result for each pixel layer - no merging. I can get what I want/expect if I manually rasterise each layer before exporting the PSD. In this simple example, that's not a big deal, but some of these PSD assets I've purchased come with a substantial number of layers and that approach would be both inconvenient and impractical for them. I could create layer-based slices and use the Export Persona to generate individual PNG files that I could import into Reallusion's Cartoon Animator and this should work. But, again, the significant number of layers in some of these purchases make this a significant issue as each sliced file would have to be individually imported 1a reconstruction.afphoto

Putting a little more meat on the bones of @LibreTraining's explanation, I found the following info at Wikipedia > Emoji > Implementation > Vendors and platforms > Microsoft Windows. Differently from macOS and iOS, color glyphs are only supplied when the application supports Microsoft's DirectWrite API, and Segoe UI Emoji is explicitly declared, otherwise monochrome glyphs appear.[161] Microsoft's COLR/CPAL format for multi-color fonts such as Segoe UI Emoji is supported by the current versions of several web browsers on Windows (including Firefox, Google Chrome, Internet Explorer and Microsoft Edge), but not by many graphics applications.[126]

Hi @Artturi I can't put my finger on what's causing those cyan artefacts/highlights, sorry – your file opens and displays fine on my Mac system. Could this be one of those your-graphic-card-driver-needs-updated scenarios that sometimes seems to trouble Windows users? What version of Affinity Photo are you using?

@walt.farrell You're absolutely right, of course - but I see now I wasn't quite as clear as I had thought. I meant that there was no shortcut available for applying the setting I pointed out.

Hi @Andrew Wilson If you purchased from Serif's own store, visit https://store.serif.com/en-gb/account/downloads/ (you'll need to log in with your Affinity account credentials) and you'll find an installer download link for each purchased app (as well as your registered email and product key). If you purchased from Microsoft's store (same goes for Mac users purchasing from Apple's Mac App Store), log back into that store with the same account originally used to purchase the apps and redownload/install.

No menu command or keyboard shortcut, but there is a slightly different approach, if you already have text that you want to move to the next column. Put the cursor into the paragraph you want to move and set Paragraph > Flow Options > Start > In Next Column - as shown below. This can be included in a text paragraph style for automatic use.

Hi @Gabe - sorry, I had done a search but came up blank on previous reports. Good to know you've already got this logged.

I was in what seemed to be a similar position earlier this week. I had issues with Montserrat - it would appear perfectly on screen, but exported PDF's displayed what looked like a Cyrillic style version of Montserrat. I had several older versions installed (they came with Final Cut Pro plugins from FXFactory) as well as my personally installed latest version. All apparently managed properly in Font Book, with just my preferred version active - the others showing as inactive. In the end, I cleared them all and reinstalled just a single recent version, but that led to duplicate entries in the font menu. Yikes! Then I remembered an old, old Word troubleshooting tip - Save As to produce a brand new document from scratch. Evolving documents contained hidden 'baggage' and this would clear that baggage, producing a clean version of the document and would often resolve problems. (If nothing else, it could make documents considerably smaller!) I tried the same thing with the Publisher document I had been working on and, hey presto, the duplicate Montserrat entries had vanished - and my exported PDF's now displayed as expected. My reckoning is that each Publisher document contains some sort of unique reference to every font - not quite a cache maybe, but something similar. Those references somehow got out of whack as I was trying to straighten out my Montserrat versions and was only finally cleared when I did a Save As.

Publisher 1.10.0, from Serif App Store Mac mini, M1 processor macOS Big Sur, 11.5.1 Same problem on Publisher 1.8.4 (Serif App Store) on Intel MacBook Pro (Catalina, macOS 10.15.7). Same problem on Publisher 1.9.2.1035 (trial version) on Windows 10 Pro (OS build 19041.1165) Steps To Recreate Create a table. Type in some text. Select some of the text. Drag and drop the selection to another location within the table. Expected behaviour: the selection drops into the table cell indicated by the insertion point that follows the mouse/trackpad pointer. Reality 1: drag horizontally left or to any higher cell (left or right) and it works as expected. Reality 2: drag horizontally right or to any lower cell and the selection flies off unpredictably into a random cell. The screen-recording shows both realities: dragndroperror6fps.mp4 Try to guess where your selection will end up! Minutes of fun for all the family! 😀 Points may be awarded for correct guesses…

I'd come across a reference to Font Menu Cleaner recently, but hadn't pursued it at the time. Thanks to your recommendation here I decided to grab it and have just spent a happy half hour disabling many foreign-only fonts - including about eight hundred from the notorious Noto family. Excellent! Thanks, @MaasSoCal, for giving me the nudge I required. For anyone else wondering about this particular utility's heritage, it comes from the same developer ("Etresoft") that produces the popular EtreCheck troubleshooting utility.

Oh that's sneaky. I do like the way you think, @Lagarto - thanks for that suggestion!!! 👍 It had occurred to me earlier that I could place a white shape over the top of the day number to mask it - it's at the lower left corner of the page and left justified - and that might be almost good enough. It would probably produce a slight variation between single day and double day dates. Not that anyone would notice unless they went looking for evidence. But your suggestion should work better.

I had a feeling that was the case - thanks for confirming so quickly.

I'm producing a template for a step-by-step guide, updating an old design produced in other software. Once created, these guides are unlikely to be updated more than once or twice a year. The original design includes the date last exported/printed on the back page. The format used is in the style of month year (for example, July 2021) and this works nicely for these guides. Now that I'm trying to implement this in Publisher, I can't see a way to drop the offered day of the month from the field. Is there a way to override this that I'm missing? In shorthand, I'm after something like mmm yyyy - not some variation of dd mmm yyyy. If we have to, we can obviously enter or update this manually, assuming we remember - but it would be nice to have this aspect automated. In case it's significant, it's specifically the Printer or Exported Date field that I'd like to use. I did come across one or two posts from a couple of years back asking for similar functionality, but I suspect that it isn't available yet.

Hi @Kelito It looks a bit like you're viewing that problem document in Outline view. (There might be something else going on as well, but check this anyway.) If you've not already tried @Dan C's suggestion to reset back to the default settings, have a look under View > View Mode. If you are on Outline, try any of the three options that appear above that option, as shown below: Manual > Get Started > Viewing