How I Manage eBooks with calibre

[unboggling]

Post deleted.

[unboggling]

Thread Rules

Please post elsewhere any questions about how calibre works, or any requests for help with a problem, by starting a new thread in the main calibre forum or relevant calibre subforum.

Please post in this thread feedback about the first post, recommended changes to it, or comments about different ways to manage ebooks with calibre.

[PeterT]

@Unboggling; any thought into putting this into an alternate format, maybe (oh horrors) an ePub?

[unboggling]

Originally Posted by PeterT

@Unboggling; any thought into putting this into an alternate format, maybe (oh horrors) an ePub?

I'd thought about it. Generating an ePub would be relatively easy to do. But it seems like it's more accessible online here than in an ePub that might be added to someone's library then forgotten. At least if I added it to my library, I'd probably forget it was there. It's easier for me to deal with frequent revisions by just pasting new version over older version at Post #1 of this thread.

[unboggling]

Originally Posted by PeterT

...maybe (oh horrors) an ePub?

Giving a book version further thought:

Translating the BB code formatting of the version at Post #1 into HTML is relatively painless, per suggestion of theducks to copy the HTML of the post page and paste it from there into an editor, but then spoilers need to be stripped and formatting redone to be more suitable for a book. I need to revise this document frequently with changes to fix unwitting errors and keep it congruent with my actual settings, customizations, and workflow. A book version doesn't seem practical.

[unboggling]

The content of Post #1 now seems relatively stable and problem-free, though it will still need revisions for changes in calibre or in my workflow. Please let me know if you find any problems I missed, so I can fix them. Meanwhile I've been thinking about the future direction of this project.

1. Searching the forums works best for small posts, when each post is limited to one specific topic. This large document has lots of topics, so it pops up often when using forum-search for keywords, which may annoy people searching for solutions to specific problems. That brings up the post but doesn't show where keywords are in the document unless the spoilers are expanded to allow looking for the highlighted keywords. Alternatively, if all spoilers are expanded first, a browser search of the document for keywords works well. Without expanding spoilers first, a browser search for keywords when viewing the page source also works but shows any keyword hits from HTML tags. All the search methods are awkward for one reason or another.

2. If I transform this project into a website:

• + People could link to it from a post or sticky here, avoiding the search problem here.
• + Site would have internal search feature.
• + HTML and CSS would be more flexible than BBcode for formatting.
• + After each revision of content, it could be transformed into an ebook with significantly less work than from the BBcode-formatted document here.
• - Implementation would require learning more HTML and CSS along with the initial work of setting up the site. Good for me in the long run for eventual use with ebooks, but still time-consuming.

3. I'm not sure how useful this project is to other people. The content is different from and broader than the usual calibre forum content of "how do I do this new-feature-to-me?" or "how do I solve this small specific problem?" Last year, as a new user I looked for content like this, overall maps of how other people used calibre, including strategy and workflow along with examples. Couldn't find anything as broad as I wanted, just disorganized bits and pieces throughout these forums. So started the KISS thread, and that eventually grew into this document. I still wonder if others find it useful, if there's a common need for this kind of content.

What do you think? Feedback will help me decide what to do. Please comment, either by private message or in this thread.

[brainvision]

I already gave you karma points - as you know - 'cause I found this thread very very useful: I think that it contains a lot of information that everybody needs! Once starting using Calibre more in depth, than maybe will not follow al of your suggestion, but sure they are excellent example to show us what Calibre can do and how we should think at this program.

I prefer to read the post little by little, a paragraph at once,to be sure to really understand it and with the intention to try by myself your approach..
I don't know what you should do to give more emphasis to this post, but I'm pretty sure you should do it! And, more, if you can and if you want, you should try to make it always better and complete!!
Examples are always the best way to learn when we are talking about software and practical things to do..

thank you very very much, once again!
I really appreciate this "little" but precious work!
see you!!

[unboggling]

You're welcome. Glad to hear you find it useful. Thanks for the glowing endorsement. Made my day.

Edit:
And thank you again for the karma last week. I like karma. And I like feedback even more. I plan to continue revising and adding to it, at least for awhile. I'm still thinking about the "give more emphasis to this post" thing, as well as future direction of the project.

[travger]

OK, I have some thoughts:

