| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Resolves: BZ # 31411
References:
https://iso639-3.sil.org/code/ltg
https://en.wikipedia.org/wiki/Latgalian_language
https://github.com/unicode-org/cldr/blob/main/common/main/ltg.xml
|
|
Resolves: BZ # 25119
Also to sync with CLDR
|
|
Signed-off-by: David Paleino <dapal@debian.org>
|
|
Resolves: BZ # 21271
|
|
[BZ #31370]
= `Default_Ignorable_Code_Point`s should have width 0 =
Unicode specifies (https://www.unicode.org/faq/unsup_char.html#3) that characters
with the `Default_Ignorable_Code_Point` property
> should be rendered as completely invisible (and non advancing, i.e. “zero width”),
if not explicitly supported in rendering.
Hence, `wcwidth()` should give them all a width of 0, with two exceptions:
- the soft hyphen (U+00AD SOFT HYPHEN) is assigned width 1 by longstanding precedent
- U+115F HANGUL CHOSEONG FILLER needs a carveout
due to the unique behavior of the conjoining Korean jamo characters.
One composed Hangul "syllable block" like 퓛
is made up of two to three individual component characters, or "jamo".
These are all assigned an `East_Asian_Width` of `Wide`
by Unicode, which would normally mean they would all be assigned
width 2 by glibc; a combination of (leading choseong jamo) +
(medial jungseong jamo) + (trailing jongseong jamo) would then have width 2 + 2 + 2 = 6.
However, glibc (and other wcwidth implementations) special-cases jungseong and jongseong,
assigning them all width 0,
to ensure that the complete block has width 2 + 0 + 0 = 2 as it should.
U+115F is meant for use in syllable blocks
that are intentionally missing a leading jamo;
it must be assigned a width of 2 even though it has no visible display
to ensure that the complete block has width 2.
However, `wcwidth()` currently (before this patch)
incorrectly assigns non-zero width to
U+3164 HANGUL FILLER and U+FFA0 HALFWIDTH HANGUL FILLER;
this commit fixes that.
Unicode spec references:
- Hangul: §3.12 https://www.unicode.org/versions/Unicode15.0.0/ch03.pdf#G24646 and
§18.6 https://www.unicode.org/versions/Unicode15.0.0/ch18.pdf#G31028
- `Default_Ignorable_Code_Point`: §5.21 https://www.unicode.org/versions/Unicode15.0.0/ch05.pdf#G40095.
= Non-`Default_Ignorable_Code_Point` format controls should be visible =
The Unicode Standard, §5.21 - Characters Ignored for Display
(https://www.unicode.org/versions/Unicode15.0.0/ch05.pdf#G40095)
says the following:
> A small number of format characters (General_Category = Cf )
> are also not given the Default_Ignorable_Code_Point property.
> This may surprise implementers, who often assume
> that all format characters are generally ignored in fallback display.
> The exact list of these exceptional format characters
> can be found in the Unicode Character Database.
> There are, however, three important sets of such format characters to note:
>
> - prepended concatenation marks
> - interlinear annotation characters
> - Egyptian hieroglyph format controls
>
> The prepended concatenation marks always have a visible display.
> See “Prepended Concatenation Marks” in [*Section 23.2, Layout Controls*](https://www.unicode.org/versions/Unicode15.1.0/ch23.pdf#M9.35858.HeadingBreak.132.Layout.Controls)
> for more discussion of the use and display of these signs.
>
> The other two notable sets of format characters that exceptionally are not ignored
> in fallback display consist of the interlinear annotation characters,
> U+FFF9 INTERLINEAR ANNOTATION ANCHOR through
> U+FFFB INTERLINEAR ANNOTATION TERMINATOR,
> and the Egyptian hieroglyph format controls,
> U+13430 EGYPTIAN HIEROGLYPH VERTICAL JOINER through
> U+1343F EGYPTIAN HIEROGLYPH END WALLED ENCLOSURE.
> These characters should have a visible glyph display for fallback rendering,
> because if they are not displayed,
> it is too easy to misread the resulting displayed text.
> See “Annotation Characters” in [*Section 23.8, Specials*](https://www.unicode.org/versions/Unicode15.1.0/ch23.pdf#M9.21335.Heading.133.Specials),
> as well as [*Section 11.4, Egyptian Hieroglyphs*](https://www.unicode.org/versions/Unicode15.1.0/ch11.pdf#M9.73291.Heading.1418.Egyptian.Hieroglyphs)
> for more discussion of the use and display of these characters.
glibc currently correctly assigns non-zero width to the prepended concatenation marks,
but it incorrectly gives zero width to the interlinear annotation characters
(which a generic terminal cannot interpret)
and the Egyptian hieroglyph format controls
(which are not widely supported in rendering implementations at present).
This commit fixes both these issues as well.
= Derive Hangul syllable type from Unicode data =
Previosuly, the jungseong and jongseong jamo ranges
were hard-coded into the script. With this commit, they are instead parsed
from the HangulSyllableType.txt data file published by Unicode.
This does not affect the end result.
Signed-off-by: Jules Bertholet <julesbertholet@quoi.xyz>
|
|
From Кирилл Изместьев <izmestevks@basealt.ru>,
see: https://sourceware.org/bugzilla/show_bug.cgi?id=31530#c6
and the following comments.
|
|
Resolves: BZ # 31530
|
|
Delay setting file->decided until the data has been successfully loaded
by _nl_load_locale(). If the function fails to load the data then we
must return and error and leave decided untouched to allow the caller to
attempt to load the data again at a later time. We should not set
decided to 1 early in the function since doing so may prevent attempting
to load it again. We want to try loading it again because that allows an
open to fail and set errno correctly.
On the other side of this problem is that if we are called again with
the same inputs we will fetch the cached version of the object and carry
out no open syscalls and that fails to set errno so we must set errno to
ENOENT in that case. There is a second code path that has to be handled
where the name of the locale matches but the codeset doesn't match.
These changes ensure that errno is correctly set on failure in all the
return paths in _nl_find_locale().
Adds tst-locale-loadlocale to cover the bug.
No regressions on x86_64.
Co-authored-by: Jeff Law <law@redhat.com>
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
|
|
In 2018 the license changed to use Unicode-3.0 license.
The Unicode License is a permissive MIT type of license.
Automation is updated to fetch the correct license file to
keep it in sync with the data files.
The new license is OSI approved and has an SPDX identifer:
https://opensource.org/license/unicode-license-v3
https://spdx.org/licenses/Unicode-3.0.html
The FSF and the GNU Project have been contacted to update
the license list for this license:
https://www.gnu.org/licenses/license-list.html
|
|
|
|
Resolves: BZ # 29845
|
|
Resolves: https://sourceware.org/bugzilla/show_bug.cgi?id=23774
See this change in CLDR committed on 2024-01-29:
https://github.com/unicode-org/cldr/commit/635e2d3d0566563e12c8ea58c219d35183fcec12
|
|
Resolves: BZ # 31205
Adapt test cases in test-grouping_iterator.c
|
|
Resolves: BZ # 19956
|
|
used in Russia.
Resolves: BZ # 24386
|
|
Resolves: BZ # 31257
|
|
Resolves: BZ # 23172
|
|
Resolves: BZ # 19479
|
|
Resolves: BZ # 31239
The correct abbreviated month names were apparently given in the comment above `abmon`.
But the value of `abmon` was apparently just copied from the value of `mon` and this
mistake was hard to see because code point notation <Uxxxx> was used. After converting
to UTF-8 it was obvious that there was apparently a copy and paste mistake.
|
|
Resolves: BZ # 29506
|
|
|
|
|
|
tl_PH: convert to UTF-8
|
|
Resolves: BZ # 24006
|
|
|
|
Resolves: BZ # 30605
|
|
Sort Makefile variables using scrips/sort-makefile-lines.py.
No regressions on x86_64.
|
|
|
|
Resolves: BZ # 27312
|
|
Resolves: BZ # 12908
https://iso639-3.sil.org/code/zgh
|
|
|
|
See: https://sourceware.org/bugzilla/show_bug.cgi?id=31221#c2
|
|
|
|
Resolves: BZ # 31221
glibc can recognise its code, but does not have its data.
This patch remedies that.
Signed-off-by: Janet Blackquill <uhhadd@gmail.com>
|
|
|
|
Resolves: BZ # 31086
|
|
Resolves: BZ # 31086
|
|
Resolves: BZ # 31086
|
|
Resolves: BZ # 31086
|
|
|
|
|
|
|
|
|
|
|
|
code "fy"
Resolves: BZ # 14522
|
|
|
|
|
|
Resolves: BZ # 27601
|
|
|
|
|
