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 4 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).