Better anchor definition

[moyogo]

For ligature anchors, many UFOs designed with one authoring tool don’t work with other authoring tools as they have different ways of storing this information. Some authoring tools expect specific suffixes (like _1, _2,... or #1, #2,...) while others expect specific prefixes. It would be better to standardize this, either in the name or preferably with an attribute (for example ligatureIndex).

/cc @graphicore @khaledhosny @jamesgk

[graphicore]

Related questions:

• How do we know, looking at a UFO source, which glyph is of type Ligature, Mark, Base, other ... ?
• How many parts is a Ligature-Glyph made of? We need that to write correct mark2liga features, also for ligature carets (also needs position information). IMHO, there's nothing in UFO that helps.

[moyogo]

@graphicore I think another issue can be opened for a way to define ligature caret. The point of this issue is ligature anchors.

[khaledhosny]

There are also cursive anchors, but in general how do you tell what type a given anchor is, base, mark, ligature, entry, exit. I don’t see how one would be able to use of the anchors without knowing such essential information about it.

[graphicore]

@moyogo the point is that you need the type of the glyph -- ligature -- and how many components it has, for both.

@khaledhosny right. I think Glyphs uses a naming scheme where name is the base anchor and _name is the matching mark anchor. For ligature anchors it would use _name_1, _name_2 etc, afaik, may be not fully correct though. For entry and exit it probably uses just reserved names like "entry" and "exit". I'm not saying its the best solution, but naming conventions could be a solution.

[typesupply]

I've done a lot of work with using glyph names to indicate feature states and behavior. Pretty much every fancy OpenType font that I've written code for has had a specific naming scheme and a script that interprets it into .fea. The names are ultimately not very flexible and they are really cumbersome for designers. It's not fun to type /o.010340/o.120140 when you just want to compare a couple of "o" designs.

Anyway, I think a much more future proof solution would be to publicly define a structure that can be stored in the lib that defines GSUB/GPOS behavior for a particular glyph. That would open up a huge number of interesting possibilities. But... How far does it go? Do we define what the generated .fea should look like? Or, do we stop at saying, "this is a ligature and here's some data about it" and "this is a mark"? This is going to get really deep, really fast. Even more problematic, how is a tool supposed to know when something that exists in .fea should be replaced with auto-generated .fea code and when it should be left alone because the designer made an edit?

Don't get me wrong, I think some sort of data structure that can deeply describe the intended use of a glyph would be really useful. Defining how that is used is something that I'm not sure we can get consensus on.

[justvanrossum]

• Would Anchor become more usable if it had an optional type attribute, that contains a (standardized) string?
• Would defining glyph.lib["public.*"] keys for glyph type and ligature component count be helpful?

[typoman]

That would be very useful. As I mentioned in a fontParts issue, having an anchor lib also would be nice to add other information like context of mark positioning. This context information can be stored in glyph lib now, but by removing the anchor, any authoring tool should also remove that information from glyph lib. If there will be an anchor type property I prefer to store the information there instead of glyph lib. I guess I can store more elaborate data structure using XML there if it's string but not sure if this is considered standardized or not.

[justvanrossum]

As explained in the issue you reference, adding lib to anchor is problematic, so please focus on solutions that don't require that.

Regarding anchor.type: what are the needed values for such a field? In the above comments I read:

• base
• mark
• ligature
• entry
• exit

Is that correct and complete?

Likewise for the type of a glyph?

[typoman]

As explained in the issue you reference, adding lib to anchor is problematic, so please focus on solutions that don't require that.

I will probably use this type property then.

Is that correct and complete?

I think so. But I don't know what's the use for ligature type though. Example in Arabic is that it's either base or mark. On the ligatures the base anchor gets an index for the order.

[typoman]

Likewise for the type of a glyph?

Only from this set:

• base
• ligature
• mark
• components

https://docs.microsoft.com/en-us/typography/opentype/spec/gdef#glyph-class-definition-table-overview

[typoman]

(Just to be clear for anchor type)
Anchor type can only be:

• base
• mark
• entry
• exit

Base anchor can get an index attribute for the logical order of mark in a ligature.

[typoman]

Actually in adobe fea file a ligature mark and base mark are defined differently.

• Base:
  pos base [behDotless-ar] <anchor 428 -5> mark @mark_bottom <anchor 438 368> mark @mark_top;
• Ligature:
  pos ligature [lam_alefWasla-ar.fina] <anchor 473 -3> mark @mark_bottom <anchor 492 726> mark @mark_top ligComponent <anchor 139 -3> mark @mark_bottom <anchor 173 893> mark @mark_top;

But personally I don't need to know if an anchor is ligature type when I generate the feature. I just check if it's a base and if it has an index.

[typoman]

Current solution to prevent adding any property to anchor is having name conventions for anchors. The advantage of naming convention is that the intention of the anchor is visible. The name corresponds to the anchor mark that is going to be placed on the base. So if a top mark is going to be placed on a base, in the base glyph, the base anchor is called top and in the mark glyph, the mark anchor is called _top. This is the naming convention from the Glyphs app and I think it's also used in fontmake. For a ligature, the anchor index is written after the name so it becomes top_1. For entry and exit a prefix is needed to differentiate it from the mark anchor. The prefix for mark anchor is _, the prefix for cursive anchor is # so it becomes #entry or #exit.

[justvanrossum]

See also: googlefonts/ufo2ft#330 (comment)

Suggestion:
Describe/document the Glyphs/fontmake behavior into more detail. It may then become easier to reason about the following:

• What are the weaknesses of this scheme?
• How could the procedure (of generating such features) benefit from UFO enhancements?

In other words:

• What is the problem?
• How does the current solution work?
• How is the current solution not adequate?
• Can the UFO format be enhanced to solve said inadequacies? If so, how?

[typoman]

Suggestion:
Describe/document the Glyphs/fontmake behavior into more detail. It may then become easier to reason about the following:

I will do that, thank you for pointing them out.

One note for now. If the glyph type is mark, it could include both mark and base anchors. In a glyph that is defined as a mark, the base anchor is used for mark to mark positioning. Takeaway: anchor type cannot always be inferred from its glyph type.

[khaledhosny]

One limitation of the above scheme is that it allows only one cursive anchor/lookup in the entire font.

[typoman]

Could you give an example where there is a need for multiple lookups for cursive anchor?

[khaledhosny]

OpenType allows it, I don’t see why we should have such a limitation otherwise. I have a font that has cursive anchors with RTL flag and without it, based on whether it wants the rightmost of the leftmost glyph to be the one setting on the baseline.

[typoman]

I have a font that has cursive anchors with RTL flag and without it, based on whether it wants the rightmost of the leftmost glyph to be the one setting on the baseline.

Good point. Thank you!

[typoman]

This also adds the question, do we need a RTL property for anchors?

[justvanrossum]

Is this googlefonts/ufo2ft#303 ?

@khaledhosny, are there any other fundamental problems that are good to consider up front?

[khaledhosny]

No, another font that I didn’t convert to UFO since fontmake does not support cursive anchors at all.

May main problem with UFO anchors right now is that there behavior is unspecified. Tools like fontmake and ufo2ft try to follow Glyphs but 1) Glyphs is not a UFO editor 2) Its behavior is not specified either 3) it has arbitrary limitations (like supporting only one cursive anchor per font).

