<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-compose;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoPlainText>Hi Michael, All,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>>> I assume that we will need to define the context those combining marks are allowed. ... But I guess Sarmad will know for certain.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>This discussion is published by IP in <b>Section 4.5. Non-Spacing Combining Marks</b> of the <a href="https://www.icann.org/en/system/files/files/msr-2-overview-14apr15-en.pdf">Overview and Rationale</a> document released as part of <a href="https://www.icann.org/resources/pages/msr-2015-06-21-en">MSR-2</a>. I encourage you all to review it. It is noted in this section that:<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoNormal style='margin-left:.5in'><i>The actual set of combining marks allowable in the LGR will be smaller than the set included in the MSR, because it will be limited to those marks that are actually required for at least one combining sequence not expressible in NFC. In addition, where the number of such attested sequences is known and limited, GPs are encouraged to enumerate the sequences where feasible, rather than adding the “bare” combining mark to the repertoire. This would serve to prevent such marks from combining with every other allowed code point in the GP’s repertoire.<o:p></o:p></i></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>This suggests that where pre-composed form is not encoded directly, it is preferred to include the combining mark only with the desired code point(s) as a <a href="https://tools.ietf.org/html/rfc7940#section-5.1">sequence</a> to prevent over-generation. <o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Regards,<br>Sarmad<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>-----Original Message-----<br>From: <a href="mailto:latingp-bounces@icann.org">latingp-bounces@icann.org</a> [<a href="mailto:latingp-bounces@icann.org">mailto:latingp-bounces@icann.org</a>] On Behalf Of Michael Bauland<br>Sent: Tuesday, January 17, 2017 1:55 PM<br>To: <a href="mailto:latingp@icann.org">latingp@icann.org</a><br>Subject: Re: [Latingp] How should combining diacritic marks be handled?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Hi Mats, hi all,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>On 16.01.2017 17:21, Mats Dufberg wrote:<o:p></o:p></p><p class=MsoPlainText>> MSR2 contains a number of combining diacritic marks, e.g. U+0323 <o:p></o:p></p><p class=MsoPlainText>> COMBINING DOT BELOW. It might be that we find that some of the <o:p></o:p></p><p class=MsoPlainText>> languages that should be supported requires that code point in <o:p></o:p></p><p class=MsoPlainText>> combination with, say, "n", i.e. "U+006E U+0323". Let us assume that <o:p></o:p></p><p class=MsoPlainText>> there is no pre-composed equivalent code point.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> We can then justify the inclusion of U+0323. Will then the Integration <o:p></o:p></p><p class=MsoPlainText>> Panel accept that code point in any context, or just in the specific <o:p></o:p></p><p class=MsoPlainText>> context?<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>I assume that we will need to define the context those combining marks are allowed. At least we did this for middle dot of the "ela geminada"<o:p></o:p></p><p class=MsoPlainText>in the Catalan language tables (see, e.g., <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__www.iana.org_domains_idn-2Dtables_tables_sap-5Fca-5F1.0.txt&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KTETvEaGPwPcawI-QmNa-kiv-ZBvdgyyLm-mxd028M4&m=dq_XzWWgeHkFr9WfH9IXK7WNh6-cBi-Ri4_TEqaDJkc&s=reu-ntqXFnNrZeDRDBLwSxLIFdJo9q4_2kUN7aPCiP8&e"><span style='color:windowtext;text-decoration:none'>https://urldefense.proofpoint.com/v2/url?u=http-3A__www.iana.org_domains_idn-2Dtables_tables_sap-5Fca-5F1.0.txt&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KTETvEaGPwPcawI-QmNa-kiv-ZBvdgyyLm-mxd028M4&m=dq_XzWWgeHkFr9WfH9IXK7WNh6-cBi-Ri4_TEqaDJkc&s=reu-ntqXFnNrZeDRDBLwSxLIFdJo9q4_2kUN7aPCiP8&e</span></a>= ). But I guess Sarmad will know for certain.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>> If the IP requires that we justify combining diacritic marks for every <o:p></o:p></p><p class=MsoPlainText>> context it will be allowed for, then we have to go language by <o:p></o:p></p><p class=MsoPlainText>> language to find all combinations to support.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> If the IP accepts to include a combining diacritic mark for any <o:p></o:p></p><p class=MsoPlainText>> context as long as it is justified for one language, then we can go <o:p></o:p></p><p class=MsoPlainText>> code point by code point as long as we can find justification for all <o:p></o:p></p><p class=MsoPlainText>> Latin code points in MSR2 and we assume no more code points are needed.<o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> <o:p></o:p></p><p class=MsoPlainText>> If the purpose of our work is to create a Latin IDN table that <o:p></o:p></p><p class=MsoPlainText>> supports all listed languages (EGIDS value 4 or 5 as decided) then I <o:p></o:p></p><p class=MsoPlainText>> cannot see how we can achieve that without inspecting all those languages.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Going by language instead of going by character also has the advantage that we will be able to distribute the languages to members of the group. Then everybody can work with a certain sub-set of all languages.<o:p></o:p></p><p class=MsoPlainText>If we distributed the characters, everybody would have to get acquainted with every single language.<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Cheers,<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>Michael<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText>--<o:p></o:p></p><p class=MsoPlainText>____________________________________________________________________<o:p></o:p></p><p class=MsoPlainText> | |<o:p></o:p></p><p class=MsoPlainText> | knipp | Knipp Medien und Kommunikation GmbH<o:p></o:p></p><p class=MsoPlainText> ------- Technologiepark<o:p></o:p></p><p class=MsoPlainText> Martin-Schmeisser-Weg 9<o:p></o:p></p><p class=MsoPlainText> 44227 Dortmund<o:p></o:p></p><p class=MsoPlainText> Germany<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText> Dipl.-Informatiker Fon: +49 231 9703-284<o:p></o:p></p><p class=MsoPlainText> Fax: +49 231 9703-200<o:p></o:p></p><p class=MsoPlainText> Dr. Michael Bauland SIP: <a href="mailto:Michael.Bauland@knipp.de"><span style='color:windowtext;text-decoration:none'>Michael.Bauland@knipp.de</span></a><o:p></o:p></p><p class=MsoPlainText> Software Development E-mail: <a href="mailto:Michael.Bauland@knipp.de"><span style='color:windowtext;text-decoration:none'>Michael.Bauland@knipp.de</span></a><o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText> Register Court:<o:p></o:p></p><p class=MsoPlainText> Amtsgericht Dortmund, HRB 13728<o:p></o:p></p><p class=MsoPlainText><o:p> </o:p></p><p class=MsoPlainText> Chief Executive Officers:<o:p></o:p></p><p class=MsoPlainText> Dietmar Knipp, Elmar Knipp _______________________________________________<o:p></o:p></p><p class=MsoPlainText>Latingp mailing list<o:p></o:p></p><p class=MsoPlainText><a href="mailto:Latingp@icann.org"><span style='color:windowtext;text-decoration:none'>Latingp@icann.org</span></a><o:p></o:p></p><p class=MsoPlainText><a href="https://mm.icann.org/mailman/listinfo/latingp"><span style='color:windowtext;text-decoration:none'>https://mm.icann.org/mailman/listinfo/latingp</span></a><o:p></o:p></p></div></body></html>