Formatting series number nicely

[srs]

When sending a book to my kindle I use this plugboard: "{series_index:|| - }{title}" to add the series index to the title of my book.

Unfortunately when the series has more than 9 books, the book is sorted incorrectly in the kindle (it goes 1, 10, 11, 2, 3, ...). I know I can use "{series_index:0>3s|| - }{title}" (have to use 3 zeros as some series have > 100 books), but this looks ugly as the vast majority of series are less than 10 books.

Is there any way to format the title so that only the necessary number of 0s are added (eg a series with < 10 books will have no 0s prepended, while one with > 100 will have two 0s prepended).

I'm ok with adding a custom column to indicate large collections, but then I would need to use a template within a template.

Any suggestions?

[JSWolf]

Originally Posted by srs

When sending a book to my kindle I use this plugboard: "{series_index:|| - }{title}" to add the series index to the title of my book.

Use the following plugboard: "{series_index:0>2.1s| | - }{title}"

[eschwartz]

You are not the first person to ask for this.

See: https://www.mobileread.com/forums/sho...72#post2916772

Requires running a python script via calibre-debug.
You will end up with a custom column containing the formatted series_index.

[srs]

ok I came up with the following:

added a custom column: 'formatted_series_digits'
and a custom column:

program:
	finish_formatting(field('series_index'), strcat("0>", ifempty( field('#formatted_series_digits'), '1'), "s"), '', '')

kinda hacky in that you need to specify how many digits you want, but only a few series have > 10 books so I can live with it.

[stormsh]

Hello there. I'm new to calibre and just start figuring out what owesome stuff I can do with it. But at the moment I'm kind of lost. The solution is right in front of me, but I don't understand it. Please help.
I have kind of the same problem as SRS. The bookseries has 2800+ books. The Index is nicely done, starting at 1 and ending around 2800. The sorting problem is mentioned by SRS.
Because I don't mind starting the series with 0001, is there a way to add 3 zeros to the first 9, 2 zeros till 99 and 1 zero to 999? And with the Metadata Editor?
I have absolutely no idea how to get a python script working. So that's no option, sadly.

Thx 4 F1.

st.

[eschwartz]

The only way is by using that python script, or a complicated series of time-consuming commands . Simply paste it into a text file, and save it as add-series-to-custom-column.py and then open a command prompt, type "cd \location\of\folder\goes\here\" (most likely your downloads folder ) and type "calibre-debug.exe add-series-to-custom-column.py"

Err, additionally you will have to enter the library path, and change the custom column to a suitable name, so I am uploading a modified python file (in a zipped folder, because we cannot upload .py files) that imports the path to your most recent library.
Use a custom column called "formatted_series", or edit the file to change it if you want.

[stormsh]

Hi eschwartz, thanks for the detailed info. Before I do this, I have some questions in hope of understanding what I am doing.
But first some more info for you.
The books already have a series_index, starting with 1. When I open the Metadata dialog from a single book, the field the series_index is in is called "Number" (and the value is 1.00 to be precize). This is the field I want to alter. And I want to do it in the calibre DB, not only when I transfer the books somewhere and not in a custom column (I don't want to sound rude, my english is not better, sry).
The problem is that I don't understand the script good enough to alter it the way I need it to work for me. I can't even see where to say that its going to be 4 digits max with zeros in front (0001 or 0987 or 2498 e.g.). As I understand it, it should not matter if I write this value in a new column or in an existing one!?
So I just alter
"cache.set_field('#formatted_series', dct)" to
"cache.set_field('#series_index', dct) and everything should work?
Can I alter a field that has the value I need to alter?
Sorry to bother you with this. I should probably not deal with this if I can't handle the syntax. But I would like it neat and tidy ...

Thx 4 F1.

st.

[eschwartz]

You must use a second column, of type text. series_index is a builtin and contains data of type number (float I think), so the database will automatically remove the leading zeroes when storing it. The second column gets around that issue.

OTOH, that is indeed the correct way of changing which column you use to store the value.

So, what this script does is set the number of leading zeroes based on the highest series_index value in a particular series. If the series has books 1-9, no leading zeroes. If the series goes from 1-99, one leading zero for books 1-9. And so on.

[stormsh]

so the database will automatically remove the leading zeroes when storing it

Ok, now that is an interesting piece of information!

So even if I store the series-index with the leading zeros in the series_index itself the DB will remove it anyway. Hm, time for a feature request I think .

Now, just some more questions: This script does not create the new column, right?
I just create a new one "of type text". Why Text when I put numbers in it? Numbers are text as well!?
And I can find it in Metadata by searching for #my-column I guess?

Btw I like the part of the script "import math". What does it do? Math, obviously ^^.

Edit: I created a new column called Index and found it in the metadata under #index. Nice. So I try your script in a few minutes and see if the DB implodes.

Edit 2: It didn't implode, that's the good news. It wrote something, that's the other good news. But instead of the numbers, in the #index column is now: {0:02.0f}
What ever that means. Any ideas what I did wrong?

Edit 3: There were no errors or anything.

st.

[eschwartz]

The text column is because numerical data fundamentally stores numerical data, and leading zeroes are textual data. It is not calibre doing that.

We want a number with the appropriate formatter attached, which is what this script attached.

[stormsh]

Hi eschwartz. Ok. But what I get instead of "0001" or "0456" ist this (see screenshot).

Did I do something wrong?

st.

[BetterRed]

Originally Posted by stormsh

Hi eschwartz. Ok. But what I get instead of "0001" or "0456" ist this (see screenshot).

Did I do something wrong?

st.

Moderator Notice
Yes, you included a link to your password protected cloud site, which I have removed.

Please use the image attachment features provided - see Attachments and Images

@eschwartz - I may be missing the point, but why not 'format' the series number (float) into a right justified fixed width string custom column.

BR

[stormsh]

Sry. Here it is.

[eschwartz]

Sorry for the confusion -- this script creates a custom column that contains a formatter, you still use the series_index.

For instance:

program:

new_series_index = format_number(
	field('series_index'),
	field('#format_series')
);

@BR -- chaley made this, and I assume used this method since it allows one to change the series_index info to a limited extent without requiring a rebuild.

[chaley]

Originally Posted by BetterRed

[MOD]
@eschwartz - I may be missing the point, but why not 'format' the series number (float) into a right justified fixed width string custom column.

Although one can specify right justification in the spreadsheet view, one cannot specify the width (number of digits).

The template processor removes leading and trailing spaces, so even though you can specify fixed-width right justification, the leading spaces will be removed. For that reason you must specify leading zeros, in which case left or right justification doesn't matter.

The purpose of the script is to generate the minimum sized number specification for all the books in a given series, taking into consideration digits on both sides of the decimal point. The person I was helping when I wrote it did not want to use a fixed template for all books, because some series had indices such as "nnn.nn" and others were simply "n".