This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Test number-0819 format numbers using Unicode circled digits. However, the expected result starts with 0 (0), not a circled zero (①). There is a similar problem in number-0821.
The number CIRCLED DIGIT ZERO is not consecutively before the CIRCLED DIGIT ONE in the Unicode codepoints. I.e., ZERO is at U+24EA and ONE is at U+2460. However, the Unicode spec makes clear that these are part of a range. I think therefor that the test output is in order if "0" is replaced with U+24EA, but would like to hear the WG consensus of this.
The XSLT 3.0 spec for xsl:number in 12.3 says For example, the formatting token ① (circled digit one) has a range of 1 to 20 imposed by the Unicode character repertoire. But F+O 3.0 for format-integer has correctly updated this to: For example, the format token ① (circled digit one, ①) has a range imposed by the Unicode character repertoire — 1 to 20 in Unicode versions prior to 4.0, increased in subsequent versions. In both cases it's only an example, therefore non-normative, but we should fix the XSLT version of the text, and recognize that Unicode now has a circled zero, which should probably be used in this test.
I have modified the XSLT 3.0 text to match the F+O text as suggested.
Tim Mills wrote: > expected result starts with 0 (0), not a circled zero (①). Michael Kay wrote: > For example, the format token ① (circled digit one, ①) has a range > imposed by the Unicode character repertoire — 1 to 20 in Unicode versions > prior to 4.0, increased in subsequent versions. However, CIRCLED DIGIT ONE is U+2460, ZERO is U+24EA. They are not consecutive. Both have been around since Unicode 1.1. Are we suggesting here that the outcome from a processor should (optionally?) be: <out> 0 ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ 21 22 23 24 25</out> Or: <out> ⓪ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ 21 22 23 24 25</out> Or even: <out> ⓪ ① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ ⑩ ⑪ ⑫ ⑬ ⑭ ⑮ ⑯ ⑰ ⑱ ⑲ ⑳ ㉑ ㉒ ㉓ ㉔ ㉕</out> Numbers up to 50 have been supported since Unicode 3.3. These ranges are not consecutive: 0: 24EA (since 1.1, 1993) 1-20: 2460 - 2473 (since 1.1, 1993) 21-35: 3251 - 325F (since 3.2, 2002) 36-50: 32B1 - 32BF (since 3.2, 2002) So for these Unicode ranges in particular, it is incorrect that only 1 to 20 existed in Unicode prior to 4.0. All these circled digits where added earlier. This means that the sentence in the XSLT 3.0 spec is possibly incomplete: "For example, the formatting token ① (circled digit one) has a range of 1 to 20 imposed by the Unicode character repertoire." I am not sure how to move forward. Since these ranges fall under implementation-defined behavior (and add to that the supported Unicode version is implementation-defined as well), I don't think there's anything we can force here, so I propose that the result of the test should iterate these alternatives.
I've moved forward and implemented a solution, essentially: * added new dependency enum values for numeric formatting * added range dependency to indicate supported ranges * fixed the test by allowing alternate outcomes * fixed the test by adding (new) dependencies In addition, I added a bunch of tests for other No category numbers that have a more or less natural formatting range implied by the Unicode spec.