R C-R

Or just snap the top edge of the rectangle to the lower edge of the object you don't want to move & then snap the top edge of the object you do want to move to the lower edge of the rectangle. Probably a little bit faster than using the alignment options.

Hi @ElBeardo, FWIW this feature of the Mac OS is called the Application Switcher. As explained in this article, it can do more things than just switching between apps.

Neither am I, but what I do find surprising is there is no warning about that like there is for tif: the file is saved in the *.giff.gif or *psdd.psd or whatever form without informing the user it is doing that. So basically, it performs an unnecessary sanity check for TIFF files & incorrectly tells users that ".tiff" is required, but doesn't behave the same way for other formats, where users should be told that the extension is invalid & either given the option to cancel or use a valid one. I don't think 'jpg' or 'jpeg' should trigger a warning but I am not so sure about the other two. For example, 'jpe' is sometimes used to indicate a low resolution version of a JPEG file & may not be usable with some apps. JFIF is the abbreviation for the JPEG File Interchange Format standard, but as an extension 'jfif' or 'jif' is sometimes used to indicate the file has been saved using an optional lossless compression mode defined in the standard that is not widely used or supported. It also might be worth considering that there are several different ways the file type can be specified besides with extensions (like with MIME or Apple's uniform type identifiers) & there is no uniform or standard way to relate them all to each other. With that in mind, personally I think for exports the Affinity apps should allow any file extension a user cares to use for whatever reason, whether it is considered valid or not. There should be a notification of some sort when the extension is (correctly!) considered to be non-standard, with an option to cancel or change the extension before saving, but they do not need to do more than let the user know it is a non-standard usage, or prevent them from using it.

In an earlier post, @melonbird mentioned that this had been done:

I don't know who wrote that 'difference between' article, but they got several things wrong. The most obvious is that "Applications that are meant to open TIFF files are already coded to recognize both extensions and can open both with no problem at all." As @cegaton (among others) has mentioned, not all apps are coded to recognize both extensions. More to the point, Adobe owns the copyright to the TIFF 6.0 standard (acquired when they bought Aldus) & it still recommends ".tif" as the preferred extension (including for Mac file systems). Thus, the closing statement that "TIF is used in legacy file systems that use the 8.3 naming convention while TIFF is used in newer file systems that allow long filenames" is greatly oversimplified & inaccurate, even ignoring that Affinity Photo follows the TIFF 6.0 standard's recommendation for batch job exports to TIFF or that there are many 3 character file extensions used with most if not all file systems (including psd, txt, png, svg, & pdf). In short, there is no justification for Affinity's insistence that ".tiff" is in any way the "required" extension for exporting documents to the Tagged Image File Format. BTW, Affinity isn't even consistent in displaying the message giving users the option to include both extensions (like ".tif.tiff"). Try exporting to for example gif or psd & changing the file extension to something else in the save dialog (like giff or psdd). At least in the Mac versions you won't get the message but the file will be saved with the altered extension preceding the correct one.

My assumption is what was logged would be considered in the wider sense.

I did not say it was, only that one of the real world difficulties with this is sort of like integrating the generic USB class driver standards (relatively easy to create) with all the extensions necessary to support proprietary features of specific devices made by different manufactures, without creating conflicts (not so easy to create or get everyone to agree to). Generic class drivers would not support all the features those devices can support. That's why they come with software that must be installed to support everything.

In theory, you are right about that. Unfortunately, this is almost impossible to fully achieve in the real world because of the huge variety of OS & hardware configurations, the potential interactions between different drivers from different sources that may need to access the same APIs or other resources in specific orders, & the difficulty of determining which items that one installed driver may require may also be required by another. The 'proper' way to do this would be for every device maker to agree on a set of 'universal' standards & extensions, sort of like how USB class drivers & extensions are supposed to work to insure compatibility, but that degree of cooperation among competitors has historically been very difficult to get.

I don't have any square brushes either, not at the bottom of the list or anywhere else in any brush category. AFAIK, at least in the Mac version they have to be created (or imported), as you just mentioned that you did. My only other suggestion is to try a large 'basic' blur brush on an area of high color contrast -- at least for me the blur effect is most obvious when applied to those areas & borders on imperceptible in low contrast areas.

Thanks for the links. They seem to include a number of different issues, including one or more fonts that are somehow incompatible with Affinity & the number of files (fonts & lots of other types) the app must have open to process documents. That second issue is due to certain limitations in the Mac OS on how many files can be open at the same time. I don't understand all the details but on my iMac the Terminal command "sysctl kern.maxfiles" says the kernel will only allow 12288 files to be open at the same time. That sounds like a lot but it includes the total for all processes, so a combination of a very large number of active fonts plus all the files the OS must keep open just to function and all each running app must open to function can potentially cause a 'too many open files' error, even when an Affinity app is not running. I am not sure there is anything Serif can do about that, at least not without affecting performance.

Unless I am looking in the wrong place, I am not seeing that. What I see in the Export Persona is the slice size is shown in pixels, which for the artboard has been rounded up from its 2659.31 x 1188.74 px size to 2660 x 1189 px. The document units were originally set to points ("pt"), so the Transform panel shows 1994.5 pt x 891.6 pt for the width & height. Changing the document units to px shows the numbers above.

Where have you seen or read anything about that? The only thing I have read that is at all related to installed fonts causing problems is with very large numbers of fonts installed, the launch time of the app is increased, sometimes to 1 minute or more. But aside from corrupted fonts or mis-set permissions, which could conceivably prevent the app from launching at all, I have seen nothing about font files affecting opening a document file after the app is running.

At least for me, the Blur Brush Tool acts somewhat like the Smudge Brush Tool -- even at 100% opacity. flow, & hardness, unless I jiggle the brush back & forth a bit while using it, the blurring effect is very subtle, so much so that I often have to zoom in far enough to see individual pixels to see it. One thing that increases the effect considerably is to take the brush spacing down from the 25% default to the minimum of 1%.

From page 119 of https://www.adobe.io/content/dam/udp/en/open/standards/tiff/TIFF6.pdf (the TIFF 6.0 standard finalized in 1992): The apparent contradiction in the Apple Mac recommendation of Filetype "TIFF" vs. the ".TIF" extension is because back in the pre-OS X days Macs used a pair of 4 character type & creator codes, not filename extensions, to specify what applications should open files. These codes are case-sensitive & always 4 characters long so "tiff" would have been interpreted as a file type different from ".tif" or "tiff." These days, since the Mac OS (OS X & macOS) are UNIX-like operating systems, for consistency's sake there is no good reason to use the ".tiff" extension.

It does not seem likely that there was anything really deliberate about it. It seems more like just a sanity check that failed to include both extensions as sane ones. Besides, if they really wanted to force us to always use .tiff then it would not make any sense to design batch job exports to use .tif, would it?