[Fontforge-devel] Accents and anchors

[Tavmjong Bah]

Hi George,

I have used the Build-Accented-Glyphs command to build characters in
the Latin Extended and other blocks. This works quite well in most cases
using anchors. However, the recent change in Pango to using anchors to
align adjacent glyphs has exposed what I have long believed to be a
problem with how FontForge builds accented characters. FontForge (for
"postscript" reasons according to a comment in the code) chooses to
build preferentially with accents in the Spacing Modifier Letters (SML)
range. I thus added anchor points to these accents. Pango now uses these
anchors to align the accent above a previous letter rather than leaving
it to the right of the letter as should happen for SML characters. One
could argue that this is a flaw in Pango but I believe that the SML
characters should just not have anchors.

There are a few other problems with the use of accents in the SML
range, primarily with using the same accents for both above and below
diacritical marks:

1. FontForge replaces accents for capital characters even for accents
that go below a base glyph. This means that the below accents for lower
case and upper case characters are different.

2. Using the same accents for below and above a base glyph requires two
anchor points, creating a problem in choosing the right one to use.

3. Using the same accents for both above and below a base glyph removes
the possibility of customizing the below accents to take up less space
(much like the use of special capital letter accent like breve ->
Breve). May be not a real problem.

It seems to me that unless there is a real compelling reason to use
accents in the SML region that it would be better to prefer those in the
Combining Diacritical Marks block.

I've attached a diff file for a version of fvcomposit.c that I've used
for the past 6 months that works around some of the problems I had. It
forces FontForge to use a combining mark for below accents thus
alleviating the need for multiple anchor points in spacing marks. (It
does not change the preference for spacing vs. combining marks.) The
changes also handle double accents. It is an ugly hack but worked for
me. I hesitate to provide a better "patch" without knowing what would be
excepted as the existing code is quite complicated and it would take
some time to understand it fully.

Tav

[Alexej Kryukov]

to these accents. Pango now uses these anchors to align the accent
above a previous letter rather than leaving it to the right of the
letter as should happen for SML characters. One could argue that this
is a flaw in Pango but I believe that the SML characters should just
not have anchors.

Indeed, this is a flaw in Pango, as "mark" and "mkmk" features should
not be applied to characters which apparently are not combining
marks. On the other hand, adding anchors to SML characters looks
quite ugly by itself, so that I have to agree with your last statement.

It seems to me that unless there is a real compelling reason to use
accents in the SML region that it would be better to prefer those in
the Combining Diacritical Marks block.

I would strongly argue against this. In my fonts I prefer to add
combining marks at a quite late stage (i. e. after many accented
characters), and implement them as references to spacing diacritics.
This is mainly because it is quite easy to select a correct positioning
for a spacing accent (all that one needs is to figure out a standard
width for such characters and make them visually centered), but
positioning combining marks requires some additional work (especially
if we would like them to look reasonably good at least in combinations
with some base letters even in those applications which don't support
OpenType). Thus I can't be absolutely sure that I never will move my
combining diacritics left all right, thus breaking all already existing
accented characters.

Also, note that for the most common spacing accents there are "capital"
counterparts, which have their own names and standard positions in PUA
assigned by Adobe. There is no such commonly accepted convention for
combining marks.

To my mind, a more elegant (but, of course, more difficult in
implementation) solution might be as follows: would it be possible to
introduce a special flag denoting if a specific anchor point should be
included into GPOS tables, or used only for generating accented
characters. Don't know, if it would be better to make such a flag a
property of an anchor point itself, or of an entire anchor class...

[George Williams]

Post by Tavmjong Bah
I have used the Build-Accented-Glyphs command to build characters in
the Latin Extended and other blocks. This works quite well in most cases
using anchors. However, the recent change in Pango to using anchors to
align adjacent glyphs has exposed what I have long believed to be a
problem with how FontForge builds accented characters. FontForge (for
"postscript" reasons according to a comment in the code) chooses to
build preferentially with accents in the Spacing Modifier Letters (SML)
range. I thus added anchor points to these accents. Pango now uses these
anchors to align the accent above a previous letter rather than leaving
it to the right of the letter as should happen for SML characters. One
could argue that this is a flaw in Pango but I believe that the SML
characters should just not have anchors.

That seems reasonable behavior for Pango.
I had not actually expected you to be using anchors that way. If you
don't want Pango to use those anchors then you can create your own
feature name. Pango won't apply it if it doesn't recognize it.

Post by Tavmjong Bah
2. Using the same accents for below and above a base glyph requires two
anchor points, creating a problem in choosing the right one to use.

Good point.

