Swashes as components

I’m wanting to develop a range of swashes and control their attachment to base glyphs via anchors. Can this be done? Would it be a component?

So I when the swash feature is selected the substitution would apply the swash element(s) which would lock to the glyph by anchor placement. The elements would remain as independent shapes, as diacritics do.

I want to avoid the user keying in characters for the swash feature to substitute. Rather when swash is turned on, the font can build the swash glyph. Stylistic Sets can then be used to changes the swash style.

Adding a swash element in the feature should be possible, but you might need to replace the default glyph with swash-less alternate depending ion the style (e.g. cancel serif). In that case, I do not see the benefit of the method, maybe unless you have multiple swash forms.

I’m not sure what you mean; is it glyph palette input in Adobe apps?

I’m away from my Mac at the moment so can’t test (on phone). Tosche, the thinking is that I can add many different swash elements depending on context. To avoid building loads of additional glyphs. More like adding accents like mark to mark. It may be that I’m thinking of a single to many sub which CFF can’t do (?). It may be that it can’t be done and the only way is to build several different glyphs and control them through context.

The other option is for the user to key in ‘code’ and use plug in swash elements as I did with Kingfisher, but thus means the base text is messed up.

Ultimately I’m wondering if there is a way to use anchors to help place different swash elements depending on context.

I don’t use Adobe now. Been on Affinity for a few years. But the lack of the glyphs being available in the glyph palette may be a problem for users. With Kingfisher the user would select swash feature and then key in ‘c*’ to call up a cap swash then the next glyph entered is the one it attached to. So if ‘F’ is next then c*F = F with a swash added to its top left. The supplied PDF walks users through this.

I see. Attached is a demo file of dynamic swashes. The swsh feature adds ‘swash’ glyph to top right and/or bottom left to lowercase g if a is next to it. The new swash glyphs are set as non-spacing marks.DynamicSwashTest.glyphs (2.7 KB)

Thanks Toshi! Let me process this. It certainly does what I think I’m after. I guess I can then change these again through Stylistic Sets – if SWSH and SS01 then sub swash.bottomleft by swash.bottomleftALT etc.

If I add an anchor “topright_swsh” to the ‘a’ the swash anchor “_topright_swsh” isn;t locking to a new position. Should it? Ideally I’d like the dynamic swashes to attach to an anchor position.

The additional anchor in a does work for me. If you haven’t edited the feature code and only added the anchor to the a, the swash is only being used for g.

The ss01 variant works for me too.

[edit] I improved the code and tested it on Affinity Designer. As predicted, it kinda works but not really.

Sorry, it does work – OK in Affinity (all apps for me–I’m on 1.10.04).
I can’t see it in Glyphs 3 though – which is a bit of a pain. How are you seeing it in Glyphs?

Substitution works fine in Glyphs. Anchor positioning needs to be tested in actual apps.

Edit View does not preview custom positioning rules. There is Text Preview (WindowText Preview), but it only shows standard features. You can change the swash feature to a feature that is active by default like calt or liga to preview it in Text Preview.

OK, can see that, thanks Florian.
So there is no easy way to see the custom anchor positioning whilst editing? – really?

Having overlaying glyph boxes in Edit View would cause many layout and user interaction issues.

Is there no way to see it as I can with diacritic placing? The same method would be great. I suppose I could name them as diacritics to get the positioning and then rename after?

You could build a custom glyphData to add those swashes to the anchor cloud.

Ah. That sounds fine. Will see how I get on, thanks

Here is a template:

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE glyphData [
<!ELEMENT glyphData (glyph)+>
<!ATTLIST glyph
  unicode       CDATA #IMPLIED
  unicodeLegecy CDATA #IMPLIED
  name          CDATA #REQUIRED
  sortName      CDATA #IMPLIED
  sortNameKeep  CDATA #IMPLIED
  category      CDATA #REQUIRED
  subCategory   CDATA #IMPLIED
  case          CDATA #IMPLIED
  direction     CDATA #IMPLIED
  script        CDATA #IMPLIED
  description   CDATA #IMPLIED
  production    CDATA #IMPLIED
  altNames      CDATA #IMPLIED
  decompose     CDATA #IMPLIED
  anchors       CDATA #IMPLIED
  marks         CDATA #IMPLIED>
<glyphData format="2">
  <glyph unicode="0067" name="g" category="Letter" case="lower" script="latin" description="LATIN SMALL LETTER G" anchors="top, bottom@descender" marks="cedillacomb, dotaccentcomb, caroncomb, brevecomb, circumflexcomb, commaturnedabovecomb, swash.bottomleft" />

1 Like

:+1: :+1: :+1: :+1:

In TheSans etc. I built simple SWSH with one-to-many substitutions and some kerning, works fine in Affinity, browsers and other modern software. Not in Adobe, they seem to be behind in typographic support. The anchor method described above is attractive and flexible.

Testing shows promise — the next question is if it is right for the typeface I have in mind.

1 Like