Re: Slots for Cyrillic Accented Vowels

From: Philippe Verdy (
Date: Wed May 18 2011 - 13:26:55 CDT

  • Next message: Plamen Tanovski: "Re: Slots for Cyrillic Accented Vowels"

    Yes, but of course this does not mean that we don't need more support
    in fonts. What this actually means is that font development should not
    depend only on a few specialists, using costly softwares and extreme
    knowledge as in the current situation when working with OpenType.
    There's certainly a need for better tools, that are really open, and
    less quirky to install on more platforms than just Linux (for free
    But what is also missing is a way for users to correctly evaluate the
    quality of fonts, and clean up their installations, and more easily
    upgrade them or complement them, possibly by using composite fonts
    (because almost all fonts have deficiencies and cannot be altered in a
    interoperable way across systems, without infringing some property
    The current font technologies remain a huge interoperability problem.
    And I hope that some day, the OpenType specifification will be cleaned
    up to mark the features that are no longer recommended, and those that
    all new fonts should implement for macimu interoperability.
    But I also hope that the OpenType technology will cover the domain of
    composite fonts, allowing existing fonts to be used in an unmodified
    way (without infringing rights) along with user-provided or
    service-provided complementary data to fill the gaps). If it's not
    possible, may be reinvent a new font development model that will be
    really portable.

    For now most fonts only concentrate on encoding their glyphs and
    mapping them to a single character, but anything else (even if
    excluding advanced typographic features such as kerning pairs and
    hinting) requires too much knowledge and tuning work. Working on the
    various font metrics and glyph metrics is still extremely tricky to
    get consistant results, and all font developers still need to use a
    lot of personal scripts to check the consistency of their work.

    In fact, some alternate non-OpenType font formats that are easier to
    work on already exist, but they are still proprietary to specific font
    development tools, for easier editing, before converting them to
    existing legacy font formats (which are supposed to be more compact,
    but still costly and inefficient to decode in software, when a basic
    general purpose compression scheme like .tar.gz or .zip, containing
    the various tables as XML and tyiny SVG files in an open archive
    format similar to today's MSOffice and OpenOffice documents, would
    simplify a lot the development and complementation of existing fonts,
    based on wellknown and stable standards.

    Is there a subproject, in OpenOffice for example, to develop such font
    format, most probably XML-based, and then standardize it using common
    interoperable schemas, with a separate development of conversion tools
    that will automatically generate the legacy OpenType and PostScript
    formats tuned for various specific systems, instead of continuing to
    add new quirky binary storages that are very difficult to extend
    without adding new tables with contradictory contents between each
    other ? Note that these conversion tools could as well be built
    directly within system-specific renderers as part of their font
    installation and caching tools and UI.

    -- Philippe.

    2011/5/18 Doug Ewell <>:
    > A somewhat shorter explanation:
    > The comparison with existing Latin precomposed characters is not
    > relevant. Almost all of those were added for compatibility with
    > existing standards, as Philippe said.
    > Text editing and processing with combining marks is not "very difficult
    > and erroneous." The one use case that Plamen mentioned (a user manually
    > deleting a base letter) is easily trained. Unicode has been around with
    > this architecture for 20 years now.
    > There are plenty of fonts that support Cyrillic base letters with
    > combining marks. There are plenty that don't, especially older fonts,
    > but on no account is it 99%.
    > There is no great urgency to break stability and introduce duplicate
    > encodings for Cyrillic text. All Cyrillic text can be represented using
    > the existing architecture.
    > --
    > Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
    > | | @DougEwell

    This archive was generated by hypermail 2.1.5 : Wed May 18 2011 - 13:29:31 CDT