Minor bug in the TOOLS > REPORTS

[fdwojo]

As much as I like to think I know my way around how programs operate, I've just noticed what might be a problem in SIGIL 2.2.1 that I don't think its something I'm causing.

When I have an EPUB open in SIGIL and then bring up the REPORTS feature (under tools), and then select the HTML FILES line, I typically like to find out which files have the most words, so I sort by "All Words". But when I do this, It doesn't seem to sort that column numerically. For the example I'm looking at, (keeping it very short), I can see that my ALL WORDS column shows the following numbers:

g1_hints_27.html ----- 980
g1_hints_25.html ----- 796
g1_hints_22.html ----- 762
"
" --------------------------- (skipping several properly descending lines)
"
g1_tips_08.html -------- 42
g1_cover.html ----------- 1 -- (all is good up until here, and then…)
g1_hints_19.html ---- 1,579
g1_hints_c2.html ---- 1,567
g1_hints_c3.html ---- 3,236
g1_hints_28.html --- 11,789
g1_hints_15.html ---- 2,074
g1_hints_c4.html --- 13,418
TOTAL WORDS: ---- 41,593

All the other columns work perfectly whether I sort ascending or descending. But the ALL WORDS column seems to be a bit psychotic. I've tried opening several other EPUB files (some I've created, some are professionally published) and all of them have a weirdness when you try to sort by ALL WORDS. In one case, it starts with:
96
1
9170
3414
and continues, sometimes increasing and sometimes decreasing each line.

Anyone have any idea if I'm alone in this? Am I doing something wrong or have an improper setting I should check for? Should I be reporting this (somehow) to the devs?

And just for the record, I'm using the most recent version (2.2.1) with the PC mentioned in my SIG.

[BetterRed]

You're not alone, I see the same, I opened the Sigil Manual to test. Weird.

The developer's will see it here.

BR

[theducks]

Wow!
I had not noticed as I just usually look at file size.
But I can confirm the sort is screwy.
(all the other cols sort normal)

[KevinH]

I will look into fixing this.

Update, the problem is caused by the thousands separator (the comma in this case), the conversion from its string representation to numeric is having issues with it since it can change its meaning depending on locale.

[KevinH]

This bug has now been fixed in Sigil master. It will appear in our next release.
Thank you for your bug report!

[fdwojo]

Thanks, Kevin. I'm glad the cause was able to be found. There's more I need to learn about Sigil (even though I've been using it for years), but the Reports are a very handy tool for me, so I'm glad it was resolved.

[BeckyEbook]

@KevinH: It's not good. Now the sorting by file size has stopped working.

[DiapDealer]

Originally Posted by BeckyEbook

@KevinH: It's not good. Now the sorting by file size has stopped working.

Still seems to work on Linux. Do you mean it doesn't sort at all (no change), or that it's sorting incorrectly?

EDIT: And it seems to be working for me on Windows as well. Perhaps it's a locale issue?

[KevinH]

It works just fine for me on macOS after my fix. The only change was in Misc/NumericItem.h

The locale dependent thousands groupSeparators were messing up converting the text value in each column to a float for comparison purposes.

So now we use the QLocale dependent routine to convert the text to a float value for numeric comparison. This should work under any locale dependent group separator.

If this is not working for you then perhaps we need to set the default QLocale to use in main.cpp.

Could you try that?

#include <QLocale>

early in main.cpp add

QLocale::setDefault(QLocale::system());


or replace QLocale::system() with whichever locale you want. Please see the note below that tells how a system locale is generated on Windows.

Returns a QLocale object initialized to the system locale.

The system locale may use system-specific sources for locale data, where available, otherwise falling back on QLocale's built-in database entry for the language, script and territory the system reports.

For example, on Windows and Mac, this locale will use the decimal/grouping characters and date/time formats specified in the system configuration panel.

[KevinH]

Also, since a header file was changed that is included in almost all of the reports cpp files, please try a full clean build just in case.

If it still does not work, let me know and I can try just getting the groupseparator string from QLocale() and manually removing it before trying the old toFloat() approach. That should work as long as it is the same as the groupseparator used when building the strings for the report tables in the first place.

[BeckyEbook]

Strange.
I did a full clean build many times.
Fresh ZIP file from github etc.

The main.cpp idea was causing an error during the build.

W:\Develop\Sigil\Sigil-master\src\main.cpp(146): error C2761: "void QLocale::setDefault(const QLocale &)": Ponowna deklaracja składowej nie jest dozwolona

[ang. member function redeclaration not allowed]

Anyway setDefault for QLocale: If this function is not called, the system's locale is used.

In the attached gif I show the problem.

[KevinH]

I just can not figure out why your QLocale().toString() function and QLocale(QString).toFloat() can not be properly working. It seems to work everyplace.

And how can the text "66.82" can not be converted properly to a float is very strange.

I know some locales use "," as a group separator and some use commas as a decimal point (like France). Other places use blanks or non-breaking spaces as group separators.

Since that value is generated by QLocale().toString() that same QLocale().toFloat() should handle it.

So for Poland:

what is your locale decimal point, and thousands group separator characters?

[BeckyEbook]

Originally Posted by KevinH

So for Poland:

what is your locale decimal point, and thousands group separator characters?

Decimal point: comma
Thousand group separator: space

[BeckyEbook]

BTW: After changing the code in the report to 0 decimal places, the sorting works nicely (but that was to be expected).

QString fsize = QString::number(ffsize, 'f', 0);

[KevinH]

Oh, but your image for file sizes all show decimal points as '.' not a comma.
That is freaking out the QLocale().toFloat().

So I am missing the use of QLocale() to generate the file sizes and that is what is causing the trouble.

Let me see if QString::number() has a QLocale equivalent.