Figure 1 needs a colour key

[r12a]

2.2.3 Unicode Normalization Forms
https://w3c.github.io/charmod-norm/#normalization_forms

We should explain what the yellow, green and red colours mean (preferably in a list alongside the table rather than in flowing prose paragraphs).

[r12a]

Note, btw, that there's also a misleading traffic light connotation to the colours used.

[asmusf]

The figure lacks discussion of the fact that some of the "original" code points are normalized while others are not. There's also not an example of canonical re-odering.

[aphillips]

I fixed the "stop light" but haven't added a key yet.

[r12a]

The WAI folks are always reminding me that i don't have enough contrast in stuff i make, but even i can't easily read the text on the darker backgrounds here ;-) Suggest we invert the colour for the text or choose some other colour. (I'll admit that even the green stuff is not that easy to read. And wait, are there actually two light green colours used? Seems like NFD and NFKD columns are slightly different.) It's a pain, i know, but we'll probably have to fix this anyway before publication.

[aphillips]

I made more contrasty color choices ("mmm! pastels!"). There is only one green color and one blue color: those characters use the same sequence as each other, which is what the color is supposed to illustrate visually.

@asmusf No, the example doesn't illustrate canonical reordering. Nor does it discuss pre-normalized vs. non-normalized inputs. We do have text about some of these topics. UAX15, by my count, has at least 7 illustrations and tables about this topic. Shouldn't Mark and Ken have to do at least some of the heavy lifting here? :-)

The U+01FA example was carefully chosen to have a compatibility equivalent and a canonical mapping (actually, two of them) as well as a precomposed code point. Is there a better general illustration?

[asmusf]

On 10/25/2017 8:17 PM, Addison Phillips wrote: I made more contrasty color choices ("mmm! pastels!"). There is only one green color and one blue color: those characters use the same sequence as each other, which is what the color is supposed to illustrate visually. @asmusf <https://github.com/asmusf> No, the example doesn't illustrate canonical reordering. Nor does it discuss pre-normalized vs. non-normalized inputs. We do have text about some of these topics. UAX15, by my count, has at least 7 illustrations and tables about this topic. Shouldn't Mark and Ken have to do at least some of the heavy lifting here? :-) The U+01FA example was carefully chosen to have a compatibility equivalent and a canonical mapping (actually, two of them) as well as a precomposed code point. Is there a better general illustration? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#126 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ANbTHlGjaSvvJf8EuCTP84Z5FPYHAN-Vks5sv_nGgaJpZM4P-C__>.

It's easy to get side tracked by some cases that exhibit all features and therefore look neat. I admit I only looked at it from the figure and didn't re-read everything in context, but I keep running into people having real issues with not getting the canonical reordering (or the fact that NFC starts with NFD and only re-composes after reordering.) This leads to claims that there are normalization exceptions when all those are are unnormalized partially precomposed sequences that would not work if NFC tried to compose them directly, but do work if they are first decomposed (as is the case). So I would step back from all the colors and ask what do we really need to get across. And second, is putting everything into a single table the best didactic tool? Having that much of an issue with colors tells you that there may be an issue. Finally, I have come across people who can't read a sequence when it line-wraps inside a table cell; they read each line as alternative representations for the same thing. Breaking apart that humongous table would allow wider columns.

[r12a]

Can we increase the size of the examples – there's plenty of room for that, and the characters are very difficult to see on my screen.

[aphillips]

I made the letters big using the same style as elsewhere and made the table more illustrative of the point the original was trying to make by joining cells and using borders. Text adjustment was needed. Thoughts?

[r12a]

Other than that you may want to increase the line-height to stop the diacritics bumping into the line above, LGTM.

[asmusf]

I take it, "table 1" has morphed in to "example 12". In that case, two comments apply.

1. I'm at a loss to see the 3 sequences mentioned in this sentence: "Note that there are only three distinct code points sequences" (there also seems an extra 's' in "points").
2. we still have sequences breaking across lines. I keep running into people who cannot understand that they need to read successive lines as part of the same sequence.

Perhaps the same fix can address both comments:

"Note that on each line there are only three distinct code point sequences, such as U+00C5 U+0301, U+01FA, U+0041 U+030A U+0301 on the second line."

This would also fix the extraneous "s" in "code point sequence" -- (and clarifying that a single code point is also a sequence; otherwise you'd have to write "code points or sequences."

However, when you write "code points or sequences" then you have the problem that the sequences also contain code points, so giving the example "U+00C5 U+0301, U+01FA, U+0041 U+030A U+0301" is still helpful.

Other than that, things look a lot nicer in this version.

[aphillips]

Changed "code points sequences" to "code point sequences" (removed extra 's')
Added more explanatory text to ensure that the sequences will be recognized as sequences--as @asmusf suggests, I list the code point sequences.
Added a link to the orginal example (currently example 10).

[r12a]

I'm happy to close this issue now.