Re: Display of Isolated Nonspacing Marks (was Re: Questions on ZWNBS...)

From: Peter Kirk (peter.r.kirk@ntlworld.com)
Date: Wed Aug 06 2003 - 17:48:12 EDT

  • Next message: Michael Everson: "Re: Roadmap---Mandaic, Early Aramaic, Samaritan"

    On 06/08/2003 14:03, Doug Ewell wrote:

    >Peter Kirk <peter dot r dot kirk at ntlworld dot com> wrote:
    >
    >
    >
    >>Point taken. But when different fonts and rendering engines give
    >>different results because the standard is unclear or ambiguous, that
    >>is a matter for the discussion here. And when conforming fonts and
    >>rendering engines fail to give the required results, that may also be
    >>because of a deficiency in the standard.
    >>
    >>
    >
    >Or it may not. It may be a deficiency in the level of Unicode support
    >afforded by the fonts and rendering engines. ...
    >
    If there are such deficiencies in fonts and rendering engines which
    purport to be Unicode compliant, that suggests a lack of clarity in the
    standard which should be rectified.

    >... It may simply reflect a
    >difference between your "requirements" and what the standard promises,
    >and doesn't promise.
    >
    If Unicode doesn't promise what I require, surely it is at least
    reasonable for me to ask on this list whether it ought to be extended or
    clarified to do so. The UTC may choose not to make any changes, but I
    don't see why they shouldn't even be asked to.

    >
    >
    >>It seems that many rendering engines give to the sequence space,
    >>combining mark the width normally assigned to a space. Is this
    >>actually what the standard suggests?
    >>
    >>
    >
    >The standard doesn't say anything about width in this case. It leaves
    >it up to the display engine, which is as it should be.
    >
    >
    The standard does say, section 2.10 of 4.0, that "In rendering, the
    combination of a base character and a nonspacing character may have a
    different advance width than the base character itself". And any
    intelligent typographer will realise that this "may" is a "must", with
    regular character designs but not of course in monospace, in some cases
    like the example given of i with circumflex. This sentence applies to
    spaces with diacritics as space is a base character, as we have been
    informed. The subsection of 2.10 entitled "Spacing Clones of European
    Diacritical Marks" (by the way, why "European" when the text appears to
    apply to all diacritical marks?) should suggest to any intelligent
    typographer that the sequence space, diacritic is intended to be spaced
    as the diacritic and not as a space, but it would help for this to be
    clarified as not all typographers are very intelligent and some may not
    be aware that this space has actually lost most of the properties of a
    space e.g. line breaking and is being used only "By convention".

    >
    >
    >>I have identified a need to display combining marks with no extra
    >>width, only the width required by the mark. Should the sequence space,
    >>combining mark do what I want, or shouldn't it? If so, this needs to
    >>be spelled out so that rendering engines know what they are supposed
    >>to do. If not, there may be a need for a new character. This is a
    >>deficiency in the standard, not in the rendering engines.
    >>
    >>
    >
    >When the specific alignment of isolated glyphs is important to me, I use
    >markup. I'm a big supporter of plain text, as many members of this list
    >know, but the exact spacing of isolated combining marks seems like a
    >layout issue to me.
    >
    >
    OK, what kind of markup should I use, in any well-known markup language,
    to ensure that an isolated diacritic is centred in the space between the
    words before and after it?

    >-Doug Ewell
    > Fullerton, California
    > http://users.adelphia.net/~dewell/
    >
    >
    >
    >
    >

    -- 
    Peter Kirk
    peter@qaya.org (personal)
    peterkirk@qaya.org (work)
    http://www.qaya.org/
    


    This archive was generated by hypermail 2.1.5 : Wed Aug 06 2003 - 18:37:36 EDT