<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div><blockquote type="cite" class=""><div class="">On Jan 15, 2016, at 8:01 AM, Jonathan Morgan <<a href="mailto:jonmmorgan@gmail.com" class="">jonmmorgan@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="">Hi DM,<br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Jan 15, 2016 at 1:40 AM, DM Smith<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:dmsmith@crosswire.org" target="_blank" class="">dmsmith@crosswire.org</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div style="word-wrap: break-word;" class="">I’ve been trawling through the code. Seems that there is support for Strong’s Numbers that are not padded. If a module contains Strong’s Numbers that are not padded, it is to use StrongsPadding=false. (Actually any value other than “true” will be false. TRUE is false.) This module does not have it.<div class=""><br class=""></div><div class="">Not having StrongsPadding in a conf is the same as StrongsPadding=true. There’s a note in the wiki that says that we’ll probably reverse that in the future. I doubt it. We still have LZSS as the default compression though no module has used it for years (other than experimental modules).<br class=""><div class=""><br class=""></div><div class="">I’m not sure how a Bible with a reference to G0001 will find G1 as it doesn’t unpad the user’s input. But at least the dictionary should work. BTW, there’s a missing "if (strongsPadding)” in rawLD. It is present in zLD. I think this is a bug. Need to verify, report and submit a patch for it. (BTW, I don’t have write permissions either on the main repo, but I’m not discouraged in contributing and submitting patches.)</div></div></div></blockquote><div class=""><br class="">Sorry if I'm missing something, but surely keys without padding wouldn't appear in the correct (numeric) order in the dictionary?<br class=""><br class="">Jon</div></div></div></div></div></blockquote><br class=""></div></div><div>Jon,<div class=""><br class=""></div><div class="">Right. They will be in collation order, not numerical order. It doesn’t work as a SWORD module for that reason and was my primary motivation for moving it to the Experimental repository. The tei2mod program needs to add support for Strong’s numbers as imp2ld has. It doesn’t pad the values as it puts them into the module.</div><div class=""><br class=""></div><div class="">The ordering problem is a more general problem. Our collation order is good for ASCII. It is not good for Latin-1 as the byte value for accented letters is not adjacent to unaccented counterparts.</div><div class=""><br class=""></div><div class="">Each language, script combination has its own collation order. Some languages use multiple glyphs for a single letter. This was noted earlier this month on this mailing list.</div><div class=""><br class=""></div><div class="">In a past job, I had to implement a sort routine that would account for numbers occurring anywhere in a string. What I discovered in the process of doing this was that there is a need for an internal representation that differs from an external representation and routines that would normalize an external representation to an internal representation. Basically that routine would look at a string as an alternating sequence of numbers and non-numbers. The routine external2internal would create a string where numbers were zero padded to 10 digits. (It also did other things like strip noise words from the string, normalize dotted acronyms, normalize casing, …).<br class=""><div><blockquote type="cite" class=""></blockquote></div></div><div class=""><br class=""></div><div class="">Also in an earlier posting this month, I mentioned that ICU has collation routines that are language and script sensitive. The collation values that these produce are good for byte-order sorting, but are not intended for external use.</div><div class=""><br class=""></div><div class="">What we need is a dictionary that stores the case-insensitive keys and that the frontend can collate as it sees fit. That collation order would be used to sort and show the case-insensitive keys. Basically another layer of indirection with a mapping from external presentation to the internal storage of the module.</div><div class=""><br class=""></div><div class="">We’ve talked about this before. I think Troy suggested a mechanism.</div><div class=""><br class=""></div><div class="">I’m going to survey the lexdict modules in all the repos in the Master list (and a few others) to see where we stand with those modules and the StrongsPadding flag. If any key starts with a number and isn’t zero padded, it will have difficulty if StrongsPadding=false is not in the conf. If a module has some that are zero padded and others that are not, this also is a problem.</div><div class=""><br class=""></div><div class="">DM</div><div class=""><br class=""></div></div></body></html>