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.