[HarfBuzz] Why mark glyphs are skipped when MarkBasePos matching?

[Shusaku KIMURA]

Dear Mr Wordingham.

Thank you for the reply. The replies from you and Mr Hosken give me
very helpful information.

> Describing it as "ignoring all marks" is a confusing way of putting
> it; "processing all marks" would be better.

Yes, I understand that the goal is 'processing all marks' as you
mentioned and 'ignoring all marks' is just the way to the goal.


> Yes.  For example Tahoma Version 5.2, installed in Windows 7, uses a
> single lookup with a single subtable for positioning marks on bases
> in Thai.  The combination of a vowel below and a tone mark above is
> quite common.

Thank you for the information.


> The rules about the association of marks and bases and components of
> ligatures are not as clear as they should be...

OK. Thank you for the information.


> There are many places where the behaviour of HarfBuzz is derived not
> from the specifications, but from an analysis of the behaviour of
> Uniscribe.

So that means Uniscribe also has behaviors not described in the
specification, even though Uniscribe is implemented by Microsoft who
is the writer of the specification. Is it correct?

Anyway, I get that there are no documents which is absolute and
trustworthy for the implementer. Are there any contacts to report such
unclearness or ambiguity of the specification?


Thank you,

2019年3月26日(火) 19:32 Richard Wordingham <richard.wordingham at ntlworld.com>:
>
> On Tue, 26 Mar 2019 13:33:29 +0900
> Shusaku KIMURA <skimura0 at gmail.com> wrote:
>
> > Thank you for quick and kindly response.
> >
> > > One could have two lookups, one ignoring marks above, and one
> > > ignoring marks below, but that requires GDEF to categorise marks as
> > > marks above or as marks below.
> >
> > Do you mean Mark Attachment Class Definition Table in GDEF?
>
> Yes.
>
> > Certainly,
> > it would be possible to be solved by Mark Attachment Class Definition
> > Table and two lookup tables of different markAttachmentType.
> >
> > I agree this solution is more complex than HarfBuzz's solution
> > (ignoring all marks), but I believe this solution is the way of
> > conforming to the OpenType Layout specification. Therefore I am not
> > sure whether the HarfBuzz's solution is really necessary.
>
> Describing it as "ignoring all marks" is a confusing way of putting it;
> "processing all marks" would be better.
>
> > I suppose that there was actual font data which expectes such
> > behavior, and the implementation was needed. Is this correct?
>
> Yes.  For example Tahoma Version 5.2, installed in Windows 7, uses a
> single lookup with a single subtable for positioning marks on bases in
> Thai.  The combination of a vowel below and a tone mark above is quite
> common.
>
> > > A major complaint about OpenType is
> > > that the syntax of font files is defined, but not their semantics.
>
> > I am not familiar with whole of the OpenType specification, but I
> > studied OpenType Layout specification, and I agree with you for
> > example about BASE table. But GSUB and GPOS table are relatively clear
> > about the semantics including this topics, I think.
>
> The rules about the association of marks and bases and components of
> ligatures are not as clear as they should be.  For example, there is a
> rule that marks on different components of a ligature do not interact,
> e.g. cannot ligate with one another or be positioned relative to one
> another. This rule is not in the specification.  While this works for
> Arabic, there are scripts where two bases ligate and their marks may
> interact.
>
> > For HarfBuzz, is OpenType (Layout) specification not always absolute?
>
> There are many places where the behaviour of HarfBuzz is derived not
> from the specifications, but from an analysis of the behaviour of
> Uniscribe.
>
> Richard.
> _______________________________________________
> HarfBuzz mailing list
> HarfBuzz at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/harfbuzz



-- 
Shusaku KIMURA
skimura0 at gmail.com