From: Florian Weimer <fweimer@redhat.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: Carlos O'Donell <carlos@redhat.com>,
Rafal Luzynski <digitalfreak@lingonborough.com>,
Siddhesh Poyarekar <siddhesh@gotplt.org>,
GLIBC Devel <libc-alpha@sourceware.org>
Subject: Re: glibc 2.29 - Winter is coming...
Date: Mon, 07 Jan 2019 19:59:24 +0100 [thread overview]
Message-ID: <87zhsce1kj.fsf@oldenburg2.str.redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1901032054490.20350@digraph.polyomino.org.uk> (Joseph Myers's message of "Thu, 3 Jan 2019 20:58:24 +0000")
* Joseph Myers:
> On Thu, 3 Jan 2019, Carlos O'Donell wrote:
>
>> The new Era name will likely have to be backported to all the active
>> open stable branches so they can display the new Era name.
>
> Presumably that includes the character properties for U+32FF? (Does
> anything in glibc care about the to-be-announced compatibility
> decomposition that's the reason Unicode 12.1 will be needed
> <https://www.unicode.org/L2/L2018/18220-u121planning.txt> or is glibc only
> concerned with character properties that are already known?)
It seems that the CLDR data has a transliteration for the other era
characters. I don't know how relevant this to glibc.
I'm pretty sure we need to adjust the collation data for U+32FF.
For the era data itself, we also need to know the multi-character era
name, so knowing the U+32FF codepoint is of little help (in the sense
that we can ship the changes today and have other projects to supply the
actual glyph shape).
Thanks,
Florian
next prev parent reply other threads:[~2019-01-07 18:59 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-02 10:28 glibc 2.29 - Winter is coming Siddhesh Poyarekar
2019-01-02 10:59 ` Florian Weimer
2019-01-02 11:29 ` Siddhesh Poyarekar
2019-01-02 11:52 ` Rafal Luzynski
2019-01-02 18:24 ` Siddhesh Poyarekar
2019-01-03 0:20 ` Rafal Luzynski
2019-01-03 14:32 ` Carlos O'Donell
2019-01-03 20:58 ` Joseph Myers
2019-01-04 21:25 ` Carlos O'Donell
2019-01-07 18:59 ` Florian Weimer [this message]
2019-01-02 13:11 ` Gabriel F. T. Gomes
2019-01-02 13:16 ` Florian Weimer
2019-01-02 13:47 ` Siddhesh Poyarekar
2019-01-02 16:02 ` Gabriel F. T. Gomes
2019-01-08 13:33 ` Szabolcs Nagy
2019-01-08 14:16 ` Carlos O'Donell
2019-01-08 14:21 ` Szabolcs Nagy
2019-01-08 16:50 ` Carlos O'Donell
2019-01-09 10:50 ` Ramana Radhakrishnan
2019-01-09 16:03 ` Carlos O'Donell
[not found] ` <BL0PR01MB4593D75E9376CC15EE8CA24AF7990@BL0PR01MB4593.prod.exchangelabs.com>
2019-01-23 14:07 ` Carlos O'Donell
2019-01-09 5:48 ` Siddhesh Poyarekar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zhsce1kj.fsf@oldenburg2.str.redhat.com \
--to=fweimer@redhat.com \
--cc=carlos@redhat.com \
--cc=digitalfreak@lingonborough.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=siddhesh@gotplt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).