Mobileread
How I Manage eBooks with calibre
#1  unboggling 07-19-2012, 04:11 PM
Post deleted.
Reply 

#2  unboggling 07-19-2012, 04:15 PM
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.
Reply 

#3  PeterT 07-19-2012, 04:45 PM
@Unboggling; any thought into putting this into an alternate format, maybe (oh horrors) an ePub?
Reply 

#4  unboggling 07-19-2012, 05:00 PM
Quote 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.
Reply 

#5  unboggling 07-21-2012, 09:12 PM
Quote 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.
Reply 

#6  unboggling 08-13-2012, 05:35 PM
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: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.
Reply 

#7  brainvision 08-30-2012, 03:34 PM
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!!
Reply 

#8  unboggling 08-30-2012, 04:23 PM
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.
Reply 

#9  travger 09-01-2012, 11:07 PM
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?
Reply 

#10  unboggling 09-02-2012, 05:02 AM
Quote 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.
Reply 

  Next »  Last »  (1/12)
Today's Posts | Search this Thread | Login | Register