[Paps-discuss] (no subject)

[Thomas W. <to...@to...>]

Arne Götje (高盛華) wrote:
> The fonts need to contain a) the base glyphs b) the combining 
> accents c) "anchors" in the GPOS table to tell the rendering 
> engine where exactly to place the accents. In fontforge this is
> done easily. :)

Jan Willem Stumpel wrote:
> ...
> So the advice to users has to remain: use pre-combined accents
> whenever possible. Don't count on the "combining accents"
> mechanism to work. It won't, except from some lucky cases.

Arne Götje (高盛華) wrote:
> yes, it depends totally on the font to define the *position* of the
> accents (and weather or not they can be stacked). But it depends on the
> rendering engine to *interpret* the information the font gives about the
> accents.
> 
> BTW: there was no irony in my statement. In Fontforge it is really easy
> to define the "anchors". For all pre-composed Latin based combinations,
> you can get it done with around 10 anchor classes, including the stacked
> ones for Vietnamese.
> 
> The difficulty is to decide how the combinations should be displayed,
> i.e. which "standard" to follow and which scripts to support.
> You need to define the anchor points, both for the base glyphs and the
> combining accents, separately and for each possible combination. This is
> quite some work...

Rich Felker wrote:
> Well there are two flip sides to this situation. On the one hand
> you're right, but on the other hand if no one tries to use the
> combining characters, applications and fonts will remain broken. :(
> Since I need to use scripts where combining is essential, I'm somewhat
> inclined to hilight the brokenness in apps (by using combining chars
> in more situations) in hopes that the authors will fix them...

Arne Götje (高盛華) wrote:
> In this case, *you* need to *define* which combinations you need and
> *how* they should be displayed. If they exist already as pre-composed
> glyphs in Unicode, then it's no problem to implement them... but if not,
> it's up to you to do the definition first and then either to modify
> existing fonts by yourself (e.g. by using fontforge), or ask the
> upstream author of the fonts to do it for you.
> 
> So, I suggest, you make a list of which combinations you need (and how
> they should look like) and ask the upstream maintainer of the font of
> your choice to implement them for you. ;)
>
> If the application of your choice then still cannot display the
> combinations correctly, prod the maintainers of that application to
> either use a rendering engine which can interpret the GPOS table of TTF
> fonts, or hack the support in by themselves, or (the best solution)
> forward the request to the upstream maintainer of the rendering engine
> they use...

Rich Felker wrote:
> *nod* these are all good suggestions.
Not in practice, I'm afraid.

Jan Willem Stumpel wrote:
> In the meantime I found that most fonts on my system do *not* have
> this table (including the Bitstream Vera fonts and the MS "core"
> fonts). It seems that including such a table is one of the things
> that we must "badger" upstream font developers about.

It was interesting that Arne pointed out that the problem could in theory 
be solved by fixing fonts but I don't think it's appropriate 
to shift the task of fixing the issue to fonts and their providers, 
because that approach is not reliable and not practical given the 
huge number of existing fonts and the small number of rendering engines.

Rather a font rendering engine should do the following:
* If anchor points are defined in the font, they should of course 
  be used.
* In absence of appropriate font information, the rendering engine 
  should determine the bounding boxes of base character and accent(s) 
  which should easily enable it to apply some kind of best-guess 
  approach to place the accent to a proper location.
  The engine should maintain a list of which accents are (normally) 
  placed on top or below, and whether the standard position is 
  with a gap or not (sometimes below), centered or attached to an edge.
  For italic or oblique fonts, the slanting angle should be considered 
  for best possible placement.
* If the font does not contain the appropriate accent and the 
  rendering engine provides the feature of font substitution, the 
  accent should be taken from a different font. For maximal 
  consistency of style, neither the base character nor a precomposed 
  character should be taken from that other font (unless the base 
  character itself is missing in the current font).

I actually implemented an automatic accent placement algorithm myself 
quite a while ago for fixing PostScript fonts; I wrote a PostScript 
program that would compose the Latin-1 set of combined characters from 
base letters and accents automatically and save an updated PostScript 
font. This way I could make use of the many free PostScript fonts that 
used to be made by amateurs, often just containing the Adobe standard 
encoding characters.

Kind regards,
Thomas