Strong's numbers are padded by 0, which is why they currently sort properly.
Such a sort order sounds a good idea (though perhaps not for the developers
;).
Modules produced in such a way wouldn't be compatible with Sword <= 1.5.11,
though.
I still suspect that sorting isn't quite as easy as spec
On Wed, Sep 17, 2008 at 10:38 PM, Daniel Owens <[EMAIL PROTECTED]> wrote:
>
>
> Greg Hellings wrote:
>
> On Wed, Sep 17, 2008 at 9:56 PM, Daniel Owens <[EMAIL PROTECTED]> wrote:
>
>
> Ben,
>
> Thanks for the explanation. It seems to me that setting up dictionaries to
> use key retrieval from an unc
Greg Hellings wrote:
On Wed, Sep 17, 2008 at 9:56 PM, Daniel Owens <[EMAIL PROTECTED]> wrote:
Ben,
Thanks for the explanation. It seems to me that setting up dictionaries to
use key retrieval from an uncompressed file with one key per line (ordered
as the module creator orders i
On Wed, Sep 17, 2008 at 9:56 PM, Daniel Owens <[EMAIL PROTECTED]> wrote:
> Ben,
>
> Thanks for the explanation. It seems to me that setting up dictionaries to
> use key retrieval from an uncompressed file with one key per line (ordered
> as the module creator orders it) makes the most sense to me.
Ben,
Thanks for the explanation. It seems to me that setting up dictionaries
to use key retrieval from an uncompressed file with one key per line
(ordered as the module creator orders it) makes the most sense to me.
If that helps increase efficiency and preserves the order of dictionary
entri
RST's directory contains both chapter and book compression (.conf says
it's using book), and it includes the entire content of FinPR92 in a
subdirectory.
___
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sw
Hi Daniel,
Code points are not the only way to sort it.
However, there does need to be a comparison function defined, which will
compare two words and give which is bigger.
This needs to be used consistently, from module creation to frontend. There
could be a library of defined comparators provide
Is code point
order the ONLY way to sort dictionary entries? Surely there is a solution
which would retain the printed or intended order of dictionary entries
without giving up lots of efficiency. If not, I think users would find
a correctly ordered but slower dictionary to one which is fast bu
The issue with ordering as I understand it is that if it is in (some form
of) sorted order, you can use binary search to find entries.
If you want order retained, it is best to use a genbook - but it won't be as
efficient, and may not have as good UI support.
With huge english dictionaries (like We
Sorry, mea culpa. svn update and try again.
-Troy.
Peter von Kaehne wrote:
> Trying to build sword and get an error
>
> creating vs2osisref
> make[2]: *** No rule to make target `vs2osisreftxt.o', needed by
> `vs2osisreftxt'. Stop.
>
>
> I use Ubuntu 8.04.This is the latest svn down
I meant to mention that
byte ordering does some strange things to Vietnamese dictionaries. The
Vietnamese script is a Latin script, but because it uses some odd
characters code point ordering results in illogical and
non-alphabetical entry ordering. For example, the "d" with a line
through it (
Quoting DM Smith <[EMAIL PROTECTED]>:
> Found an interesting thread on ordering dictionary entries. Currently
> we use byte ordering for the key which results in UTF-8 or Latin-1
> (cp1252) code point ordering.
There has been some discussion about this. IIRC the general opinion
was that the ori
Trying to build sword and get an error
creating vs2osisref
make[2]: *** No rule to make target `vs2osisreftxt.o', needed by
`vs2osisreftxt'. Stop.
I use Ubuntu 8.04.This is the latest svn download. I used ./autogen.sh,
./configure, make.
Peter
___
sw
Hi Steven,
OSIS files produced from USFM by Snowfall Software are structured as
[Testament] | Book | Section | Paragraph
with verse numbers as milestones.
OSIS files produced by some other means may be structured as
[Testament] | Book | Chapter | Verse
I assumed you were already aware of this,
14 matches
Mail list logo
