Re: Run-time checking of fonts for Sinhala support

From: Harshula (harshula@gmail.com)
Date: Thu Sep 03 2009 - 09:44:01 CDT

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

    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. :-)

    > But are you familiar enough with
    > font technology, and the way operating systems and rendering engines
    > support font technology, to understand the burden this sort of checking
    > imposes at runtime EVERY TIME text is to be displayed?

    Thanks for your question.

    Every time text is displayed, it should incur the cost of a simple
    lookup in an in-memory data structure or at worst opening and reading a
    font metadata file from the buffer cache.

    The layer that manages the fonts needs to be notified (using a
    technology like inotify) when a font file changes and when the mtime of
    a directory containing fonts changes. The font management layer can then
    handle the cases where a font file has been added, deleted or changed.
    In the case of a font file being added/changed, it can trigger parsing
    of the font file, which could be computationally intensive, to
    generate/update a metadata file.

    I do not see any need to do computationally intensive parsing of fonts
    every time text is displayed in-order to choose a compliant font.

    Does that sound plausible?

    cya,
    #



    This archive was generated by hypermail 2.1.5 : Thu Sep 03 2009 - 09:46:25 CDT