loukash

Ah, sorry. I meant this one:

Alright, as it turns out, my "vintage" µ-mini couldn't rotate by itself yet. So obviously I'd rotated all portrait images myself losslessly via GraphicConverter before importing them into iPhoto. And that's why they now import correctly into Publisher, unlike all the other auto-rotated images from my iPhone and Canon.

Alright, as it turns out, my "vintage" µ-mini couldn't rotate by itself yet. So obviously I'd rotate all portrait images myself losslessly via GraphicConverter before importing them into iPhoto. And that's why they now import correctly into Publisher, unlike all the other auto-rotated images from my iPhone and Canon.

… which reminds me: One workflow where I'm still using 1-bit images are document scans for OCR: scan in grayscale adjust contrast & threshold, clean up junk pixels save as compressed 1-bit TIFF (until now in Photoshop, obviously) open in Acrobat OCR save as PDF That gives the most compact PDFs. File size matters here.

Outside APu, the images are rotated correctly. Also, as I posted in the other thread, not all images seem to be affected. Portrait view photos I made with my 2004 Olympus µ-mini are placed correctly. I don't remember if originally I'd rotate them manually though – usually losslessly via GraphicConverter – but I can make a few fresh photos to test it again. Will have to charge the battery first, haven't used it in quite some time…

Would you mind to share an example? I'd be seriously interested to test how complex an image has to be so that it cannot be vectorized e.g. by Illustrator CS5 – which is what I still have and use for this very purpose, as noted previously. Thanks

NeoFinder's predecessor CDFinder was my very first online software purchase over 20 years ago. And Norbert, the developer, is always open for requests and ideas. Having accumulated over 1800 unique catalogs in there – mostly backup CDRs and DVDRs – can't do without. Optionally, NeoFinder catalog files are even still backward compatible with CDFinder in case someone would need to look up their catalogs e.g. while running an "antique" PowerPC Mac (I do from time to time).

^ requoted for emphasis! I'm aware of that, and I found it highly annoying from the start. But back then I wanted to check out all those free-as-in-beer brushes et al, so I had to play along… Yep, that's a significant part of any devs' job. That's what ~/Library/Caches is for. Aside from the already present folders com.seriflabs.affinitydesigner, com.seriflabs.affinityphoto and com.seriflabs.affinitypublisher, an app can create its own "private" folder in there and cache whatever else it needs for fast access. If a user deletes that folder, the app will simply rebuild its cache on the next launch. Some apps will let you choose the path where to put a cache or temporary files, which is in particular necessary for audio editing apps that usually use huge 32-bit floating point files. ~/Library/Caches has the benefit that it's excluded from Time Machine backups so you don't store needless junk on your precious backup drive over and over again. Some other apps, on the other hand, are poorly conceived and store their cache/temp junk in ~/Library/Application Support or even in ~/Documents where it's being pointlessly backed up by Time Machine again and again – unless you'd explicitly exclude it from TM backup manually. For those apps I'd usually create a cache folder in ~/Library/Caches myself and redirect them via symlink; iZotope Product Portal – yet another cross-platform app with a non-standard UI – being a recent bad example with 200 MB of cache junk in ~/Library/Application Support/iZotope/ProductPortal_cookies that don't need to be backed up: at worst you'd have to log into your iZotope account again. I have no exact idea either, it was just a "fraction-educated" guess. Even though I still have an Apple Developer ID from the days when membership was free, my programming skills are sadly limited to basic AppleScript.

It's very likely the same format on both platforms, so thanks for the words of caution. Good point. No worries. As noted: I.e. I can reformat and reinstall the complete partition at any given time. Nothing here that's not replaceable, all is safe. Just a few minutes ago I've finished here some "dirty testing" of Nik Collection 2015 within Photo 1.9: … ff.

Full Photo reset again, this time without Serif account login: Analog Efex Pro 2 OK Color Efex Pro 4 crash on 1st run, then OK Dfine 2 OK HDR Efex Pro 2 OK Sharpener Pro 3 OK Silver Efex Pro 2 OK Viveza 2 OK Repeated one by one at least two times without crashing. Didn't apply any presets though, just opened each plugin, it did "something", clicked Save.

Analog Efex Pro 2 OK on 1st run, then crash Color Efex Pro 4 crash on 1st run, then OK Dfine 2 OK HDR Efex Pro 2 crash on 1st run, then OK Sharpener Pro 3 OK Silver Efex Pro 2 OK Viveza 2 OK So it's a hit or miss, but strictly "technically" they are able to run inside v1.9

Alright, a more or less clean install of Photo 1.9 on High Sierra, a "dirty" Google Nik Collection 2015 partially living on another partition with some of the prefs copied over, i.e. NOT a kosher installation: Analog Efex Pro 2 OK. Color Efex Pro 4 crashes now, but worked on first use. Dfine 2 crashed. HDR Efex Pro 2 crashed. Sharpener Pro 3 OK. Silver Efex Pro 2 crashed. Viveza 2 OK. Now let's see what happens if I fully reset Photo.

Having also the free-as-in-beer Google version from 2015, today I briefly checked in Photo 1.9 on High Sierra, but only Analog Efex Pro 2 and only as a "demo" because the actual Nik installation lives on an El Capitan partition. Haven't checked the other modules but will try. (Hold on while I'm rebooting…)

Just checked my backup catalogs, and one of my custom system palettes dates at least as far back as July 2003 – that was on Mac OS X Jaguar! – and its current incarnation was unchanged since 2012 until I briefly tested it right now. The *.clr file format is obviously still the same to this day.

