Building fractions using anchors

I was thinking about building fractions using anchors. I modified GlyphData.xml accordingly and the positioning of numerators and denominators works pretty well.

But the result is not perfect: the metrics is (logically) based on the first element (in case of onehalf the metrics is based on one.numr).

Is there a way to set the RSB for a glyph in GlyphData.xml? Or is there any other way I could build fractions using components aligned using anchors but keeping the LSB of numerators and RSB of denominators?

What is wrong with the LSB of the one.numr?

I’m trying to implement to respect mectrics keys on auto aligned components. That should solve your problem but probably comes to late for your current project.

Anchors are not going to help, I think.

Georg, LSB is fine, RSB is wrong.

I will try to describe it more precisely.

Usually a width of an accented glyph is defined by its base character. This is the situation of ä, č or ñ.

However, there are accented letters that may not share the width of the base letter, for instance ď, ľ, ť or ʼn. When using standard components and anchors, such glyphs require additional adjustment of RSB.

Ideal solution would be to have an option to set the source value for RSB individually in GlyphData.xml.

An example: dcaron – LSB is defined by the base glyph d, the position of the caron.alt is defined by an anchor and RSB would be overridden by RSB of “caron.alt”.

This way one could easily build other composed glyphs. For instance certain ligatures. The distance between letters would be defined by anchors and the LSB and RSB by the defined components.

Glyphs secret: If the accent's name starts with a double underscore ("__caron.alt"), then its width is added to the compound glyph.
1 Like

Mekkablue, YES, this is exactly what I’ve been looking for!!! Thanks!

Mekkablue: my tripple yeah for that! thanks! :slight_smile:

High five :slight_smile:

I’ve been asking Georg personally to resolve the spacing issue of Polytonic Greek cap diacritics, even proposed a solution, only to find here that it already exists :frowning:

Edit: It’s not working in my case (Polytonic Greek).

Toshe, you are right. The aforementioned solution unfortunately only works for RSB. It is perfect for Czech/Slovak ÄŹ, ĹĄ, Äľ and for certain ligatures perhaps.

It would of course be great to have similar workaround for LSB to create ʼn or Greek Ή.

Mekkablue? Georg?

Anyway, I would love to have the possibility to control LSB and RSB dependency of any glyph in GlyphData.xml, for instance:

<glyph unicode=“010F” name=“dcaron” decompose=“d, caron.alt” category=“Letter” subCategory=“Lowercase” script=“latin” description=“LATIN SMALL LETTER D WITH CARON” rsb=“caron.alt”/>

or

<glyph unicode=“0389” name=“Etatonos” sortName=“gr055” decompose=“Eta, tonos” category=“Letter” subCategory=“Uppercase” script=“greek” description=“GREEK CAPITAL LETTER ETA WITH TONOS” lsb=“tonos”/>

Please, forget Afrikaans 'n as a character, unless you’re making some apartheid-IBM-backwards-compatibility historical typeface. It is simply not in use, and there hasn’t been a keyboard for it in 30 years. People type the apostrophe and then the n.

For tonos, I either disable automatic alignment or use alternative base glyphs with extra LSB.

Mekkablue, 'n character was used just as an example of a feature which would make creation of accented letters and glyphs made of components faster and more efficient. I know it is not used anymore.

So I think about a script which would do the required adjustements of LSB and RSB for me. In first round, it would disable automatic alignment, in the second round it would apply LSB/RSB according to a database of preferred LSB/RSB in the script or according to a custom value added to my GlyphData.xml.

It is a workaround, but it can be pretty useful.

Filip,
I think this should be more general solution, ideally not something you need to address on the glyph level, i.e. XML. Besides, specifying LSB by the glyph is very tricky in Alpha diacritics, whose LSB might become actually smaller than the original width (in fact I am making two different Polytonic cap diacritic for this exact reason). There should be a way that Glyphs use the sidebearing of whichever is wider, judging from the glyph name. That double underscore trick should simply work on both sides, shouldn’t it?

I was thinking of a similar script, but I’m hesitant to do so because I strongly think that this should be supported by default. Anyway, my idea goes like this: Enable alignment, Disable alignment, and Update metrics using sidebearing keys.

And disabling automatic alignment is not an option for me.

Tosche, I absolutely agree with you. At the moment I was looking for an efficient solution for dcaron, lcaron and tcaron, and the __ does that trick.

Typing custom LSB/RSB values to glyphs with enabled alignment would come handy: “+caron.alt” or “+50”.

I try to avoid disabling alignment as much as you do.
So I would also prefer a system solution.

Interesting! I'd suggest that "__caron.alt" be added to the Mark Category.

There is another option to build tonos and half caron glyphs.
If you don’t use anchors but set it up like a ligature. The problem is that auto alignment for ligatures only works with letter. So the trick is to make a glyph that contains components of tonos (and all the combination with other marks for politonic) but call is a.tonos (or choose some letter from another script to to get it between your other letters). If yo need to adjust the distance between the “mark” and the base letter, use kerning. This is a bit of a hack but works quite nicely. And I’m working on a better solution. Maybe I manage to apply metrics keys.

That is what I'm doing, which results in two different sets, manually switched depending if kerned component letter actually becomes narrower than the original width of the base letter, especially in Alpha. You have to manually check and adjust (I cannot write a design-independent XML). Another problem is that those fake marks still use anchor positions of the original, even when I tell them to be letters. So I have to decompose them. And when flipped components are involved, some letters just freak out.
Useful for my dcaron and lcaron, not for my tcaron and Lcaron. But I'll just undo the automatic alignment on those two and then set their metric keys to the base letter, right?

For tcaron and Lcaron just use the caron.alt without the underscores.

Sorry to bring back this old topic, but I would like to clarify some ideias. I working with “__caron.alt” on tcaron and lcaron, using anchors and tracking to align them properly. But I have two question:

First, to achieve the right alignment I have to give a very negative RSB to “__caron.alt”. Is that correct?

Second, this solution works nice for combine letters as ťk, but when you combine ťa for example, it doesn’t works so good on bolder weights. What is the best solution? Kerning on those situations?

Yes, kerning is necessary. You have two options: positive kerning for pairs like ÄŹk or negative kerning for pairs like ÄŹa. The second option is better for apps not supporting kerning (the caron remains visible), the first options is easier and faster.

2 Likes