Beta testers for calibre 9 needed

[DNSB]

Originally Posted by BetterRed

So, its better that thousands of users change the "Column Header" value on their "#pages" custom columns, rather than one developer change the "Column Header" value on the "pages" built-in column

Do you have any indications that Kovid Goyal has used the Count Pages plugins and knew that it defaulted to a column header of Pages?

Originally Posted by BetterRed

I might if I was daft enough to have previously unchecked "Show this confirmation again".

Given that option was introduced running from the latest source? When did you have the option to unchecked that option?

Originally Posted by BetterRed

Why would anyone want introduce a custom column with the same Column header value as a built in column's Column Header value — other than "Because you can".

Rather than allowing that, IMO it would have been better to allow users to change Column header value for built-in columns - e.g

Sorry but I have to disagree there. Again, do you have any evidence that Kovid Goyal was aware of the existence of the Pages column header used by the Count Pages plugin?

As for changing the Column header value for built-in columns? That way lies madness.

[DNSB]

Just to help answer/confuse the question of whether the ADE synthetic page number algorithm is truly the be all and end all of page count techniques, I've attached an ePub originally created over a decade ago. Basically, it is the images from my font test ePub stored using Base64 encoding instead of JPG/GIF/PNG binary encoding.

[BetterRed]

Originally Posted by DNSB

Do you have any indications that Kovid Goyal has used the Count Pages plugins

None, but this is a beta version - and therefore subject to material change.

Originally Posted by DNSB

and knew that it defaulted to a column header of Pages?

It doesn't default, it suggests.

Originally Posted by DNSB

Given that option was introduced running from the latest source? When did you have the option to unchecked that option?

I didn't, but you posted a screen shot that indicates I will have the ability to uncheck the option.

Originally Posted by BetterRed

. . .
Why would anyone want introduce a custom column with the same Column header value as a built in column's Column Header value — other than "Because you can".

You seem to be conflating two issues -- the Column header value of the built-in 'pages' column, and the ability to create a custom column with a Column header value that duplicates a the Column header value of a built-in column.

Please answer my "Why would anyone…?" question

Originally Posted by DNSB

As for changing the Column header value for built-in columns? That way lies madness.

Why?

You and others have have correctly stated that its the value in Lookup name that matters not the value in Column header… in which case why not let the user change them… given they will have the ability to duplicate them.

BR

[ownedbycats]

Originally Posted by ownedbycats

There's only Calibre Pages on the Sort By menu, so I have to switch to table-view to sort by that.

Weirdly when I restart it seems to randomly pick whether to show the custom or calibre column. strange behaviour

[DNSB]

Originally Posted by ownedbycats

Weirdly when I restart it seems to randomly pick whether to show the custom or calibre column. strange behaviour

On my Windows box, I just checked the 2 pages columns. One has the lookup name of #pages while the other has the lookup name of pages.

If I disable one, the other one is the only one that shows. If I disable both, neither showed. If I enable both, both show. This was tested making the changes and then restarting calibre 5 times for each variant.

This is running calibre from source updated yesterday. No commits appear to have been done in the last 2 days.

[DNSB]

Originally Posted by BetterRed

It doesn't default, it suggests.

Odd, when I installed the beta, the Pages builtin column was created. No suggestion about it.

Originally Posted by BetterRed

You seem to be conflating two issues -- the Column header value of the built-in 'pages' column, and the ability to create a custom column with a Column header value that duplicates a the Column header value of a built-in column.

Please answer my "Why would anyone…?" question

As far as I can tell, you seem to be upset that calibre's new column for displaying page counts uses the same column header as the default for the page count column for the Count Pages plugin.

Given that you could not create a custom column with a header duplicating another column until a change to calibre was made very recently, the old saw about a tempest in a teapot comes to mind.

As to why someone would want to do this? I lack the ability to understand why someone would want to duplicate headers. That this happened was likely due to the lack of knowledge that a column header used by a plugin was being duplicated.

