When I'm looking at
https://unicode.org/Public/emoji/11.0/emoji-sequences.txt
It goes on line 16 that:
--
# type_field: any of {Emoji_Combining_Sequence, Emoji_Flag_Sequence,
Emoji_Modifier_Sequence}
# The type_field is a convenience for parsing the emoji sequence
files, and is not
On Fri, 8 Jun 2018 20:45:26 +0200
Philippe Verdy via Unicode wrote:
> 2018-06-08 19:41 GMT+02:00 Richard Wordingham via Unicode <
> unicode@unicode.org>:
> The way tailoring is designed in CLDR using only data used by a
> generic algorithm, and not custom algorithm is not the only way to
>
On Fri, 8 Jun 2018 14:14:51 -0700
"Steven R. Loomis via Unicode" wrote:
> > But the consortium has formally dropped the commitment to DUCET in
> > CLDR. Even when restricted to strings of assigned characters, the
> > CLDR and ICU no longer make the effort to support the DUCET
> > collation.
>
On 6/8/2018 2:28 PM, Marcel Schneider
via Unicode wrote:
On Fri, 8 Jun 2018 13:33:20 -0700, Asmus Freytag via Unicode wrote:
[…]
There's no value added in creating "mirrors" of something that is successfully being
On Fri, 8 Jun 2018 16:54:20 -0400, Tom Gewecke via Unicode wrote:
>
> > On Jun 8, 2018, at 9:52 AM, Marcel Schneider via Unicode wrote:
> >
> > People relevant to projects for French locale do trace the borderline of
> > applicability wider
> > than do those people who are closerly tied to
On Fri, 8 Jun 2018 13:33:20 -0700, Asmus Freytag via Unicode wrote:
>
[…]
> There's no value added in creating "mirrors" of something that is
> successfully being developed and maintained under a different umbrella.
Wouldn’t the same be true for ISO/IEC 10646? It has no value added neither, and
Richard,
> But the consortium has formally dropped the commitment to DUCET in CLDR.
> Even when restricted to strings of assigned characters, the
> CLDR and ICU no longer make the effort to support the DUCET
> collation.
CLDR is not a collation implementation, it is a data repository with
> On Jun 8, 2018, at 9:52 AM, Marcel Schneider via Unicode
> wrote:
>
> People relevant to projects for French locale do trace the borderline of
> applicability wider
> than do those people who are closerly tied to Unicode‐related projects.
Could you give a concrete example or two of what
On 6/8/2018 5:01 AM, Michael Everson
via Unicode wrote:
and achieving a fullscale merger with ISO/IEC 15897, after which the valid data stay hosted entirely in CLDR, and ISO/IEC 15897 would be its ISO mirror.
I wonder if Mark Davis will be
2018-06-08 19:41 GMT+02:00 Richard Wordingham via Unicode <
unicode@unicode.org>:
> On Fri, 8 Jun 2018 13:40:21 +0200
> Mark Davis ☕️ wrote:
>
> > Mark
> >
> > On Fri, Jun 8, 2018 at 10:06 AM, Richard Wordingham via Unicode <
> > unicode@unicode.org> wrote:
> >
> > > On Fri, 8 Jun 2018 05:32:51
On Fri, 8 Jun 2018 13:40:21 +0200
Mark Davis ☕️ wrote:
> Mark
>
> On Fri, Jun 8, 2018 at 10:06 AM, Richard Wordingham via Unicode <
> unicode@unicode.org> wrote:
>
> > On Fri, 8 Jun 2018 05:32:51 +0200 (CEST)
> > Marcel Schneider via Unicode wrote:
> >
> > > Thank you for confirming. All
Marcel,
On Fri, Jun 8, 2018 at 6:52 AM, Marcel Schneider via Unicode <
unicode@unicode.org> wrote:
>
> What got me started is that before even I requested a submitter ID (and
> the reason why I’ve requested one),
> "Characters | Category | Label | keycap" remained untranslated, i.e. its
> French
On Fri, 8 Jun 2018 08:50:28 -0400, Tom Gewecke via Unicode wrote:
>
>
> > On Jun 7, 2018, at 11:32 PM, Marcel Schneider via Unicode wrote:
> >
> > What bothered me ... is that the registration of the French locale in CLDR
> > is
> > still surprisingly incomplete
>
> Could you provide an
On Fri, 8 Jun 2018 13:06:18 +0200, Mark Davis ☕️ via Unicode wrote:
>
> Where are you getting your "facts"? Among many unsubstantiated or ambiguous
> claims in that very long sentence:
>
> > "French locale in CLDR is still surprisingly incomplete".
>
> For each release, the data collected for
> On Jun 7, 2018, at 11:32 PM, Marcel Schneider via Unicode
> wrote:
>
> What bothered me ... is that the registration of the French locale in CLDR is
> still surprisingly incomplete
Could you provide an example or two?
> On 8 Jun 2018, at 11:07, Henri Sivonen via Unicode
> wrote:
>
> My question is:
>
> When designing a syntax where tokens with the user-chosen characters
> can't occur next to each other without some syntax-reserved characters
> between them, what advantages are there from limiting the
On 8 June 2018 at 13:01, Michael Everson via Unicode
wrote:
>
> I wonder if Mark Davis will be quick to agree with me when I say that
> ISO/IEC 15897 has no use and should be withdrawn.
It was reviewed and confirmed in 2017, so the next systematic review
won't be until 2022. And as the
On 8 Jun 2018, at 04:32, Marcel Schneider via Unicode
wrote:
> the registration of the French locale in CLDR is still surprisingly
> incomplete despite the meritorious efforts made by the actual contributors
Nothing prevents people from working to complete the French locale in CLDR.
On 7 Jun 2018, at 20:13, Marcel Schneider via Unicode
wrote:
> On Fri, 18 May 2018 00:29:36 +0100, Michael Everson via Unicode responded:
>>
>> It would be great if mutual synchronization were considered to be of benefit.
>> Some of us in SC2 are not happy that the Unicode Consortium has
Mark
On Fri, Jun 8, 2018 at 10:06 AM, Richard Wordingham via Unicode <
unicode@unicode.org> wrote:
> On Fri, 8 Jun 2018 05:32:51 +0200 (CEST)
> Marcel Schneider via Unicode wrote:
>
> > Thank you for confirming. All witnesses concur to invalidate the
> > statement about uniqueness of ISO/IEC
Where are you getting your "facts"? Among many unsubstantiated or ambiguous
claims in that very long sentence:
1. "French locale in CLDR is still surprisingly incomplete".
1. For each release, the data collected for the French locale is
complete to the bar we have set for
On Wed, Jun 6, 2018 at 2:55 PM, Henri Sivonen wrote:
> Considering that ruling out too much can be a problem later, but just
> treating anything above ASCII as opaque hasn't caused trouble (that I
> know of) for HTML other than compatibility issues with XML's stricter
> stance, why should a
On Fri, 8 Jun 2018 05:32:51 +0200 (CEST)
Marcel Schneider via Unicode wrote:
> Thank you for confirming. All witnesses concur to invalidate the
> statement about uniqueness of ISO/IEC 10646 ‐ Unicode synchrony. —
> After being invented in its actual form, sorting was standardized
>
23 matches
Mail list logo