I prefer being explicit than implicit, so I think type, index and flagsattributes would (potentially) allow the compiler to build any kind of mark positioning lookup supported by OpenType without having to do lots of guesswork. The new attributes should be optional so that people who prefer the current behavior can continue doing so without disruption.

One thing that would still be unsolved is contextual mark positioning. I have no idea how that would be supported for anchors without full OpenType machinery in the format. So I guess people will have to keep writing that manually or have font-specific scripts to handle them.

[typoman]

One thing that would still be unsolved is contextual mark positioning. I have no idea how that would be supported for anchors without full OpenType machinery in the format. So I guess people will have to keep writing that manually or have font-specific scripts to handle them.

This is the main limitation of anchors for me in UFO. A context cannot be written in the name. I would love to have the option to write it in the anchor but there is None atm.

[typoman]

A possible solution for future, adding an attributes dictionary to the anchor with (standardized) string keys?

[typoman]

A solution for now, write all the related info for mark and cursive positioning inside the glyph lib and define the spec. An authoring tool (e.g. RF extension) is required to show the preview, change its attributes and to compile it to features.

[typoman]

Another disadvantage for anchor naming scheme, the intention of the designer is unclear. The anchor naming scheme for generating mark positioning is exactly similar to build precomposed accented glyphs. Is the anchor made to generate mark positioning or just to build precomposed accented glyphs? This could lead to unnecessary extra data in the final binary. An anchor that is used for glyph construction is not necessarily supposed to be used for mark positioning and position of a precomposed mark can be different from a mark that is going to be placed using mark positioning on the actual base glyph (very common in Arabic). One solution, a new data structure only for generating marks and cursive attachment that could be saved in glyph lib and also to segregate these data.

