Indexing question

[KevinH]

Qt QString does have a locale aware comparison function but the user's locale is used and it can not be set in the function call. On Mac OSX it uses the International Setting Preferences to determine the locale to use.

The only issue then would be the ebook author who runs Sigil must run Sigil in the locale for where the book is to be read. For those authors running Sigil in their native language, there should be no issues. For those ebook professionals who develop ebooks with multiple translations this is going to be an issue.

I can try to change the code to use a locale aware comparison, but handling this in a plugin may be better as it gives you more control for locale source and destination possibilities.

[roger64]

The only issue then would be the ebook author who runs Sigil must run Sigil in the locale for where the book is to be read. For those authors running Sigil in their native language, there should be no issues. For those ebook professionals who develop ebooks with multiple translations this is going to be an issue.

To expect from a [locale]* publisher to use a [locale] interface of Sigil does not seem to be an undue requirement. This would already be a big step forward for the "accented" world...
* insert your own language here.

I can try to change the code to use a locale aware comparison, but handling this in a plugin may be better as it gives you more control for locale source and destination possibilities.

Let see if there are some proposals..

[roger64]

I've found this article

https://en.wikipedia.org/wiki/Alphab...ic_conventions

which gives some insight about this question. It explains why it's sound to abide by language specific conventions when using alphabetic order lists.

Of course there is also this, but for experts only.

[KevinH]

roger64,
There is no issue about how to go about this. Only if it would be better done in a plugin or not. Doing it in a plugin would allow the ebook developer to specify the target locale independently from the current locale the ebook developer is operating in. Whereas the localeAwareCompare used in QString in Qt does not.

[roger64]

@KevinH
Thanks for your very useful explanation - and patience.

[roger64]

About index-size

This will be my last 2015 question.

It's related to index-size but maybe the answer is not Sigil related. I have been puzzled by some figures that I checked with both the Calibre Editor and Sigil: they provide very exactly the same figures.

Take an EPUB with a medium-size index included (530 entries or so).
The total size of this EPUB (images, fonts, everything) is 2129 k
When I open this EPUB and check the size of index.xhtml (either using Sigil report tool or right from the Calibre editor file navigator) it's 364 k
I suppress index.xhtml, plus what is in the Index Editor window (I know it's a little more than 7k.
I save and open again: the new size of the EPUB is now 2098k.

This process can be reversed. Importing a 7k text file, creating a 364k index file on this 2098k EPUB and ending with a 2129k EPUB.

I am just puzzled...

A logical answer would be that the suppressed files were not really suppressed. Is this possible? After deleting, I did save.

[KevinH]

An epub is compressed. If you remove a file from an epub, you will only save the size of the compressed version of the file. So your 364k file compressed was 2129k - 2098k = 31k in size roughly. Given many of the links have similar hrefs, that seems okay to me.

Perhaps, I do not understand what you are asking?

[Doitsu]

Originally Posted by roger64

I suppress index.xhtml, plus what is in the Index Editor window (I know it's a little more than 7k.
I save and open again: the new size of the EPUB is now 2098k.

I'm also not quite sure what you're asking about. (I'm assuming that by suppress you mean supprimer, which is remove in English.)

If you generate an index, Sigil will add a special index entry to each paragraph in which the entry occurs. It has the following format:

id="sigil_index_id_1"

Even if you delete Index.xhtml and the Index editor entries, these special ids won't be automatically deleted. I.e., each initial index generation will increase the file size of an ePub.
If the file size of an ePub is important to you, you'll have to manually remove these ids from the epub file using a regular expression:

id="sigil_index_id_\d+"

[roger64]

Thanks for your answers and sorry for being unclear. Yes by using "suppress", I really meant "remove"...

OK: I will clean thoroughly this EPUB of all its index tags and do the maths again... in early 2016.

I wish you all and Sigil a happy New Year.

[roger64]

This question arises from a casual look I gave to a Sigil report on the EPUB where I had added an index: I noticed that the total size of all text files was 473k and that the size of the index file was 364k. Really? an index whose size is 3/4 of the text files? I wanted to know more about it.

Here is the answer: basicallly, as Kevin said, it's all about compressed and uncompressed sizes. But if you do not check it, you do not know it...

Without any index at all,
the compressed EPUB size is 2092 k
the uncompressed EPUB size is 2608 k
But once indexed,
the compressed EPUB size increased to 2129 k (a + 37 k)
the uncompressed EPUB size increased to 2978 k (a + 370 k)

It appears from these figures that index data are particularly sensitive to compression (from 37 k compressed size to 370 k overall* uncompressed size).

@Doitsu
Other information: the compressed size of the 1657 index tags was about 7 k but this figure only adds to the text files, not to the index.

* saying "overall", I count the 364 k of the index.xhtml file plus the 7 k text data above.
The data left in the window of the index editor belong to Sigil.