What does "always" mean? Can't reproduce with v1.8.4 on El Capitan: Rearranging works for me in both palettes simultaneously. Actually I do use custom system palettes a lot, inside and outside Affinity across apps like Adobe CS or Logic Pro, even syncing them between different Macs and between MacOS versions from Mountain Lion Leopard (!) up to Catalina. Can't comment on Big Sur issues though. Perhaps you may want to upload a document and a palette that crash? Palettes are inside ~/Library/Colors

I have noticed the same phenomenon with Photo after installing the complete suite for testing on a spare High Sierra partition. On that partion, I have run v1.8.x of Photo before, but not Designer or Publisher. The latter two launched fine and quickly, but Photo kept on bouncing in the dock for a long time. Since it's just a test partition without any special app settings that I'd need to keep, I simply launched Photo with ctrl key pressed down to open the Clear User Data window and selected all checkboxes to reset everything. That has helped. Depending on what your customized app settings, assets and everything are, you may want to be very careful what to reset though, and make sure you have a full backup of everything first. The app itself shouldn't be part of the problem here – apart from quite a few other ugly new bugs, duh – so no need to reinstall that.

Can you post a document where it happens?

For what it's worth though, Apple is only restrictive with sandboxed user content. At least up to Catalina – no idea about the newest Big Sur restrictions, lacking a compatible Mac. But stuff outside a sandbox can be easily "outsourced" via symlinks. Most standard apps will have no problems with that: My Catalina partion is only 64 GB in size. Yet it can run full Xcode, Logic Pro with its complete sound library, all Affinity apps, iMovie, GarageBand, Pages, Numbers, you name it, all at the same time (not that I'd do that, but hey, it's fun, right?). After I have downloaded and installed an app, I moved it to another large partition on this SSD and linked it back to the Catalina /Applications or /Library folders via symlink. (Logic has this functionality already built in, for relocating its 70+ GB sound library to a different volume). So I have a 64 GB partition that runs around 150 GB worth of apps and their supporting files. (Dads, don't try that at home on your kid's brand new shiny iMac! ) That would easily work with non-sandboxed Affinity user files if only the apps would be able to share them. (Note to self: check out if the non-sandboxed APu can share some *.propcols from ~/Library/Containers/com.seriflabs.affinitydesigner/Data/Library/Application Support/user)

Yeah, that's especially confusing as there's no visible divider between the spreads whatsoever.

Um, that's not "recent versions". Sandboxing was here since Affinity shipped in 2014, and it was to be expected that it just becomes even more restrictive with each MacOS upgrade. But it's definitely one of the reasons I'll be buying the v2 upgrades of APh and AD from the Serif store and not from Mac App Store. Whereas I bought APu 1.7 from the Serif Store right from the start, and can thus do with the ~/Library/Application Support/Affinity Publisher folder whatever I want, like moving it into any location of my choice by means of simple symbolic link magic (which is exactly what I did and I have my reasons for doing it). Not possible with App Store sandboxed apps and their walled garden inside ~/Library/Containers that prevents symlinks from "looking outside". But the biggest conceptual mistakes Serif made were: using completely separated app support folders for each app, instead of organizing them into subfolders: ~/Library/Application Support/Affinity/Designer ~/Library/Application Support/Affinity/Photo ~/Library/Application Support/Affinity/Publisher and adding: ~/Library/Application Support/Affinity/Shared putting all assets into a monolithic file called assets.propcol – my Photo/Designer 1.9*) assets.propcol are 2.58 GB each! WTF?! In fact, they both contain the same 1+ GB freebie which Serif gave away a few years back and that I have already stored elsewhere on the drive! As for shared data in a sandbox: isn't it what ~/Library/Group Containers is for? Serif has a few folders in there aready: ~/Library/Group Containers/6LVTQB9699.com.seriflabs ~/Library/Group Containers/6LVTQB9699.com.seriflabs.beta ~/Library/Group Containers/6LVTQB9699.com.seriflabs.extensions ~~~ *) While I've downgraded to 1.8.4 on my everyday's El Capitan, today I have installed the full v1.9 suite on a spare High Sierra partition for experimenting.

^ No solution yet, but some JPEGs in portrait mode seem to be unaffected. You may want to use Layer > Convert To Image Frame for easier photo manipulation.

Haha, sometimes it's a Good Idea™ to take a closer look at the breadcrumbs navigation at the top of each forum page, which in this case goes like this: Cheers!

Bad analogy. Appropriate analogy would be: People trying to put things in their pocket only to find out there's a hole in it. I don't like this analogy as far the literal subject is concerned either because I would never want to skin a cat in the first place. Give me a dog instead! But fair enough, when you're right you're right. Exactly. And that's a bug. Hence my bug report with examples. I see. Well, that's basically what I've done here, only you've done it smarter and more efficiently than what I did, because my example was only a "proof of concept" by using and expanding already existing paths: So, thanks for chiming in again and expanding on the subject in a constructive way this time. But it still is what it is: a workaround. Now, would you go this exact path (no pun intended) if you had never used a vector app before, and your only analogy were, say, a piece of paper and a cutter? I don't think so.

Thank you for that! Just a few weeks ago I desperately tried to recall what the name of this film was. Actually we used to call it "Ulanofolie" in our Swiss German designer slang, but you brought me on the right track nonetheless. I still have a bunch of them buried somewhere in my studio…

For the record, I've chosen the latter option. This very issue being one of the main reasons because I have yet to rebuild my custom PDF export settings from InDesign CS5.5.