[justvanrossum]

Is the anchor made to generate mark positioning or just to build precomposed accented glyphs?

That's an interesting question.

On the one hand: well, maybe it is cool to have mark features for (latin) accents?
On the other: that seems rather accidental, and is not controllable enough.

But anchor.type could be used to distinguish them, if it existed, so this is nice argument in favor of that.

[behdad]

lol. @typoman hijacked another thread. :)

[typoman]

I've been instructed to not to post a comment on anything I find relevant to the subject. I will do it in one huge post when I gathered all I could. Thank you all for your patience and sorry for distractions!

[gferreira]

Would Anchor become more usable if it had an optional type attribute, that contains a (standardized) string?

yes!

Regarding anchor.type: what are the needed values for such a field?
base, mark, ligature, entry, exit

I can think of an additional category of anchors which are used during the design stage and are not needed in the generated font. examples:

• anchors used for positioning ‘meta glyph parts’ (ex: making an ‘m’ out of a stem and two arches)
• anchors used only for creating precomposed accented glyphs (and not used by any feature)
• anchors which work as ‘markers’ for parametric shapes (think of variable bitmap fonts)
• anchors to control dimensions beyond 2D space (HOI handles, warp mask, crazy things)

exploratory questions:

1. could arbitrary anchor types be allowed?
2. would it make sense to have something like skipExportAnchors somewhere?

[moyogo]

While FontForge sticks to one anchor type per anchor as its model is close to the OT model, Glyphs.app and fontmake/ufo2ft currently may assign more than one anchor type per anchor.

For example when circumflexcomb has only a mark-to-base mark anchor, FontForge will have just that. Glyphs.app and fontmake/ufo2ft will be happy with a _top anchor.
When that circumflexcomb has a mark-to-base mark anchor, a mark-to-mark base anchor and a mark-to-mark mark anchor, FontForge will have all 3. Glyphs.app and fontmake/ufo2ft will be happy with only 2 anchors, _top for the mark-to-base mark anchor and the mark-to-mark mark anchor and top for the mark-to-mark base anchor.

[typoman]

What a MarkToMark base anchor is going to do? I've never heard of that one. MarkToMark is supposed to attach a mark to another mark. Why should it be written on a base glyph?

[benkiel]

For the above example, I think what @moyogo means for base is the mark that the other mark attaches to. That example is for when the mark attaches to a letter, has a mark that attaches to it, and attaches to another mark.

[typoman]

Then what is a difference between mark-to-mark base anchor and a mark-to-mark mark anchor?

[tiroj]

What a MarkToMark base anchor is going to do? I've never heard of that one. MarkToMark is supposed to attach a mark to another mark. Why should it be written on a base glyph?

Because the base is a diacritic carrying a precomposed mark?

Typically, my mark-to-mark anchors involve 2nd glyph y adjustments to obtain a consistent optical distance between the top of the 1st mark and the bottom of the 2nd mark for above marks (and vice versa for below marks), while my mark-to-base anchors use the default vertical alignment of the marks. Obviously the mark-to-mark anchor adjustments should also apply when the mark is applied to a diacritic glyph with a precomposed mark. So, e.g. applying acutecomb to ä would need the mark-to-mark adjustment of the height of the acutecomb from the mark-to-diaeresis mkmk anchor.

So either one needs to use the mark-to-mark anchor on the diacritic bases, or to have a third anchor for mark-to-diacritic.

[benkiel]

