Frank Jonen

You can place affinity files within affinity apps. Select them and you edit the embedded version of your file. There is no way of sensibly updating them though*, that was forgotten. You have to replace the embedded file each time. *) when externally changed

For a leader demo it's good enough.

So you can scale it without rendering quality issues. A motion graphics tool can use temporal anti-aliasing more efficiently when it can use paths to generate its own pixels the way it likes to process them. In Nuke for example you can get super sharp logos if you create a font with the base shapes and colour them in-app once compiled to match. In general, rastering to need vs pixel remapping is very different when it comes to render. Also most motion graphics apps will let you manipulate the vector shapes once imported.

Ha yep! Good catch. I ran it with a single-pass only last night. This is what a 2-pass looks like. Should have done that in the first place. I can see a couple of other issues now with optical alignments that could be better.

Another example how it could be done in Affinity.

Yeeeah… somewhat Here's some inspiration from a working document I'm on at the moment. Note that I've adjusted the placements to skip the periods that would otherwise end up too close to the terminal characters (see 12.1 and 12.2 line). There's a tolerance of course, otherwise things like 12.1.2 would look stray. Leaders here are calculated from the logical outside in. That way it doesn't matter on which side I have them, they're always correct. In edge-cases you have to evaluate it more than once, but in this example it was a single pass.

We read from left to right. In RTL language settings the leader would start at the right. In either case it always starts aligned with the logical outside. Otherwise it would look quite rubbish. That's why nobody does it from the inside out. You'd get this ragged edge on the logical outside instead of a clean line. Currently I typeset it in LaTeX where it is done correctly, render to outlines (since Affinity still can't import PDFs correctly) and place it where I need it. As for the extra spacing: In LaTex my function adds either an x-width, a half-space or an en-space depending on whether the first glyph has an apex going into a vertex, a straight vertical line, an overhang arm or a vertex going down into a serif. That's in addition to the regular micro-typography settings. Something like that would be great to have in Affinity. It'd be rather simple (from a UI POV) to handle that in the Optical Alignment panel with a control character like [leader]. That way users could easily control the spacing in a familiar UI that can be stored in a Text Style.

This is half bug, half feature request. The OCIO config defines a colour picking transform. This should be reflected in Affinity's colour picker. In the past it was just sRGB (I think, there's no documentation on it). With the 1.7 releases we get an ICC looking colour picker that seems to be derived from the colour profile set in the document settings (or an arbitrary one?) The feature request part. Could we do without ICC profiles in 32-bit mode? Just use whatever the OCIO defines as base colour space and run with that? Or standardise on ACES even.

Hi Sean, no problem. It happens every single time without fail. problem lineup.afdesign

When you tab-align right, the main point where you'd use leaders, it fails. This also happens on the AppStore version.

Depending on your documents and use cases mailmerge may indeed work. For me it was more convenient (even on the simpler jobs) to just generate a bunch of files and have the outputs organised in folders without having to do anything afterwards.

Maybe this can help you: I've done similar things before in the past. Hundreds of name variations that all had to be integrated with the document and couldn't just be a quick-dry overprint at ink-time. I've always placed the main PDF as elements in a LaTeX document (often background + generated text + overlay) and wrote a small script to generate and process the tex files. Those either were generated codes from a database (or the script generated them on-the-fly and appended them to a CSV for later import to either a spreadsheeter or a database. In terms for flexibility, my more off-beat use cases were: Generate lettering from text in string variables. All glyphs were stored as press-ready CMYK images in a folder and named to their ISO name making it easy to grab. The run-time for a 400+ entry data set (names to glyphs, names to characters, address, gender based layout variant switcher) was like half an hour give or take to final PDFs. Probably because I was doing other stuff on the same machine as well. That was years ago though. These days I'd write it in Go and run it multi-threaded instead, cutting the time down to about a quarter of that. It's all just simple loops of if… then instructions. Anyone can do that after a short Udemy class (how I learned Go). Especially for clients who just discovered digital offset printing and want to talk to the recipient directly using their names like 20 times on a single page that's pretty much the only way to go.

I'm sure they can fix it. Other panels don't have that issue (Appearance for example expands to the full panel). It's about 2 clicks in Xcode (one for the view controller, one for thew view).

Yeah that's a downside of the Mac AppStore. No rollback option. The twilightzone marching ants did look cool btw for like 10 seconds, then I had a more complex selection and the nope train went by. Yep. It's Metal. I just disabled Metal to OpenGL and the ants weren't on LSD anymore. I'll just disable Metal and restart for now whenever I have to do selections until a fix is out. It's annoying but at least it's an option.

The new marching ants selection makes me nauseous. Can't use it.