Beta testers for calibre 9 needed

[theducks]

Originally Posted by BetterRed

I just discovered one can have a fixed width spine.

Why do the 'shelves' have to be horizontal, if they were vertical ('piles') one would not have to adopt the posture of a swivel-eyed loon to read the titles

BR

Oh No, you used the IKEA DVD/CD shelves

[kovidgoyal]

Originally Posted by DisabledReader

The built-in Pages column defaults to On in the Book Details panel and the Book Information (I) window. Should probably be Off by default.
Also, it's not showing in the Create Catalogue function.

No, if defaults to off everywhere. Try this

CALIBRE_CONFIG_DIRECTORY=/some/temporary/directory calibre

Now you will have no Pages column in book details. The book information popup window deliberately shows all hidden columns such as last modified and pages and id and uuid and so on. As for catalogs, I'm afraid that bit of calibre is largely unmaintained since its creator lost interest in it.

[un_pogaz]

Originally Posted by JSWolf

So a book with say a graphics for the chapter titles will show up a lot larger then it should because of the 1000 words per graphics.

1000 characters, not words, and I will not reopen the subject. Comprosmise must be made and that the one done Calibre.
Also, 1000 characters is a half-pages, and ONE graphic per chapter will have only a relatively insignificant impact on the finale size comparé to the text of the all book.

Originally Posted by BetterRed

The ONLY books for which I maintain a page count in a custom column (#pages/Pages), are those that have a format of HARDBACK, PAPERBACK or PDF otherwise it's empty (Undefined).

Oh, and Comics

Added : then there's the documentation for the widely used Count Pages plugin (which was released in May 2011) :-

Good for you. Your are someone meticulous.
But I affraid that is not the usage of the vast majority of users.
And the documentation of Count Pages will not help your case because it imply that the except use of the plugin and of a "Pages (#pages)" column is by 'brute force', so in a similar way that the Calibre Page do.

This lead that we can found two column with the same header, especialy on old library that was create before the Calibre Pages addition.
And?
Seriouly, And? What?
Okay that confusing, is regrettable. But what serious issue that create? What serious solution do you propose to resolve this?
Because, all the arguments I see are things already know and so the current choice it was done knowingly as an acceptable compromise.

What I see is:

• that one of the two is a Custom Column, so that the user can edit them to the name of their choices to reflect their use
• nothing force you to display or use the two column at the same time

Beside, Kovid just accepted a PR that allow the user to add/change a custom column header with one that already exist.

[Wiggo]

Originally Posted by un_pogaz

Okay that confusing, is regrettable. But what serious issue that create? What serious solution do you propose to resolve this?

Easy peasy - a fix spine width for those who don't have a pages column.
Those who haven’t been interested in the page count so far won’t be interested in it in the future either, everyone else has the Count Pages PI.
In short - do it like https://github.com/mawise/bookshelf?...e#3d-bookshelf (which still looks far better)

IMO for your private bookshelf crusade, many people are being forced to put up with a column that is redundant and, after hours of background fiddling, also delivers poor results.

[BetterRed]

Originally Posted by Wiggo

Easy peasy - a fix spine width for those who don't have a pages column.

You can also use a number between 0.0 and 1.0 to pick a fixed size.

My "Template for spine width" is set to .25

BR

[Wiggo]

Originally Posted by BetterRed

Attachment 220236



My "Template for spine width" is set to .25

BR

You have to read the whole paragraph.

[un_pogaz]

Originally Posted by Wiggo

Easy peasy - a fix spine width for those who don't have a pages column.

Those who haven’t been interested in the page count so far won’t be interested in it in the future either, everyone else has the Count Pages PI.

IMO for your private bookshelf crusade, many people are being forced to put up with a column that is redundant and, after hours of background fiddling, also delivers poor results.

Yes, all this point are valid. Their is plenty way to use the bookshell view, thanks to the template.

The heart of the debate that BetterRed is talking about here is:
How the Calibre buildin column pages is named "Pages (pages)".

The rest, whether you use it or not, or how, that not the debate.

Originally Posted by Wiggo

IMO for your private bookshelf crusade, many people are being forced to put up with a column that is redundant and, after hours of background fiddling, also delivers poor results.

• forced: nothing is "forced", is a colmun like any others, use it if you want, or not.
• redundant: side effect to this late support, but explain me why is a serious issue?
• delivers poor results: before I continue, can you explain me what is a good result?

[JSWolf]

For those who want to start using Count Pages, they are forced to name their page count column something other then Pages.

[un_pogaz]

Originally Posted by JSWolf

For those who want to start using Count Pages, they are forced to name their page count column something other then Pages.

A recent change in master allow the user to create custom column with a already used heading https://github.com/kovidgoyal/calibr...b415dc847cab96

[JSWolf]

Originally Posted by un_pogaz

A recent change in master allow the user to create custom column with a already used heading https://github.com/kovidgoyal/calibr...b415dc847cab96

Thanks for that info.

[DNSB]

Originally Posted by JSWolf

For those who want to start using Count Pages, they are forced to name their page count column something other then Pages.

Odd. A custom column with it's lookup/search name starting with # (i.e. Pages/#pages) does not seem to cause any issues with the Pages/pages used by calibre.

Can you point to an example of where you are seeing an issue?

[JimmXinu]

A warning for Calibre Sync users: Calibre Sync is incompatible with Calibre 9's library changes.

My phone shows Calibre Sync last updated 2025-Apr-1.

Originally Posted by kovidgoyal

It will be because the isbn, lccn and flags columns have been deleted from the calibre books table in calibre 9 (they were never used for anything and just tkae up unneccessary disk space). The developer of Calibre Sync should update his SQL query to exclude those columns.

[BetterRed]

Originally Posted by DNSB

Odd. A custom column with it's lookup/search name starting with # (i.e. Pages/#pages) does not seem to cause any issues with the Pages/pages used by calibre.

Can you point to an example of where you are seeing an issue?

I see an issue when the user is presented with list of Column header values which are not unique, from which they must make selection. Here's a couple:

gridview field under cover


view manager


I have no idea which "Pages" is which.

And, when version 9 is released if I was daft enough to add a custom column with a Column header value of "Publisher" I wouldn't know which "Publisher" was which either.

BR

[Terisa de morgan]

Originally Posted by JimmXinu

A warning for Calibre Sync users: Calibre Sync is incompatible with Calibre 9's library changes.

My phone shows Calibre Sync last updated 2025-Apr-1.

Thank you, so I'll stay on calibre 8 in the meantime.

[DNSB]

Originally Posted by BetterRed

I have no idea which "Pages" is which.

Simple answer would be to rename the column with lookup name #pages to some other name. CP_Pages? Page Count? After all, the name does not really matter, it's the lookup name that is the real identifier.

Originally Posted by BetterRed

And, when version 9 is released if I was daft enough to add a custom column with a Column header value of "Publisher" I wouldn't know which "Publisher" was which either.

Would you disregard the warning that you are about create a column with the same heading/name as an existing column?