@moyogo for your Glyphs/ufo2ft example, is my assumption that the tool has some knowledge of what marks should be in the mark to mark feature correct? (this is the way I've done it in the past, just want to double check my assumption).

[typoman]

In circumflexcomb glyph example (which is a base glyph), there shouldn't be any MarkToMark positioning. Or am I wrong? I don't think it makes sense to have two types per anchor.

[behdad]

@typoman You should study the OpenType spec, in much more detail than you know currently.

In circumflexcomb glyph example (which is a base glyph),

What does "is a base glyph" mean / refer to here? "comb" in the glyph name means combining.

[benkiel]

(not a real letter, etc)

That's the case we're talking about.

[typoman]

Thank you for clarification, I think @moyogo terminology is different from what I've understood so far, ergo the confusion. But in my experience in Glyphs app and in a combining mark, any anchor mark in Adobe feature syntax will get one rule per anchor.

• top anchor will get a mark rule in mkmk feature:
  pos mark [circumflexcomb] <anchor -207 670> mark @mark_top;
• _top will get a markClass defintion:
  markClass [circumflexcomb] <anchor -207 448> @mark_top;

What's the third rule he's refering to? I don't see it in Glyphs app feature file.

[moyogo]

@benkiel Indeed, Glyphs.app and ufo2ft follow specific rules that get translated to AFDKO feature syntax, which then gets translated into GPOS lookups. Adobe’s markFeatureWriter.py follows similar rules but isn’t as complete. In short, an anchor will translate to a mark-to-mark lookup only if it is both a base anchor and a mark anchor in glyphs that also have mark anchors, and an anchor will translate to a mark-to-liga lookup only if there are matching numbered anchors in ligature glyphs.
FontForge follows rules much closer to the model of GPOS lookups.

@typoman The AFDKO feature syntax is higher level than GPOS lookups so you won’t see exactly the same structure. In short the _top is only defined once in the AFDKO example you give, but it will be duplicated, one in the mark lookup and another one in the mkmk lookup in GPOS. So you could very well have "_top", "_topmkmk" (at the same coordinates), and "topmkmk" in circumflexcomb that will produce the same GPOS structure as having "_top" and "top".

Glyphs.app and ufo2ft make the anchor type implicit as long as you follow their rules.
FontForge makes the anchor type explicit.
The UFO spec doesn’t currently mention that there is a relation between "_top" and "top".

Sorry, I’m just babbling about how different authoring tools work without providing a way forward.
But we may need to either specify rules in the spec that follow or a close to what Glyphs.app and ufo2ft do or a way for the user to be more specific.

@gferreira’s skipExportAnchors as a list of anchor not to export would already help the user.

[justvanrossum]

I think we should reconsider adding a lib to anchors after all, given all the possible uses for anchors listed in this thread alone.

[benkiel]

One other thought, if we allowed a mark to have more than one type, it would accommodate what Glyphs/UFO does and also what FontForge does and allows for anchor re-use but also more specificity.

[typoman]

Here I've gathered some information about how tools deal with anchors in UFO. I hope this could be useful for people who are trying to figure out how things already work in UFO tools. Some of this is just copy-paste from different places in GitHub.

• CursiveAttachment

  FDK fea file syntax:
  position cursive glyph.name <anchor x y> <anchor x y>;
  The location of anchors is written exactly as they’re stored in the UFO in a rounded integer type. The first value record is the entry and the second is exit. If a glyph is missing one of these anchors, its location should be written as NULL <anchor NULL>.

  Glyphs app

  The anchor can be defined by writing #entry or #exit on the anchor name.

• MarkToBase, MarkToMark, MarkToLigature, MarkClass

  ufo2ft

  Its mechanism is based on the Glyphs app and in turn older mark feature writers. In ufo2ft if any of the supported features are already present in the feature file, it is not generated again. ufo2ft parses anchor.name using regular expressions and according to its results creates an object called NamedAnchor. This object is used to make all the mark related features and it has three main variables:

  • isMark bool variable. Any anchor that starts with mark prefix which is typically a _. If the parent glyph have any isMark anchor then the glyph should be a mark type, otherwise it should be a base or ligature type. Examples:

    • If anchor.name == _top -> isMark = True
    • If anchor.name == top -> isMark = False

  • key string variable. This is used to diffenetiate mark class types (e.g. top or bottom). Examples:

    • if anchor.name == _top -> key = top
    • if anchor.name == bottom_2 -> key = bottom

  • number int variable. This is used for logical order of mark in the ligature and it can also indicate if the parent glyph is a ligature type. Examples:

    • anchor.name == _top -> number = None
    • anchor.name == top_2 -> number = 2

  • Any glyph types (ligature, base, mark) should be defined in the GDEF part of the feature file in UFO. Otherwise, variables of NamedAnchor are used for its type definition.

  • ufo2ft creates mark features data while iterating NamedAnchor objects collected from the UFO glyph anchors:

  • If the NamedAnchor is not a mark e.i. isMark == False (e.g. top, top_1):

    • If NamedAnchor has a number (e.g. top_1):

      Define MarkToLigature positioning inside the mark feature according to NamedAnchor.key and put the anchor in the order according to its number:

      position ligature glyph.name 
                  <anchor x y> mark @MC_top					               # number = 1
                  ligComponent
                  <anchor x y> mark mark @MC_top;        					 # number = 2;
                  
      						# MC in the class name stands for Mark Class
      

    • If NamedAnchor doesn't have a number (e.g. top):
      Define MarkToBase positioning inside the mark feature according to its key:

      position base glyph.name <anchor x y> mark @MC_top;
      

    • If the parent glyph contains an isMark NamedAnchor (e.g. top) define the current NamedAnchor (e.g. _top) as MarkToMark positioning inside the mkmk feature:

      position mark glyph.name <anchor x y> mark @MC_top;
      

  • If NamedAnchor is a mark (e.g. _top):

    • Define a MarkClass class definition using its key (e.g. top)

      markClass glyph.name <anchor x y> @MC_top;
      

• While defining mark features, this is considered:

  • In the MarkToMark positionings, the lookups for different mark class types are separate. For example top and bottom mark lookups are defined separately, and the lookups get a MarkAttachmentType flag to ignore processing any other mark classes. For example lookup for MarkToMark positioning of bottom marks gets:

    lookupflag MarkAttachmentType @MC_bottom;

  • Script (writing system) exceptions:

    • If any glyph is considered an indic script (Beng, Cham, Deva, Gujr, Guru, Knda, Mlym, Orya, Taml, Telu) then its feature is not defined inside the mark or mkmk feature. Instead according to the following criteria they go to above mark feature abvm or below mark blwm feature:

      • If name of anchor belongs to these sets:

          abvmAnchorNames = {"top", "topleft", "topright", "candra", "bindu", "candrabindu"}
          blwmAnchorNames = {"bottom", "bottomleft", "bottomright", "nukta"}
        

      • Else if anchor position is above or equal to the middle of UPM then it’s above mark; otherwise, it’s below.

Glyphs app

Tibetan script (tibt) mark features do not go to abvm and blwm features but just one mkmk. Its lookup also doesn’t get lookupflag MarkAttachmentType as that prohibits the attachment of marks to different anchors than the previous mark.

FDK mark feature writer

• The anchors that are specific to Indian scripts must be named abvm (for Above Marks) or blwm (for Below Marks), and the Indian scripts option needs to be checked in the UI.
• The MarkAttachmentType lookupflag is no longer added to MarkToMark lookups meant for the abvm and blwm features (Indian scripts).
• All the combining mark glyphs must be added to an OpenType class named COMBINING_MARKS. I guess this is to avoid generating mark for glyphs which don't need to have mark positioning feature.
• When designing the combining marks, often there's the need to make specific versions for uppercase and small cap glyphs, which are slightly different from the lowercase. For this reason, one might want to use a casing tag in the anchors' names (e.g. _aboveLC, _aboveUC and _aboveSC instead of just _above for all the three cases) so that the position of the anchors can be tested in FontLab. But this distinction is not necessary for the mark feature, and that is why this script allows for those casing tags to be trimmed, by setting the value of kDefaultTrimCasingTags.
• If the font has ligatures and the ligatures have anchors, the ligature glyphs have to be put in OpenType classes named LIGATURES_WITH_X_COMPONENTS, where X should be replaced by a number between 2 and 9 (inclusive). Additionally, the names of the anchors used on the ligature glyphs need to have a tag (e.g. 1ST, 2ND) which is used for corresponding the anchors with the correct ligature component.

I dropped some minor details. For more details read the source of markFeatureWriter in ufo2ft or WriteFeaturesMarkFDK in python module repo of the FDK.

What’s the issue

To interpret what’s the purpose of anchor there is lots of guesswork on the anchor name and glyph data during the binary compile. Some features are generated only on the compile without getting exposed to the user (composites anchor propagation). Writing OpenType features is a user’s job, not the compiler. An authoring tool could automate some of it (like propagating composite anchors) but there shouldn't be anything left for compiler's guessing. Also for the sake of transparency adding some attributes to anchor can help to remove the guesswork and give more control to the user. My suggestion is either to have an anchor lib or the following attributes:

Anchor Definition

Explicit anchor attributes to define its definition:

• There could be an anchor.type string attribute as there can’t be two types per anchor (Entry, Exit, MarkToBase, MarkToMark, MarkToLigature, MarkClass).
• There could be an anchor.index for the anchor in the MarkToLigature anchor type. One might say this could be interpreted from the anchor order inside the glyph, but it’s not easy to read it for humans. Also, it should be visible for the user that logical order in RTL scripts is starting from the right. Adding any numbers to the anchor.name could also add more to the guessing and is best to be avoided. In the Glyphs app, numbers could be added to anchor names because anchors with similar names are not allowed.
• If all the attributes above exist, then the class/key (e.g. top, bottom) can be written in the anchor.name and there can be multiple anchors with the same name in the glyph but with different anchor.type.

Lookup definition

Still, the compiler needs to guess how to write the flags, lookups and which feature the anchor definitions belong to. Again this can be automated by an authoring tool and saved in the UFO but it shouldn't be a compiler's guesswork. This could be achieved with data structures on the font level and anchor could reference that data. This could be one way of doing it:

• anchor.flags or anchor.lookups list, so the tool explicitly writes the lookup flags instead of the compiler. The list items can be flags or the lookup name in string type. This attribute also helps to create separate lookups if needed. If anchor.lookups is added, then there should be another place to write the lookup information (e.g. font.lib) and there is no need for feature attribute since the lookup should have a list of features which it belongs to.
• anchor.contextBefore and anchor.contextAfter list attributes that are used in Arabic and Indian scripts. The list items can be a glyph.name or a group name or list of glyph.name(s). FDK has a nonpublic script to write this based on the anchor name and it has limitations for writing the context.

In the end, maybe anchor.lib could be an easier solution instead of adding all these attributes. Since there is no anchor lib in UFO, personally I'm thinking that I will write the mark feature inside the data folder. I might have my own syntax for the feature file which is easier to read and diagnose but I haven't finished it yet.

[schriftgestalt]

I think Glyphs.app uses a naming scheme … For ligature anchors it would use _name_1, _name_2 etc, afaik, may be not fully correct though.

The ligature anchos are without underscore prefix.

Would defining glyph.lib["public.*"] keys for glyph type and ligature component count be helpful?

Glyphs.app defines several attributes for each glyph: script, category (letter, mark), subCategory (ligature, nonspacing), decomposition (list of glyphInfo objects (that each have all the above info)). ligature component count can be computed from the decomposition info (iterate it and count the number of none mark glyphs).

As explained in the issue you reference, adding lib to anchor is problematic, so please focus on solutions that don't require that.

In the issue it stats that is complicated and .ufo doesn't support it. Both problems can be solved.

Regarding anchor.type: what are the needed values for such a field? In the above comments I read:
base, mark, ligature, entry, exit

sometimes anchos are only used to position components. That can be true for all five types. So a flag that says: Don't consider when generation GPOS.

For entry and exit a prefix is needed to differentiate it from the mark anchor. The prefix for mark anchor is _, the prefix for cursive anchor is # so it becomes #entry or #exit.

entry/exit anchor don’t need differentiations. They have a unique name. If you add any suffix (a '#' or an emoji) the anchors are used to (cursively) position components but are ignored when generating GPOS (see above). I see how it could be possible to add options to have multiple cursive lookups. But maybe I’ll wait what is decided on this topic here.

About the "Anchor Definition" and "Lookup definition":
this is a very detailed and good description what is needed. But it might be too complex for most people. We need to find a good balance.

[schriftgestalt]

the anchor.type should allow custom types. e.g. In Glyphs.app, you can add a 'LSB' anchor to define alternate metrics for the palt feature (used in CJK fonts)

[benkiel]

My understanding of the current state is that we're going to add a .lib to the anchor, with that any type can be stored.

[schriftgestalt]

Good. The comment was just for the .type case.

[benkiel]

@schriftgestalt I think @justvanrossum has folded on this, .lib seems to be current consensus. We'll want to register some standard keys for anchor for common uses, of course.

[schriftgestalt]

I understand. I had wrote that just before he meeting and posted it because I had written it.