I would like Complete Composites > Anchor Based to use “anchors to create and position common composites that are made out of a base glyph and one or more combining marks”. How can I achieve that?
I have:
Latin letter small a, combining breve and combining acute
OT feature defining that brevecomb is to attach to a using anchor top_high
OT feature defining that acutecomb is to attach to abreve using anchor top_low
OT feture defining that acutecomb is ti attach to brevecomb using anchor top_low
I would expect abreveacute to use the anchor top_low to position acute in relation to breve. It doesn’t. Why?
What defines the position of acute in relation to breve in Complete Composites > Anchor Based?
If I have to manually reposition all such cases where FC changes in some predefined manner the anchors I defined and want to use, then what is the purpose of Complete Composites > Anchor Based and how does it differ from Complete Composites > Anchor Based Reposition?
The latest update of FontCreator allows you to use Complete Composites again. Just select the precomposed characters (e.g. like Ccedilla, aacute, and edieresis) and Edit from the main menu and then click Complete Composites → Anchor Based Reposition.
The required anchors will automatically be added and positioned.
So I’m not getting the expected result - Anchor Based Reposition completely ignores my anchors, so not only does 3. & 4. not work, but even my 2. top anchor is ignored and abreve+mark is composed in some FC-predefined way.
I’m loving the Anchors folders though! That makes a lot of things easier - thank you
It only works with specific anchors like top and bottom. If you want to use your own anchors, then make sure both mark and base use the same anchor and Auto Attach is enabled.
If you want to use your own anchors, then make sure both mark and base use the same anchor and Auto Attach is enabled.
Yep, doing that already, but I have a group of mark combinations that I’d like to appear lower than set by the top anchor, but only in certain context - which requires a second top sth anchor - and therein lies the problem.
One thing that might help is the stacked marks trick:
FontCreator contains support for “stacked” marks, that allow you to define special anchors for exceptions, like marks that need to be placed diagonal to each other. For example the acircumflexacute in the attached project.
The trick is to use another anchor that contains the name “stacked” in it. If found in both marks, it will take precedence over other anchors. In the example there is a regular anchor named “top” and one named “top_stacked”. Then circumflexcomb has a top_stacked base anchor and acutecomb has a top_stacked mark anchor.
See this project. Verajja Var v1.02.fcp (627 KB)
The OpenType layout feature generator also adds all required features and lookups for stacked marks.
Great! Thanks!
That did the trick. Modified - the base letter, e.g. a, also required “top_stacked” base anchor:
So it wasn’t enough to add it to e.g. brevecomb as base anchor. a + top anchored marks stopped using the top anchor, and without defining “top_stacked” for a (placed identically to “top”), several a + mark combos were placed incorrectly:
Might be because some marks have both the base and the mark “top_stacked” anchor?
The OpenType layout feature generator also adds all required features and lookups for stacked marks.
How do I find it? Other than generating anchor based positioning wholesale?
Is the sample project not suitable for you? It only uses top_stacked for the marks.
It presupposes that a group of marks with “top_stacked” base anchor (like circumflexcomb in your file) will be different from a group of marks with “top_stacked” mark anchor (like acutecomb in your file). There will be cases in my project where these two groups will overlap.
How do I find it? Other than generating anchor based positioning wholesale?
Within the OpenType Designer click the upper left toolbar button. Then select Anchor Based Positioning (ccmp, mark, mkmk).
That’s what I meant by wholesale - it adds a ton of other features within Anchor Based Positioning - so I added just the feature I needed manually.
Whether in making this font or generally in programming, I prefer not to assume that users will operate within a certain set of parameters which I consider correct. Therefore, the end product should account for untypical or even “incorrect”* user actions. In my font, I’d like to position marks like gravecomb, dotaccentcomb, hookcomb lower when added above a concave mark, like breve. I’d also like to position e.g. invertedbrevecomb lower above convex marks, like hookcomb. This means that e.g. hookcomb will require “top_stacked” anchors of both types.
Since FC seems to require “top_stacked” base anchor on base letter, like a, when encountering marks with “top_stacked” anchors of both types (BTW, why?), I’d also need to set the values of “top” anchor (mark) and “top_stacked” anchor (mark) to be identical, else I get this result:
The first one is a.alt+…, the second is abreveacute. Obviously, I don’t want these two values to be identical - what I’d like is to have FC position brevecomb in both cases using the “top” anchor, but in the unlikely scenario of a+brevecomb+brevecomb to position the second brevecomb using the “top_stacked” anchor.
*Examples that immediately spring to mind are (in linguistics) transcription of a sound that is theoretically possible but unattested, or even a deliberately wrong example of diacritic stacking for teaching purposes. The point is, I don’t know which of the diacritic combinations are correct, which are wrong, and which may be used anyway, and what I do know may be wrong anyway, hence the aforementioned overlapping groups of marks.
And yes, I know I can reposition marks manually or create stacked mark combos - but do I need to explain why I’m not enamoured with these solutions?
It seems the problem lies elsewhere. After renaming the anchor to “top_stacked”, sth went wrong somewhere - sorry I can’t be more specific. I’ve now tried one more thing:
made glyphs empty
deleted features connected to “top” and “top_stacked” anchors
deleted all anchors from agrave, abreve, abrevegrave etc.
deleted “top_stacked” anchor from a
saved, closed, reopened font project
added features connected to “top” and “top_stacked” anchors
selected AutoAttach > Enable and Complete Composites > Anchor Based on agrave, abreve, abrevegrave etc.
I don’t know which of these actions or which combinations of actions were required, but things finally work the way they were supposed to. Now “top_stacked” isn’t required on a and all I’ve mentioned before isn’t an issue. If I find out more, I’ll let you know.
The anchor must be the same for it to work in mark attachment lookups.
It seems in your case it is most practical to add a glyph that contains two stacking marks, like brevecomb_gravecomb and even consider adding brevecomb.case, gravecomb.case and brevecomb_gravecomb.case for placement above uppercase letters.
Please forget about this for now.
The underlying issue is getting curioser and curioser. I’ve now tried to replicate the problem I experienced in my font in the file you provided, and it seems I’ve succeeded, and then some. I’m trying to make sense of it and failing, so here are 2 font files with glyphs tagged “Review”. This time I’ve been unable to delete anchors from agrave-abrevehookabove, even after making them simple and empty. Also, every time I do that and then select Complete Composites > Anchor Based and AutoAttach > Enable, the marks migrate higher and higher and shift more to the right.
Maybe you can diagnose what’s going on. Verajja Var v1.04.fcp (640 KB) Verajja Var v1.03.fcp (640 KB)
The anchor must be the same for it to work in mark attachment lookups.
Yes, and that makes perfect sense. What didn’t make sense was that in order for the lookup using “top” anchor to position breve on a, I had to add “top_stacked” to a. Yes, breve had both “top” and “top_stacked” anchors, but that lookup used “top”. (“top_stacked” was used by a different lookup for stacking diacritics, not for placing breve on a.)
But if you look at my two most recent posts, there seems to be something else going on there and maybe with the help of files I attached you’ll be able to figure it out.
i appreciate the solution you suggested and I wanted to avoid, but hopefully it won’t be necessary.
Another manifestation of weirdness: I tried adding anchor-based composites one by one, just in case:
agrave, aacute went OK:
acircumflex went OK, but…
adding atilde modified acircumflex:
And so it continues with each new addition, then aring results in:
which impacts the placement of all previous marks (grave & acute minutely, so it’s hardly noticeable in the image)
I understand you’re working on the problem, so this is just by way of maybe providing you with additional data.