Re: The Ruble sign has been approved

From: Philippe Verdy <verdy_p_at_wanadoo.fr>
Date: Thu, 12 Dec 2013 01:37:36 +0100

2013/12/12 Leo Broukhis <leob_at_mailcom.com>

> Joking aside, the ruble sign is intended as a character adaptable to
> Western-style typefaces (roman/italic, serif/sanserif, etc), and U+0554
> doesn't easily lend itself to that.
>

Given that the standard is widely adaptable, just means that U+0554 is
*also* usable in western styles, without being restricted to the Cyrillic
script, even if the character is encoded in a Cyrcillic block.

This just means a change in a non-normative property, not a reencoding. A
Ruble will remain a Ruble in all scripts, just like the Euro symbol, or the
Bath symbol.

Of course this does not preclude the possible future need of glyph
distinctions using variation selectors, where it would make sense, but for
now, all usages are linked to the same currency within all its glyphic
variations, even if the default glyph shown in UTC charts uses the
normalized form. Then each font designed for some style in a given script
will adapt their glyph mapped by default for its own need, including
adaptation of relative metrics while the normative glyph design is not
really changed.

One thing we could think about: some currencies have a normative glyph
design, some others not. The normative form should have an encoding with
its 1st variation selector, when the font would be free to adapt the
default glyph (used without the variation selector) more freely according
to its general design.

So U+20AC,VS1 would be an Euro with its normative glyph design, but U+20AC
alone would continue to be adaptable.

Same thing for U+0554 with the generic Ruble (but U+0554,VS1 would be the
current Russian Ruble glyph only, excluding other Rubles used elsewhere or
in other periods of history). Same thing for the Bath, the Won (may be two
possible designs between North and South Korea), the Yuan, the Yen
(depending on evolutions of the JIS standards), or even the Dollar (or
historic Peso or Thaller), that we will not reencode.
Received on Wed Dec 11 2013 - 18:39:32 CST

This archive was generated by hypermail 2.2.0 : Wed Dec 11 2013 - 18:39:32 CST