Originally Posted by BetterRed

You and others have have correctly stated that its the value in Lookup name that matters not the value in Column header… in which case why not let the user change them… given they will have the ability to duplicate them.

My reason for not wanting to have builtin column header to be changeable is simply that some utilities I use use the column header and not the lookup name. That I could, in theory, open a library database and rename all the custom columns in custom_columns to 'Custom' is not very useful.

[Comfy.n]

Originally Posted by DNSB

Odd, when I installed the beta, the Pages builtin column was created. No suggestion about it.

CP Plugin merely suggests.

[BetterRed]

Originally Posted by DNSB

Odd, when I installed the beta, the Pages builtin column was created. No suggestion about it.

The subject of the exchange was the Count Pages plugin, not the beta. The plugin does not create any custom columns - the doco identifies the columns needed, their column types and suggested Lookup name and Column Header values - one of which is pages/Pages ==>> Count Pages

Originally Posted by DNSB

As far as I can tell, you seem to be upset that calibre's new column for displaying page counts uses the same column header as the default for the page count column for the Count Pages plugin.

"Upset" - no. "Disappointed" - yes. By the manner in which the DisabledReader's concerns have been dismissed, summarily.

I raised the point though for the thousands of users of the plugin that are not technically minded.

Telling them to go away and just make changes to their library setup, is likely to cause greater issues.

As the development is still in beta it would be better to change the internal column name, in my view anyway. ==>> 241

Originally Posted by DNSB

Given that you could not create a custom column with a header duplicating another column until a change to calibre was made very recently, the old saw about a tempest in a teapot comes to mind.

Allowing users to create duplicate Column Header values does not address the concern raised above, it's a red herring wrapped up in a canard.

Originally Posted by DNSB