'Assessing Formats' - Bulk Convert to Preferred Format.
Seems a bit pointless to me. Pros - makes nice uniform library.
Cons - 1. Book that I fix today and feel happy about coloring headings purple may seem rather ghastly few years hence.
2. Any conversion may lose or add something (I'm presently reading a mobi book where there's no blank lines for the scene breakes, I doubt that they will appear after conversion. This particular book has such a twisted css that I must uglify very nice ePub in order to replace some code especially for the conversion to mobi. In this case I'll keep both nice formats).
3. When I don't read the book immediately, leaving original format be saves lot of time - just quick quality check is all.
4. By the time I get around to reading it, several things may have happened: I may have found better quality/preferred format; I may have gotten new reading device; my html skills will definitely increase.
5. Maybe next book in the series has different but nicer formatting, then I can change first one more easily, having an example.

Fixing Formats - Convert to Editable Format
IMHO converting anything html to word and back is not good practice. Editing for example ePub in Sigil is much more under control, it won't accept mistakes, and you can see right away the change (and maybe undo it).

Editing Metadata - Title
I prefer shorter title. Probably it's subconcious answer to Windows path length limit. A friend gave me his zipped library, and many books there were unextractable because the title was too long.

Maintenance -
Maybe warning about not to mess around directly in the Calibre folders should be capitalized?

[unboggling]

Originally Posted by travger

OK, I have some thoughts:

'Assessing Formats' - Bulk Convert to Preferred Format.
Seems a bit pointless to me. Pros - makes nice uniform library.
Cons - 1. Book that I fix today and feel happy about coloring headings purple may seem rather ghastly few years hence.
2. Any conversion may lose or add something (I'm presently reading a mobi book where there's no blank lines for the scene breakes, I doubt that they will appear after conversion. This particular book has such a twisted css that I must uglify very nice ePub in order to replace some code especially for the conversion to mobi. In this case I'll keep both nice formats).
3. When I don't read the book immediately, leaving original format be saves lot of time - just quick quality check is all.
4. By the time I get around to reading it, several things may have happened: I may have found better quality/preferred format; I may have gotten new reading device; my html skills will definitely increase.
5. Maybe next book in the series has different but nicer formatting, then I can change first one more easily, having an example.

Fixing Formats - Convert to Editable Format
IMHO converting anything html to word and back is not good practice. Editing for example ePub in Sigil is much more under control, it won't accept mistakes, and you can see right away the change (and maybe undo it).

Editing Metadata - Title
I prefer shorter title. Probably it's subconcious answer to Windows path length limit. A friend gave me his zipped library, and many books there were unextractable because the title was too long.

Maintenance -
Maybe warning about not to mess around directly in the Calibre folders should be capitalized?

@travger. Thank you for the feedback. It helps me. A lot.

Assessing Formats - Bulk Convert.
I will clarify what options I use in conversion. The issues of bulk convert and deleting original format both need careful reconsideration. I'll at least add some discussion of pros/cons for each of those issues, both of which I've seen discussed here more than a few times. I vaguely recall we also talked about some of this last year, and revisiting these issues now from the perspective of a year's additional experience will be good.

Fixing Formats - Convert to Editable Format
I agree, that needs some clarification and rethinking too. I've been learning HTML, CSS, and Sigil gradually and am probably to the point where I should ditch fixing in Word, OpenOffice, or LibreOffice in favor of preferably fixing in Sigil in my real-life workflow. In the workflow document I was thinking of changing the simple fix example from Word back to OpenOffice, but first I need time to figure out and test how to anchor graphics to paragraphs in OpenOffice. I wanted to use a simple example. And I wish I'd started learning ins and outs of Sigil sooner. I'll rewrite this section into at least 2 fix subsections, one for Sigil fix, one for OO fix.

Editing Metadata - Title & filename lengths
Yeah, Windows filenames does throw a wrinkle into long titles. And I suppose also long series names, when those are included in saves/sends. It's been years since I used Windows and I simply forgot…. Now you pointed it out and I read this Naming Files, Paths, and Namespaces, (Windows Dev Center) I realize I should change how I deal with title addendums and long series names such as with hierarchical series subgroups, since we all might as well try to be interoperable as possible with filenames, for principle's sake if nothing else. For Title, off the top of my head: only append very short items such as " - 3 Ed" or " - ARC" to make title more unique for editions. And put any omnibus elements into their own empty book wishlist record, rather than appended to title. And put long title addendums in custom column Note. For Series, I need to think about it some more, and test some templates for truncating and abbreviating - - and I can probably use or adapt one of chaley's examples from calibre user manual section on Template Language. This issue is probably why he used that particular example in the first place.

Maintenance - Calibre Library Folders
Done. Made entire paragraph bold - at least until I think of some other way to emphasize it significantly but more subtly (if that's even possible….)

It may take a few days to a week before any of these other changes (and subsequent dependent changes) go into effect in the document. My general rule is that any changes in the document get tested and worked into my real-life workflow first. Though to my regret and later rework, on some occasions I screwed up by including something I hadn't tested sufficiently. Such as un-KISS series numbering for Complex Series (in Edit Metadata section), that I'd tested with insufficient number of cases when overly tired. Which I just somewhat fixed, and probably still needs more work along with the other series conventions toward being simpler. (The more specific I get, the more I get in trouble….)

travger, thanks again for the feedback.

@all, you're welcome to chime in with discussion, comment, feedback.



Edit: So what is a good compromise on title or series name length, taking into account the whole path with filename needs to fit into what, 260 char? - Would you say 40 char for title? Seems too short…. Oops, let's see. Would also need path including title + series + series_index. So series name saved or sent by template needs to be a very short abbreviation derived from longer string in Series column.

[travger]

Always happy to be in the position to help; you're welcome.

You better be prepared that in Windows path starts with C:\ ...

I think it may be rather personal for what purpose anybody uses save/send and accordingly the needs for filename may be different. For example if screen is small and reader app is showing filenames, there's not much point having every filename like: Gordon Dahlquist - Miss Temple, Doctor Svenson, and ... disappearing at the edge of the screen.
That said, now I must confess that I use send/save very rarely - for me it's drag'n drop from Calibre folder to SD card.

I keep Book panel open, so Comments field is perfect for me to enter long title for the book. For example - Simple Smith: How Even a Village Fool Can Have a Fulfilling and Happy Life I enter into Comments with h5 or h6 tags, and Simple Smith into book title field.

For series I have 'Cycle' field as subseries, but if I needed to save to disk, I'd use just main series name and numeration. Cycle, Awards, Artist etc. info goes into file itself.

OMG, you speak so easily about templates and still hesitate about html ! (In Sigil you just have to click 'Insert picture'. Though I suspect you need something more complicated.)

One more point - when adding retail ebooks (or even most ePubs/mobis) it's rather safe to read metadata from the file itself. Pro side being also, that name of the downloaded file will not matter. I must add some info into custom columns manually anyway, so I'm eyeballing all the other fields too.

[theducks]

Originally Posted by travger

You better be prepared that in Windows path starts with C:\ ...

Only absolutely true if your system has a Single HD (with a single Windows accessible) partition)
Modern Systems can have multiple R/W drives (you should not have to worry about path length with Read Only media ), some removable. some networked. On a few occasions, I have had more than half of the available drive letters in use (data collection and processing. Hoo-Ray for the old Netware 4.x. No problems.)

[unboggling]

Revision notes:

Approach:
Added brief intro to clarify what it is and isn't.

Adding Books - Choose Method for Adding Books:
Added sentence that reading from file contents usually works well for retail-quality books from good sources.

Editing Metadata, Title or Series - and path/filename length issue:
Shortened the appends to Title. Mentioned an alternative for people wanting shorter titles might be putting that metadata into comments or custom column(s). Added separate paragraph (after Authors) about string length in Series and Title. Decided not to go into specifics about calibre automatically truncating when necessary to deal with various file system path/filename limitations, or the tech specs of those limitations (that would have been off-topic; and I don't know all the details). But added a few links under Filename Limitations in Links section. And added links for template info and examples in separate paragraph Set Templates in Reading Books section, and added links in Sending Books in Preferences section.

Other issues:
Still thinking about the issues with bulk convert, delete original format, and preferred fix with Sigil. Any changes there may be awhile since I want to get comfortable with any changes in real-life workflow before revising the document.

But I'm tending toward never deleting original format. In most cases that would give every book 2 formats, Preferred and Original. In the case of Preferred to Preferred, it would be Preferred and Original_Preferred, requiring Tweak save_original_format=true. For users learning how to fix books it's probably more important to keep the original formats, than for experienced book fixers who know what they're doing. I'm still in the learning how category, particularly with Sigil.

And I finally learned how to anchor a selected graphic to a paragraph in OpenOffice, preceding add of ODT into calibre. With menu command Format/Anchor/To Paragraph. All I had to do was look.

I'm also tending toward always bulk converting after adding books, for all books. For me using EPUB as preferred format, that makes sense for the assessment in calibre viewer. With further assessment of original format if necessary in other reader app for that format.

[mraxehandle]

I still don't understand why so many people use forums as a kind of wiki (I think of XDA in particular.) It seems strange to me, given how many great wiki-type tools are out there.Does MobileRead or Calibre have a wiki space that can be used?

[unboggling]

Originally Posted by mraxehandle

I still don't understand why so many people use forums as a kind of wiki (I think of XDA in particular.) It seems strange to me, given how many great wiki-type tools are out there.Does MobileRead or Calibre have a wiki space that can be used?

Welcome to MobileRead Forums.

MobileRead Wiki Main Page, links to ebooks, libraries, stores, and information on devices, readers, tools, and formats.

There is a calibre article on MobileRead wiki. AFAIK nothing prevents there being other calibre wiki pages with different focus or content.

These are some reasons this document is here:

1. It is still under development, being added to and refined, with rapid revisions.
2. Feedback spurs that along.
3. I want to keep control of the edits. AFAIK, any registered user can edit a wiki article. I might be wrong because I never contributed to a wiki before, and don't know specifics of that process.
4. The focus, as currently written and structured, is on how "I" manage ebooks with calibre, my needs, strategy, workflow, configs, and settings and how they interrelate. Not necessarily on how other people manage ebooks with calibre, which is usually different for each person. (General discussion of what other users do is mostly for context or contrast. Any discussion of methods to choose from is usually for context or contrast, and/or workflow contingencies.)
5. I suspect most of the people reading this in a calibre forum are more calibre-focused than a broader group reading it as a wiki article.

If I'm wrong about anything in that reasoning, anybody, please let me know.