Diacritics for uppercase glyphs

mauro sacchetto

In constructing accented characters with the anchor system, I am faced with this problem.

I have eg. acutecomb, which is placed with the command "Element - Build Accented Glyphs" above the preselected glyph of the | a |.

But then I created an acutecomb.cap for uppercase, which has a different design.

However, if I do the above procedure for an uppercase, the command still uses acutecomb and not acutecomb.cap.

Is there a way that the automatic positioning is done precisely with the appropriate combinig glyphs, that is, for uppercase, .cap?

Thank you

ms

Craig Eliason

I think you have to start this kind of question with what the software you're using is.

mauro sacchetto

Right! Here, on Linux, I'm using FontForge (later, I'll do a test on my Mac with Glyphs)

Adam Jagosz

https://fontforge.org/docs/techref/accented.html

I can't remember whether acutecomb.cap ever worked for me in FF, but I checked now and it seems Acutecomb works.

mauro sacchetto

Yes, you're right. Thank you! I believe that using one form or the other is the same, even if the form in .cap (or, as others propose, .case) is the same, since they are not unicode-encoded glyphs. Or am I wrong?

Florian Pircher

Capital marks are not encoded separately in Unicode. The Glyphs convention for automatic code generation would be to end the name in ‘.case’ for marks intended to combine with capital letters, but any naming convention works fine for manual feature code.

mauro sacchetto

After some tests, I seem to have realized that the accents for capital letters that the automatic building considers are those with a simple name, but with a capital initial. as @AdamJagosz said.

For example, when composing |A| + |grave|, you have to create the grave accent by calling it |Grave|, because the other combinations do not seem to work.

Neither |gravecomb.case| nor |gravecomb.cap| work.

If I am right, it is not entirely correct either what is stated in the guide https://fontforge.org/docs/techref/accented.html:

«So in such a font, if you attempt to build |Agrave| FontForge will build it out of |A| and |Grave| (or |grave.cap|, Not the standard | grave|).",

because only the first indication is correct, while, like those I indicated above, not even |grave.cap| is recognized.

In any case, it seems no to be a big trouble, for, as @FlorianPircher said, here there is no Unicode standard.

george_thompson

I use Fontlab and added various cap+diacritic.case to the alias.dat file. Same thing with small cap accents where needed.

mauro sacchetto

I apologize for the delay in replying. I use FontForge under Linux and am trying to learn how to use Glyphs on the Mac. I ignore this type of .dat file. Are they interoperable and how are they constructed? Thank you!

John Hudson

The Glyphs convention for automatic code generation would be to end the name in ‘.case’ for marks intended to combine with capital letters...

Not a convention I like. The suffix .case implies these mark glyphs would be utilised in the <case> OTL feature, but that feature is specifically for all-caps settings, not just capital letters in general. I use the suffix .cap for such mark glyphs, and if I am using them in GPOS mark positioning features I substitute them for their default forms contextually in the <ccmp> feature when preceded by either uppercase letters or ascender letters (yes, I take the view that what determines the use of the typically flatter .cap marks is the height of the base letter, not its case).

Florian Pircher

By that logic, .cap is not a much better naming scheme since a .cap mark would also be used for non-capital letters. .compact? .cmt? .flat?

John Hudson

In math typesetting, they’re referred to as flattened accents, and are used in vertical equation stacks.

Although .cap originated in the context of marks designed for use on capital letters, I suppose I think of it as something like a cap stone that you put on top of something high.

mauro sacchetto

Beyond the interesting discussion on .case and .caps. I still don't understand what kind of file this alias.dat is. Is it only available on Fontlab? And what is its syntax anyway?

Thomas Phinney

mauro sacchetto said:

Beyond the interesting discussion on .case and .caps. I still don't understand what kind of file this alias.dat is. Is it only available on Fontlab? And what is its syntax anyway?

It is a FontLab-specific format, although pretty simple.
https://help.fontlab.com/fontlab/7/manual/Custom-data-files-and-locations/

John Hudson

Glyphs has a similar GlyphData.xml file, a default version of which resides with the app but which can be overridden by an edited copy stored with a font’s .glyphs source file.

The FontLab alias.dat file is plain text and pretty easy to edit in a text editor or spreadsheet. The Glyphs GlyphData.xml file is a bit less friendly to edit because of its structure, but Glyphs provides an editing tool.

The Glyphs xml file contains a lot of information about glyphs, including default names, unicode mappings, variant names, default order, decomposition, etc.

The FontLab alias.dat file is just one of several glyph data files used by FontLab, all of which can have user overrides.

Florian Pircher

george_thompson said:

I use Fontlab and added various cap+diacritic.case to the alias.dat file. Same thing with small cap accents where needed.

Note that for this particular use case, you don’t need to create or edit a custom GlyphData.xml file. A glyph named, e.g., acutecomb.case or acutecomb.flat or acutecomb.sc etc. will inherit all of the relevant glyph metadata from the acutecomb glyph, which already has an entry in the standard GlyphData.xml. (You can see and query the standard entries in Window → Glyph Info.)