<div dir="auto">Why would the front end or engine need to know this information? Would it help the front end developers or users to know it? What do we gain by adding this? (I'm not implying it wouldn't be beneficial. But the only thing I know about Unicode is how the different UTF encodings work, so I have no idea what use this information could be. I also think changes to formats and information standards should be conservative instead of liberal)<div dir="auto"><br></div><div dir="auto">--Greg</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Jan 6, 2018 11:01, "David Haslam" <<a href="mailto:dfhdfh@protonmail.com">dfhdfh@protonmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Dear all,<br></div><div><br></div><div>We've known for quite a few years that there are aspects of <b>Biblical Hebrew</b> that mean we should <u>avoid</u> converting the Unicode source text to <b>NFC</b> when we build a module.<br></div><div><br></div><div>This prompts me to suggest that we ought to define a new <b>key</b> for .conf files.<br></div><div><br></div><div><b>Normalization=NFC</b> (this would be the default, and may be <u>omitted</u> for the vast majority of modules)<br></div><div><b>Normalization=Custom</b> (we should include this in certain Biblical Hebrew modules)<br></div><div><br></div><div>This would make it clear to front-end developers and users alike that the source text was <u>not</u> converted to NFC during module build.<br></div><div>i.e. <b>osis2mod</b> was used intentionally with the <b>-N</b> switch, in <u>accordance with the requirements of the source text provider</u>.<br></div><div><br></div><div>The Unicode source text may already be encoded in <b>UTF-8</b> ; this memo is <i>only </i>about normalization.</div><div><br></div><div>In the rare eventuality that there could arise a requrement for any of the other three normalization forms (<b>NFD</b>, <b>NFKC</b>, <b>NFKD</b>) defined by the Unicode Consortium,<br></div><div>these would also be permitted values for the conf file key.<br></div><div><br></div><div>A further benefit arises when a module needs to be updated.<br></div><div>If the modules team sees that the .conf file includes the line<br></div><div><b>Normalization=Custom</b><br></div><div>they would be forewarned against converting to NFC through <i>inadvertently</i> omitting the <b>-N</b> switch during module build.</div><div><br></div><div><u>Aside</u>: Another language with a need for non-standard normalization is <b>Tibetan</b>. We don't yet have a module in that script.<br></div><div><div><div><br></div></div></div><div class="m_5107515245992691636protonmail_signature_block"><div class="m_5107515245992691636protonmail_signature_block-user"><div>Best regards,<br></div><div><br></div><div>David<br></div></div><div><br></div><div class="m_5107515245992691636protonmail_signature_block-proton">Sent with <a href="https://protonmail.com" target="_blank">ProtonMail</a> Secure Email.<br></div></div><div><br></div><br>______________________________<wbr>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" rel="noreferrer" target="_blank">http://www.crosswire.org/<wbr>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br></blockquote></div></div>