Post by Tavmjong Bah
It seems to me that unless there is a real compelling reason to use
accents in the SML region that it would be better to prefer those in the
Combining Diacritical Marks block.

Oh there are several. Alexej has mentioned some. Here's another:
The latin acute accent, the greek tonos and greek oxia accents have been
unified to 0x0301. Unfortunately acute and tonos don't look anything
like each other.

Post by Tavmjong Bah
I've attached a diff file for a version of fvcomposit.c that I've used

I suspect a better solution would be to allow the user to customize the
search order.

[Alexandros Diamantidis]

Post by George Williams
The latin acute accent, the greek tonos and greek oxia accents have been
unified to 0x0301. Unfortunately acute and tonos don't look anything
like each other.

Tonos (which means "accent" in Greek) might look like an acute, or it
might not - it's a font design issue. It can look like an bullet, a
down-pointing wedge, or a short vertical line, but only in fonts
supporting only monotonic Greek. In fonts that want to support polytonic
Greek, tonos and oxia (="acute") should look the same, like an acute, in
contrast with varia (="grave"). Some fonts don't do this (i.e. they have
a vertical "tonos" and an acute "oxia"), but I think that since greek
letters with oxia and with tonos are canonical equivalents according to
Unicode, they should display the same.

For a few words more on this, see the following:

http://ptolemy.tlg.uci.edu/~opoudjis/unicode/unicode_gkbkgd.html#oxia
http://diacritics.typo.cz/index.php?id=68

Anyway, apart from issues with Greek, even in a purely latin font the
acute can look different on different letters: On capitals it's
generally more slanted, so as to fit in less vertical space...

[George Williams]

Post by George Williams
I suspect a better solution would be to allow the user to customize the
search order.

Here's a patch which adds a preference item.
File->Preference->Accents->PreferSpacingAccents

[Alexej Kryukov]

Post by George Williams
That seems reasonable behavior for Pango.

Well, this question has very few to do with FF itself, but I
don't think this behavior is really reasonable. To my mind,
any mark positioning features should be applied only to combining
marks, i. e. those characters which either have the corresponding
Unicode property, or have their OT glyph class explicitly set to
"Mark". At least MS Uniscribe behaves by this way.

[George Williams]

Post by Alexej Kryukov

Post by George Williams
That seems reasonable behavior for Pango.

Well, this question has very few to do with FF itself, but I
don't think this behavior is really reasonable. To my mind,
any mark positioning features should be applied only to combining
marks, i. e. those characters which either have the corresponding
Unicode property,

Many of the greek accents do not have combining variants, and so this
rule will not work.

Post by Alexej Kryukov
or have their OT glyph class explicitly set to
"Mark". At least MS Uniscribe behaves by this way.

FF enters every glyph with a mark anchor point as a Mark glyph in GDEF.
How else could it behave?

[Alexej Kryukov]

Post by George Williams
Many of the greek accents do not have combining variants, and so this
rule will not work.

Nevertheless using those accents in any Unicode texts is strongly
discouraged. Even capital accented letters, although they look
exactly like a spacing accent followed by a vowel, have a quite
different decomposition. For example, capital Alpha with smooth
breathing and acute can be represented either as uni1F0C or as
Alpha + uni0313 + acutecomb, but NOT uni1FCE + Alpha.

For this reason the correct way to handle Greek accents in an OpenType
font is the following:

-- create combining versions for all Greek accents and breathings and
their combinations (I call them 'acutecomb.grek', 'uni0313.grek',
'uni0313_acutecomb.grek' and so on) somethere in the PUA and assign
the OT glyph class 'Mark' to all such characters;

-- provide a contextual substitution rule which would replace
standard combining acute, grave and commas above with their Greek
versions each time they follow a Greek letter;

-- provide a 'ccmp' rule replacing any "accent + breathing" pair with
the precomposed combination for this pair.

This method has at least one advantage: it really works with MS
Uniscribe. Note that it doesn't involve any spacing diacritics.
(However I still prefer to use them as a base for composite glyphs,
as I have described in another mail. I. e. 'uni0313_acutecomb.grek'
actually contains a reference to 'uni1FCE' in my fonts.)

Post by George Williams

Post by Alexej Kryukov
or have their OT glyph class explicitly set to
"Mark". At least MS Uniscribe behaves by this way.

FF enters every glyph with a mark anchor point as a Mark glyph in
GDEF. How else could it behave?

I think FF does everything correctly at this point. The font
editing application should not prevent user from adding anchor
points to any characters where (s)he would like to have them.
However, a correctly designed OT renderer should use anchor
point for attaching only those characters which actually can be
recognized as combining marks; otherwise any anchor points
must be ignored.

So this is a flaw in Pango, not in FF.