font fragility and mid-word styling

bdenckla
bdenckla Posts: 30
in Font Technology
I have recently submitted a sprawling proposal for six (!) new Unicode code points in the Hebrew block.

The main motivation for this proposal is to avoid what I'm calling "font fragility" when faced with mid-word style changes such as making one letter big, bold, or red.

That is, the main motivation is to lessen the need for fonts to treat a code point differently depending on its context.

I wonder what are the thoughts of the members of this forum on this type of "font fragility" in general. Or is there no general, and it all depends on the specifics?
Tagged:

Comments

  • John Hudson
    John Hudson Posts: 3,497
    What is affecting the layout problems you show is a glyph processing run boundary at the layout engine level—triggered by a change in font, a change in size, or a change in colour (the latter possibly only affecting some shaping engines)—interrupting contexts relied upon by the glyph substitution or positioning lookups in the font. Maybe ‘glyph processing fragility’ is a better way to describe it, and this might also help make clear that this would benefit from a character level solution?
  • bdenckla
    bdenckla Posts: 30
    Thanks @John Hudson, that is a good point, that my phrase "font fragility" sort of suggests it is the font's fault, whereas of course the font can't "reason" about context it isn't given. Neither is it really the shaping engine's fault, except perhaps in the case of those engines that aren't clever enough to handle a color change without interrupting context. It's the encoding's fault. Or, breaking out of the "blame game" (the paradigm of fault), it is a problem I claim is best solved at the character level.

    So, though I would still characterize the font as fragile (it can be "broken" by reasonable styling), that is a symptom, not a cause. The cause is that the encoding currently demands too much of the font; in particular it demands that the font use context too much. This comes from the encoding being ... what shall I call it? Over-frugal (too stingy with its code points)? Parsimonious (in a bad way)?
  • John Hudson
    John Hudson Posts: 3,497
    The cause is that the encoding currently demands too much of the font; in particular it demands that the font use context too much.

    Yes, I would agree with that statement. There are places in Unicode where the encoding choice puts too heavy a burden on glyph processing to resolve correct display of text (Mongolian is, to my mind, probably the most glaring example of this), but when shaping engines and/or fonts fail in particular circumstances, it is reasonable to ask how common or critical these circumstances are? Your document currently indicates the cirumstances in which relying on contextual glyph processing fails, but it doesn’t make a case that such cirucmstances actually occur, let alone with significant frequency. I think this makes the proposal, if you’ll forgive the joke, ‘fragile’.
  • bdenckla
    bdenckla Posts: 30
    edited September 5
    Thanks @John Hudson, I do now see how this is a weakness of my proposal. I should quantify it exactly, but my guess is that there are about 5,000 stress helpers in a Hebrew Bible that uses them consistently. This comes out to about five per page if we assume a typical typesetting, which requires about 1,000 pages for the Bible proper (i.e. excluding introductions, columns for parallel translations, etc.).

    As to how often someone wants to style a letter with a stress helper (e.g. make it big, bold, or red), that is less clear.

    The examples I gave from the Feldheim Simanim Tiqqun showed a "real, live" publication (not teaching handouts, etc.) doing this (enlarging a letter with a stress helper). But I didn't quantify how often they do this. This is not easy to quantify without access to their digital sources, which of course I don't have. I may just have to suck it up and do a manual count on what I hope is a representative sample of pages!

    My failure to quantify the frequency of stress helpers was a particularly big mistake because stress helpers other than pashta are very rare in the BHS edition of the Hebrew Bible, and unfortunately that edition is basically synonymous with the Hebrew Bible for many quite expert students and even professors, particularly outside of the Jewish world. There are many people who know more Biblical Hebrew grammar than I'll ever know but they have never seen an edition that consistently uses stress helpers.

    This makes it all the more surprising (and impressive!) that the Michigan-Claremont encoding bothers to have stress helpers for telisha gedolah and telisha qetanah, since each get only about four uses in the entire BHS!
  • John Hudson
    John Hudson Posts: 3,497
    Quantifying the number of stress indicators in the Bible text isn’t really relevant to the encoding question, I think. There’s a general acceptance that any textual sign that occurs, however rarely, needs to be supported by Unicode (hence the puncta extraordinaria characters). The question will be whether there is, at this stage, a net benefit in changing the model of that support for these particular signs.

    Showing real world examples of where the font level contextual handling fails is, I would say, necessary to your case but not necessarily sufficient. The fact is that all manner of text shaping breaks at OpenType Layout run boundaries, and that isn’t generally seen as a reason to change the encoding model. I would stress the argument that the marks should not have been unified because they have different properties. Unicode marks are typically distinguished by their position relative to the base letter, so e.g. dot above and dot above right are separately encoded, and one could make a case that the difference in positioning of these Biblical signs should be taken into account in their encoding.
  • bdenckla
    bdenckla Posts: 30
    edited September 6
    John Hudson said:
    Unicode marks are typically distinguished by their position relative to the base letter, so e.g. dot above and dot above right are separately encoded, and one could make a case that the difference in positioning of these Biblical signs should be taken into account in their encoding.
    @John Hudson: I agree this is an important part of making my case. Unfortunately, I can only make the case that at least some of these differences in positioning are needed in all fonts. Some fonts even need all of these differences in positioning. But not all fonts need all of these differences in positioning.

    I think this is strong enough evidence of need, but it would be stronger if I could say that all fonts need all of these differences in positioning.

    BTW my proposal is assuming that we are trying to stick with a mostly semantic model of the Hebrew accents. If instead we are trying to promote a mostly graphical model (I hope not), I think four new code points would be needed. These four would be horizontally centered versions of the following accents:
    1. pashta
    2. segol
    3. telisha qetanah
    4. telisha gedolah

    (I am assuming that we would need to dedicate a code point to centered pashta because although a graphical-from-scratch model of the accents might have qadma and centered pashta share a code point, today's code point for qadma should not be unified with the new notion of centered pashta.)

    No centered version of zarqa/tsinnor would be needed in this mostly graphical dystopia since we already have a mostly graphical model of zarqa/tsinnor and tsinnorit. I.e. today, the terrible names ZARQA and ZINOR should, if annotations are to be trusted and renaming were allowed, be renamed to something like CENTER ZARQA and LEFT ZARQA respectively. If renaming were allowed. Which it isn't. But renaming is a useful "thought experiment."

    No centered version of deḥi would be needed in this mostly graphical dystopia because I know of no examples of its use. If there were evidence of its use, it would seem to be able to share a code point with tipeḥa but should not, for the same reasons centered pashta should not share with qadma.

Categories