As to why someone would want to do this? I lack the ability to understand why someone would want to duplicate headers. That this happened was likely due to the lack of knowledge that a column header used by a [widely used] plugin [that's been around 14½ years] for was being duplicated.

By the beta version developers - what's a beta for, if not to identify shortcomings and oversights, and address them prior to release.

Originally Posted by DNSB

My reason for not wanting to have builtin column header to be changeable is simply that some utilities I use use the column header and not the lookup name.

Which 'utilities'? If you mean those shipped with calibre - then which ones? If third-party - another red herring.

Originally Posted by DNSB

That I could, in theory, open a library database and rename all the custom columns in custom_columns to 'Custm' is not very useful.

Ah-ah - a hypothetical hobbyhorse clutching at straws.

BR

[un_pogaz]

Originally Posted by ownedbycats

I installled beta. Prexisting column named Pages (#pagecount). I tried to set the width in look & feel but didnt know which is which. Adding lookup name would help.

Right, that also a change in source but not in the last beta https://github.com/kovidgoyal/calibr...88778221b28361
But from now, use the button "Use a custom pages column", select any column, then open the template editor and set the correct lookup name.

Originally Posted by ownedbycats

There's only Calibre Pages on the Sort By menu, so I have to switch to table-view to sort by that.

Thanks for the report, I will look at it.

Originally Posted by ownedbycats

Additionally, with my custom #pages column, for some reason every book over 1000 pages is exact same width, and notably thinner than a 997-page book.

Hmm, strange because the "max pages" is to 1500.
Unless you use a custom template, rather than on from the button "Use a custom pages column", if so please share you template.

Originally Posted by ownedbycats

option to set priority on initial page-count indexing would be nice

Calibre page-count is quite fast, perform automaticly for new added books, at the pace of average 3 book by second, 1000 par hours (so very faster than Page Count plugin).
So put a priority ordre is not a problem once that the all the library scan is perform, you just need to wait that it done.
In the beta their is a issue that pages count queue can be frozen when reopen a library, but their also a fix in the master for that https://github.com/kovidgoyal/calibr...cba2f2b4bb1fc3

Also, unlike PC plugin, Calibre Page Count perform the rescan of a book only if their size is different from when the previous scan was perform, leading that rescan the all library is even faster on book already scanned (average twice faster).

[un_pogaz]

Originally Posted by BetterRed

So, its better that thousands of users change the "Column Header" value on their "#pages" custom columns, rather than one developer change the "Column Header" value on the "pages" built-in column.

BetterRed, and anyone in this debat, I undertstand your disapointement, but what solution do you propose? What name should the built-in Calibre page count column have? A relatively explicit, clear, and concise name that contains a Pages Count?
And above all, what serious issue you want to solve by?

Until now, excuse me for this lack of politeness, but your best argument was

Their is two column named "Pages" in my library. Please fix this for me.

That's not an argument, it's an opinion.
Because, at no point you did raise real and serious issues that was more greater than "annoying".

So we could argue that of because of the Pages Count plugin, their is a lot of librarys that already contain a "Pages" column...
But that's not enough. Because it's far too easy to rename a custom column create by the user to reflect their real use of it.
Okay right, that annoying, that need a bit work from the user that fall in this situation, but that the better we can do.

So, unlike you proposes a real solution, a solution that will be discussed and may or may not be accepted, you words are not matter.

In addition, we do not know the actual statistics on the number of people who have installed the Pages Count plugin, or even less the people that use a column named "Pages", but thousands of users on the 2,000,000 calibre one? That less than 1%. Thousands seem a lot, but on a more wider view, is not enough affected user to realy start to envisaged to rename it on something else. And a warning on the changelog will be good enough.

Unless someone puts real arguments and real issues tha matter on the table, I consider the subject of the namming of the Calibre Pages closed.

[JSWolf]

Originally Posted by DNSB

Umm... Jon, I had Pages/#pages from using the Count Pages plugin. When I updated to the calibre beta and the Pages/pages builtin column was added, I did not see any conflict between the two Pages column since they had different lookup names. The only issue was with the mark 1 eyeball which only saws the column heading.

What Kovid did in the change was to allow you to create/rename custom columns with duplicated column headings but the lookup name is still required to be unique.

But as you see in post #283, you'll see that when giving a list of columns to choose from, there are two columns with the same name. The looking could do something like Pages (#pages} and Pages ({pages}) so you know which is which.

Also, I do think many people who are using Count Pages have Pages as the display name of their page count column. So would it be easier for all of those people to change their column name or for Kovid to change his column name?

[ownedbycats]

Originally Posted by un_pogaz

Hmm, strange because the "max pages" is to 1500.
Unless you use a custom template, rather than on from the button "Use a custom pages column", if so please share you template.

Template is just {#pagecount}. My books vary from just 1 page to ~15,000 (super-long fanfic).

[un_pogaz]

Originally Posted by ownedbycats

Template is just {#pagecount}. My books vary from just 1 page to ~15,000 (super-long fanfic).

Ah, yep don't work like that.
The template require a decimal value bettwen 0.0 to 1.0 (min/max), so put it a raw field dosn't work. {pages} work because Calibre detect it as a special field and do a transform behind.

To use a custom column use the button "Use a custom column" and select the one you want (or pick anyone and open the editor to set the correct field)

You should end up with this as your template:

python:
from calibre.gui2.library.bookshelf_view import width_from_pages

def evaluate(book, context):
    val = book.get('#pagecount')
    try:
        pages = max(0, int(val))
    except Exception:
        return '0.3'
    return str(width_from_pages(pages, num_of_pages_for_max_width=1500, logarithmic_factor=2))

From them, you can edit the parameter "num_of_pages_for_max_width" to the max page you want, but I do not recommend using 15,000, because is rare and the vast majority of books will be bellow that, so every books will be narrowed. Better 5,000 or 10,000, to you to see.

The "logarithmic_factor" parameter is here for give more width to book that bellow the average, so that the render spine was not all too narrow. Bigger is, bigger the small book have bigger width. Tweak this if you want, but their is not recomendation for that (advanced settings)