Re: Run-time checking of fonts for Sinhala support

From: Asmus Freytag (asmusf@ix.netcom.com)
Date: Thu Sep 03 2009 - 15:34:30 CDT

  • Next message: Shriramana Sharma: "Re: Why are the double-part Indic vowel signs decomposable"

    On 9/3/2009 7:44 AM, Harshula wrote:
    > Hi Doug,
    >
    > On Thu, 2009-09-03 at 07:30 -0600, Doug Ewell wrote:
    >
    >> "Harshula" <harshula at gmail dot com> wrote:
    >>
    >>
    >>> It is pointless having a Level 1 compliant Sinhala font sitting
    >>> *unused* on the filesystem, whilst the operating system choses a
    >>> random non-compliant font that will present an incorrect and
    >>> non-standard UI to the user. Therefore, the operating system needs to
    >>> select a Level 1 compliant font by default to ensure a correct and
    >>> standardised UI.
    >>>
    >> I agree in principle that it is pointless to use a less-capable font
    >> when a more-capable font is available.
    >>
    >
    > Glad we agree on that. :-)
    >
    Precisely, because it is pointless, requiring automatic validation is
    pointless as well. Besides being expensive, and, like all technology,
    subject to bugs and or unexpected side effects.

    I've observed this exchange for a while. What I find so interesting
    about it, is your unspoken assumption that Sinhala needs a verification
    feature that no users of other script / language found necessary at all.
    Yet they are all equally interested in getting the highest capabilities
    to get their scripts / languages rendered.

    What worked for them is simply the availability of high-quality fonts,
    driven by operating systems packaged with them. In a few cases,
    requirements exist for the *availability* of a certain level of font
    (for example, a font guaranteeing some coverage or in a preferred style).

    After that, the fact that users will select these fonts and will want to
    see them selected is enough of a driving force to bring about the
    results you are after in short order.

    Your proposed technological fix does little to speed up that process -
    forcing people to re-engineer performance critical technology for a
    minuscule market may well have the opposite effect of delaying software
    that formally certifies.

    After an initial adjustment period, the whole issue will become moot.
    The software fixes would remain, and, depending on how they are
    implemented, could even interfere with users font choice later in
    unexpected ways (remember the law of unexpected consequences).

    For all of these reasons, the appropriate choice for standardization is
    to not make such a requirement. By all experience, this will lead to
    superior user experience over the long term.

    A./



    This archive was generated by hypermail 2.1.5 : Thu Sep 03 2009 - 15:38:01 CDT