Combining mark glyphs should be zero-width. [The exception is in monospaced fonts, in which the combining marks must have the same advance width as all the other glyphs. In this case, the width is collapsed in the GPOS lookups as part of the mark positioning.]

It doesn't matter where on the zero-width the actual outline is positioned. Typically, the default position is set to offset the mark over the preceding letter in cases where GPOS mark attachments are not supported. So for left-to-right scripts the outline is offset to the left of the zero-width, and for right-to-left scripts it is offset to the right. [The exception is Hebrew, in which the marks are typically centered optically on the zero-width, which allows them to be used by legacy Hebrew engines that employed algorithmic horizontal positioning.]

The most recent Adobe fonts follow the same approach John described for Hebrew fonts above, i.e. centering glyphs optically on the zero width.

Okay, thanks so far.

It doesn’t matter where on the zero-width the actual outline is positioned.

That's what I assumed. It seems I'm making some mistake elsewhere -- just for laughs I moved the accents to the right side of the zero line, and the results are exactly the same in OTMaster (correct) and CS4 (wrong).

The acute is right after the 'm' and should be on top -- adding an extra 'm' after that shows the position is correct, apart from the minor issue it's too far to the right.

The mk2base is now in 'rlig', I'll put them somewhere else and see what changes.

Is my face red and all. I said

The mk2base is now in ’rlig’ ...

and remembered Microsoft has a list of which feature should go where. That got me thinking. mark and mkmk are the feature names (and the only stuff that goes into these are the commands that perform the actual attachment) -- they shouldn't occur in rlig or anywhere else.

(This solves the shifting-to-the-right -- have to think a bit more about mkmk.)

Well, call me officially stumped.

This is with all accents centered in a 500 unit wide box, with zero width:

in lowly Windows' WordPad. (See also note below.) This is the same font in DTP powerhouse CS4:

As you can see, the top (mkmk) accents go wildly out of whack. It doesn't matter whether I add a bottom accent or not -- the result is the same.

I don't trust my OTF font making abilities enough, so I did the same using Legendum, with this result (CS4):

and SIL Doulos -- top WordPad, bottom CS4:

-- so it seems mkmk doesn't really work in CS4, while I'm pretty sure it was mentioned as a new feature (perhaps even here on Typophile).
I'd be gladly proven wrong. Anyone?

--
[Note] For some reason my custom glyph names-per-unicode do not survive the export to PFB/makeOTF trajectory, they never make it into the PFB. Custom names are preferred, because it makes writing the feature file just that bit easier (using "macroncomb" and "opene" rather than "uni030F" and "uni2011"). A rather unfortunate side effect is that these glyphs don't appear in Wordpad.

Theunis, this is a known bug in CS4 http://typophile.com/node/52173

Miguel, thanks for affirming it hasn't bin fixed as of this date.

As you can see by those older posts (and the even older one referred therein), it's quite the issue for me -- that's why I keep trying. At the very least, Wordpad -- of all possible programs! -- showed me there is nothing wrong with my understanding of the AFDKO (and I'm really thankful to Adobe for their free dev kit! It does tie in nicely to my scripting abilities.)

Note To Self: Try again in another 6 months :-(

At the very least, Wordpad — of all possible programs! — showed me there is nothing wrong...

If you want a really pure test of whether something might be wrong with the font, NotePad is even better than Wordpad: just the font and the layout engine, and nothing else to get in the way.

No feature bloat, eh? Thanks, I'll keep it in mind for the next time 'round.

Today I did some tests with Notepad, WordPad and Word 2007 using Doulos SIL, and the above combining accents don't stack more than 3 times. Is this a reasonable limit? Should there be any limit at all?

I understand this limit is not being imposed by the font; FWIW, I've opened the same RichText file in OS X's TextEdit and the 7 above combining accents I used were all visible and stacked vertically.

Miguel,

a limit of 3 seems like a strange way of implementing it in the font.

The Windows Vista/Windows 7 versions of Arial and Times New Roman can stack accents pretty infinitely in Notepad or Word 2007, last I checked.

Cheers,
Adam

I didn't say the limit was in the font. I don't think it is.

I'm also using Windows Vista and Word 2007 (v12.0.6425.1000). Just tried Arial and TNR, and I only see 2 or 3* accents. The other accents might be there, but I can't see or print them.

* sometimes 2.5 depending on the size of the text and the accents used

Guys -- thanks for delving a bit deeper into this.

I don't think there is an implementation defined limit to the number of stacked accents; I can't remember reading anything about that. Besides, there seems to be no way of knowing which 'number' one particular accent has in its stacking order. mkmk accents only have positions relative to the preceding one, and the very first relative to its parent glyph.

That said, I'm also not sure why there would be a hard-coded limitation in an OTF drawing routine, it could be written as a simple repeating piece of code (at least, that's how I would've done it ;-).

I suspect it's more a bug (or 'feature') in the way type gets blitted; it may be to a buffer restricted to the current font height plus ascenders, something like that. Do Word, Notepad, and Wordpad all use the same drawing APIs? (And -- again, just suspecting -- the answer is likely to be 'yes'.)

[In brackets, not directly related to the issue you describe. There may be no limit to the number of marks stacked. Yet if you intend to kern base glyph combinations depending on marks sitting above or below them to avoid clashes, in which case mark glyphs serve as context, you are forced to "limit" the number of mark glyphs taken into consideration for the simple reason that context is always a specific context. Add one more mark to the string and your kerning will stop working.]

Back to the IDCS4 issue, perhaps this might help.

Miguel, I believe the limit you report is a clipping zone issue. In Word, try setting the linespacing in the paragraph dialogue to an exact leading value, rather than a multiple of the default linespacing; this should reveal all the stacked accents

Also, printing to PDF should reveal them even if they are hidden in Word.

[The illustration shows the Win7 version of Cambria, in Word on exact leading, with mark-to-base and mark-to-mark attachment implemented.]

Hey, a new way of typing "aaaaaahhhh..."!

Thanks, John -- that makes perfect sense. I seem to have guessed right :-)

.. printing to PDF should reveal them ..

Wordpad didn't show my accents either until I printed to PDF -- although Miguel did say

.. I can’t see or print them

Still, nothing to worry about for font developers, as it must be a software thing: Trying to catch up with the standard :-D

Thanks for the tips. I shall try again.

On a related note, is there a real-world example of an orthography that stacks more than two accents in each direction?

If there is it must be something along the lines of Guillaume Apollinaires work, Merz or DADA (collage).

. . .
Bert Vanderveen BNO

My examples above are based on that old chestnut ie_fun.jpg (David Bürgin's thread Anchors in Fontlab?):

which is Indo-European reconstructed stuff (recognizable by its initial asterisk). This stacks tons of stuff on top, but I can't find (nor remember) if same happens belowdecks.

(On 2nd sight, yes, definitely Dadaistic influences! :-)