loukash

That definitely adds to the confusion here… @SoCreative, you may want to post a bug report in https://forum.affinity.serif.com/index.php?/forum/71-bug-reporting/

Good catch!

There are two places which do the same action: Paragraph panel (on Mac at least, as there seem to be a Windows bug where the Leading field does not appear) Context toolbar But in the Character panel, there is a third extra function called Leading Override, emphasis mine. "Override" as in: apply something extra than what has already been defined elsewhere. In this case to override the paragraph attribute "Leading". There is one slightly confusing thing about the Leading Override function: when you select only a part of a paragraph, you can't actually "underride" the leading paragraph attribute for the selection. You can only increase it by using a value greater than the paragraph leading. There are some logical reasons for this behavior. Another confusing thing is for folks coming from other layout apps where leading is confusingly a character attribute by default. I remember that whenever I had to set up default preferences in InDesign, this was among the first things I changed because it was driving me nuts. Leading is meant to be a paragraph attribute. Conclusion: Use Leading Override in the Character panel only when you exactly know what you're doing. Else, leave it at "Auto" und use the Leading field in the Toolbar or in the Paragraph panel.

And you also haven't accidentally pressed the keyboard shortcut for Select→Invert Pixel Selection? (Stuff like that happened to me more than once… and I don't consider myself all that naive either… ) Also, in all those decades on Mac, in general (i.e. unrelated to Affinity) I've occasionally experienced randomly "stuck" modifier keys every now and then, including the Option key even though I wasn't holding it, which could have been a crumb under the keycap or a low level OS glitch, I don't know.

Speaking of the Panorama mode… Usually I'm using it for stitching oversize scans of LP sleeves or booklets and the like. (I'm processing literally thousands of such scans.) At the moment I'm stitching a scanned 30×30 cm booklet. Often, especially when there are some photos on those pages, the algorithm is smart enough to correctly recognize which scans belong together and it will render them separately as pages even when selecting all scans of all pages at once. This time though, the Affinity panorama algorithm got "creative", and rendered this nice piece of typographical art, at the whopping size of 63209×18648 px: Amazing… It took about 20 minutes to render, including the inpaint process. I've scanned at 200 ppi, so the rendered image would be a whopping 8 m wide if printed.

Of course you can. Well, blame the photographer for that. Or the Physics Of The Universe…

You're right; the Affinity canvas is finite: Mere 2,147,483,647 × 2,147,483,647 pixel! How pathetic, right?!

In the Panorama mode, make sure to make use of the Add To Source Image Mask Tool to manually adjust the blend areas. Adjust, click the Render button to preview, adjust again, rinse & repeat, etc. Especially when… The Undo command works in the Panorama mode, too, so you can always revert to an earlier variant while adjusting.

Oh, you can. If you don't fear the result of such undertaking… https://forum.affinity.serif.com/index.php?/search/&q=acquire image mac

Can confirm in v2.6.3. Also, this bug is not present in v2.4.2.

^ I forgot to note that I use 2TB drives in my Macs. Mere 250GB wouldn't get me anywhere…

Could it be that your hard drive is almost full? Working with APh requires lots of RAM, and even though 16GB may seem sufficient, eventually the OS will decide to swap memory to disk. But when a disk is almost full, this may slow down everything to a crawl. Until less than 2 years ago, I was using Affinity v1 on a MacBook Pro mid-2012 running primarily El Capitan. (It can boot up to Catalina as well, but I needed El Capitan for compatibility with other software and external hardware.) As long as the SSD is of high quality, fast, and has enough free space for memory swapping, it performs pretty well. That said, although I did (beta) test Affinity v2 on that MacBook booting from a Catalina partition, I've never used it for actual work.

The smoothing algorithm in v2.4.2 is likely still the same as in v1. The thing is, smoothing never really worked great, but at least it didn't crash…

Don't waste too much of your time on that. Smoothing is broken in Affinity v2.5 and above. I'd recommend that you download and use Designer v2.4.2 instead: https://store.serif.com/en-us/update/windows/designer/2/ Note that you can't open Affinity v2.5+ documents directly in v2.4.2. You may have to copy and paste the content or rebuild via PDF/SVG export.

P.S. It would be nice if someone could file a thorough bug report with a complex example curve. Unfortunately I don't have the time for that. This is a general major bug that has nothing to do with my "vectorizing stunt" as outlined in this thread. thanks

… which is easily done by Layer → Geometry → Separate Curves, then delete all the small bits.

… but they don't cause any problem when I copy the curve to ADe v2.4.2 and smooth it there. The new failed smoothing algorithm in Affinity v2.5+ is the problem. It's really that simple.™ Sadly. Here's the curve smoothed in v2.4.2 using the Corner tool multi-step method described on previous page: Yavis-work-3-smoothed_via_v2.4.2.afdesign I haven't cleaned up the small bits though.

Definitely. We've already confirmed it on the previous page that the new smoothing algorithm is likely to crash Publisher on complex paths. This likely affects all Affinity apps v2.5 and higher. (Did I already mention that I'm sticking with v2.4.2 until this smoothing and expand stroke disaster has been fixed?)

Setting up the right workflow in Image Capture will give you exactly the same result as the failed "Acquire Image". See my posts in the following thread with several variations on how to do it, starting here:

Works great as a macro. Thanks, guys!

You've selected the "Affinity" arrowhead style for the stroke. See the logo on the top of this page…

More on the topic and various workflo… er, workarounds in these threads:

As far as I can tell, this looks to me more like a MacOS "feature" ("scare quotes" are intentional), rather than an "Affinity bug". For example, Swift Publisher behaves exactly the same, converting a drag'n'dropped image from a browser window into "import.tiff", whereas a locally saved image will be imported in the original format when drag'n'dropped from the Finder. (Swift Publisher uses a package document format, so all imported elements are visible in Finder when inspecting the package content.) This is quite typical for many MacOS workflows, where apparently either the OS or the respective app attempts to avoid any degradation of files with lossy compression through an "on-the-fly upgrade" to a lossless format. Same scenario often happens with audio files in audio apps on Mac as well, where on certain conditions e.g. an MP3 file is being "upgraded" to AIFF or WAV on import, for example. There's also a "3rd workflow", where you can copy the image in the browser window to the clipboard first. Pasting it into Affinity will place a PNG for a change, which is still significantly smaller than the uncompressed TIFF. Interestingly though, Swift Publisher will paste it as a TIFF again. So perhaps an app has some control how to handle imported or placed files? I don't know, just observing the facts…

Hey, I just spent the half last weekend at home using computers to solve a problem that I would have never had if there were no computers at my home…

Hey, we've long moved beyond the "original title" from two years ago… My advice was directed at and followed this: Now, can we just leave it at that? thanks Yup. And more. (Rasterizing, anyone?) In other words: Folks, please, lighten up! We're not discussing some moon landing trajectory here or something…