Andreas Scherer

I suggest to use the shorter (and less redundant) expression: Die Skalierungskorrektur funktioniert nur bei festem Seitenverhältnis.

Affinity 2.4.2 (all three apps) has too little space for the German info text for the "Skalierungskorrektur" in the Transform panel. The last word ("entsprechen"?) is chopped off.

On MacOS the Affinity apps already have an "OS-Standard" setting that should follow the system from "Light" to "Dark" in the evening. (Personally, I have fixed settings to "Light", so I can't really confirm this automatic switch.)

After a cold boot of this M1 Mac Mini with Ventura 13.6.6, Affinity Designer in both versions 1 and 2 takes around "30 hops" of the Dock icons to launch the first time of the day. Restarting the apps takes only a few seconds.

I do use Homebrew for my two Macs and one Linux machine. Skimming the first page of the thread you mentioned, doesn't excite me to add the Affinity apps to the sets of Casks at this time. (Note that haven't yet had the opportunity to transfer the suite from one machine to another.)

A recent brew update reports a ton of New Casks, among them affinity-designer@1 affinity-photo@1 affinity-publisher@1 For detailed information about the first, I call brew info affinity-designer and get Having downloaded and installed Affinity (V1 and V2) from the Affinity Store, I don't quite see the advantage of installing the suite via Homebrew. Comments?

See https://support.blurb.com/hc/en-us/articles/360044955872-Affinity-Publisher-PDF-files

It might also be useful that apps check for external changes and either pop up an indication ad hoc or warn when trying to save the file and suggest to save over or separate.

Or multiple FX like Outline. (Be careful not to un-group, though.)

Use a dotted curve as usual (Affinity V2 is better with its distribution settings; my example comes from V1). Then expand the curve (Layer menu) and swap the fill and outline colors of the "bullets" to make "holes". If need be, the single "curves" layer can be separated into individual elements.

CMIIW, not necessarily with all versions/installations. Here on macOS 13.6.3, imagemagick: stable 7.1.1-25 (bottled) (installed from Homebrew) does not magick identify -list format neither (A)IFF nor ILBM. Also ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 on Kubuntu 22.04 does not show these for convert display -list format.

On macOS it's SF Pro.

From a quick glance after the upgrade to version 2.3, I can confirm that this issue is fixed. Thanks!

My eyesight has also degraded, so I use my WQHD-Monitor at FullHD only, but otherwise I activate the Screen Magnifier of MacOS, i.e., Ctrl+MouseWheel. This helps quite well.

In case that you want a changed shape, you can use the boolean operator "overlap".

Sure, just not with a brush. As a geometric object, it can be created usong the Pen Tool.

Create your own brush and use it as outline of a circle. Here's a video tutorial:

I used the non-commercial package of the Brill font directly from Brill.com and the Monterchi font for personal/non-commercial use from DaFont.com. (The latter installs as Monterchi Trial.)

I can confirm these by practical example. The Glyph Browser in APub is your friend.

Mac Mini M1 2020 with MacOS Ventura 13.6.1 Affinity 1.10.8 Maybe it is just me, so bear with me. While scrolling in the Document View with the up/down gesture on a Magic Mouse works just as with a third-party mouse with physical scroll wheel, the same is not the case with numeric fields, e.g., in the Transformation panel. With a physical scroll wheel I can hover over such fields and increase/decrease the value by rolling the wheel. With a Magic Mouse, the scrolling gesture does not change the values. Is this normal or a user error?

SVG is a form of XML, so the file content is in "plain text", accessible with your favorite text editor (i.e. Vim). CSS styling is defined in the <style>...</style> group at the start of the SVG file, just as @Palatino shows above. The problem in this particular SVG file is to detect the final styling of the various tags, due to the cascading (that's the 'C' in 'CSS'), i.e. overriding, definitions. The last value for stroke-width for a particular tag takes effect. (In the original SVG file, the stroke-width for, e.g., .st7 is overwritten several times.) Most of what I learned about HTML, CSS, ..., XML, SVG came from the SelfHTML site (in German). However, there are tons of other sources for self-study.

It is. Affinity acknowledges only limited CSS styling in SVG.

That seems to be not quite correct. At least in this situation, CSS styling works. AD just doesn't grok more tricky CSS that other apps (and W3C) accept.

I think the W3C server was temporarily too busy to service your request.

The W3C CSS Validator reports the original SVG/CSS file as valid.