calibre: most desired feature, pony up for Kovid

[wallcraft]

Originally Posted by pilotbob

I think ePub to LRF and ePub to Mobi would be the most needed tools.

Add ePub to eReader and all the common ebook readers (except MS Reader) would be supported. It is likely that MobiPocket and FictionWise will support ePub as input to their publishing tools, so only epub2lrf is essential in the short term.

[llasram]

Originally Posted by pilotbob

I think ePub to LRF and ePub to Mobi would be the most needed tools.

$ epub2lrf --version
epub2lrf (calibre 0.4.72)

I'm not sure if Kovid/anyone else has filed the rough edges (cover, TOC support) off the version I contributed, but epub -> LRF is definitely there.

[kovidgoyal]

Yeah epub2lrf is there thanks to llasram. It might need some polishing, but that will happen automatically when people start using it and submit bug reports.

epub2mobi would depend on html2mobi. I'm going to wait a bit on that and see if mobipocket release a cross platform mobigen, in which case I dont have to write it.

[jotheman]

Dear Kovid,

as a non-programmer I am a little worried about the "command line based" part of your description. Will people like me (not really familiar with terminal and/or python commands) be able to take advantage of this feature or will we have to wait until it's integrated into the GUI? I can't imagine myself executing command line code on a regular basis...


jo.

[kovidgoyal]

Because of the design of calibre, once the command line utilities are available, adding support to the GUI is just a matter of a few hours of work. I will however put off adding that support until html2epub is debugged a bit.

[User Name]

Originally Posted by simond

The main problem I can see is the very frequent updates

To be seen...
If it's just a matter of replacing files, I don't see a problem there.

Anyway... I started putting some effort into it. The good thing so far:
- All required packages are available
- I was able to install it up to this point:
Installed /[...]/lib/python2.5/site-packages/calibre-0.4.72-py2.5.egg
Processing dependencies for calibre
Finished processing dependencies for calibre
into a local copy of the python tree, which also allows for checking which files are installed where (crucial for a clean de-installation procedure)

The bad:
- Some package versions are a bit off, e.g. pyqt is at 4.3.something, whereas the requirements are asking for 4.4.whatever. Other packages are more recent than stated in the requirements. Whereas I don't expect any issues from the latter, I do expect problems from the former.
- Symlinking stuff into /usr/bin isn't a good idea in my opinion. I don't know if that's the common way to do it on Linux, but on FreeBSD I'd rather expect symlinks into /usr/local/bin, if at all.
- I still have to run the postinstall and I haven't tried starting the software yet, either. I'll do that as soon as I'm in front of the machine again.

The ugly:
- Putting it into a ports-compatible form. I'm afraid I don't have enough time for this.

It's a pity that there's no way to set it up as a self-contained installation without causing too many problems in other areas.

[User Name]

Originally Posted by User Name

- I still have to run the postinstall and I haven't tried starting the software yet, either. I'll do that as soon as I'm in front of the machine again.

[~/work/calibre]: calibre_postinstall
You must be root to run this command.

*sigh*
Why on earth? I'm using a local copy of python in ${HOME}/lib/python2.5. There's absolutely no need to run something as root.

[kovidgoyal]

That's because it needs to install system files (udev rules and HAL FDI files) for device detection. Have you looked at the binary installer? It creates a single directory installation (and a few small bash scripts in /usr/bin).

[User Name]

Originally Posted by kovidgoyal

That's because it needs to install system files (udev rules and HAL FDI files) for device detection.

Is it possible to skip this step and run it manually later on? I'd like to track down every change to the system so I can set up a proper uninstall procedure which can be used when putting it into the ports mechanism.
Besides that, udev is a Linuxism as far as I know. FreeBSD has its own dynamic devfs implementation.

Originally Posted by kovidgoyal

Have you looked at the binary installer? It creates a single directory installation (and a few small bash scripts in /usr/bin).

Not yet, but thanks for the hint. I already saw the /usr/bin stuff, though (as mentioned before).

[kovidgoyal]

You can pass options to calibre_postinstall to disable any stage of the process.

Usage: calibre_postinstall [options]

Options:
  -h, --help            show this help message and exit
  --use-destdir         If set, respect the environment variable DESTDIR when
                        installing files
  --do-not-reload-udev-hal
                        If set, do not try to reload udev rules and HAL FDI
                        files
  --group-file=GROUP_FILE
                        File from which to read group information. Default:
                        /etc/group
  --dont-check-root     If set, do not check if we are root.
  --make-errors-fatal   If set die on errors.

[llasram]

If the Reader's .epub support is crippled in some way (only supported with a yet-to-be-released PRS model, only supported with DRM, buggy renderer, etc.), then implement a fully CSS-aware HTML -> LRF layer using cssutils or other full CSS parser.

[User Name]

Originally Posted by kovidgoyal

You can pass options to calibre_postinstall to disable any stage of the process.

Usage: calibre_postinstall [options]

Options:
  -h, --help            show this help message and exit
  --use-destdir         If set, respect the environment variable DESTDIR when
                        installing files
  --do-not-reload-udev-hal
                        If set, do not try to reload udev rules and HAL FDI
                        files
  --group-file=GROUP_FILE
                        File from which to read group information. Default:
                        /etc/group
  --dont-check-root     If set, do not check if we are root.
  --make-errors-fatal   If set die on errors.

Thanks and sorry for the late answer. I'm currently busy with some other projects which unfortunately have to be finished first. I'll take a closer look as soon as time allows it.

[jotheman]

Hi Kovid,

now that I am the proud owner of a fully chinese-enabled PRS500, I finally had the chance to really try out library management with Calibre. Most important finding:

There is nor real sync-feature. I can send books to the reader, but when I delete them, they will still stay in the reader's memory, so I have to delete them twice; changes in metadata are not automatically synced, etc.
=> having syncable playlists (or collections, or series, or whatever) would be really helpful to stay organized.
Maybe on could add a default setting for any book to be synced to internal memory/SD card automatically, e.g. whenever something changes.

As you might have guessed from all my previous questions and suggestions, I read a lot of short, read-and-delete news articles, mostly created with BookIt. It is really difficult to stay organized without the possibilty to delte files directly on the device and without automatic syncing, e.g. like an iPod does with iTunes. I cannot delete files on my iPod either, so I have smart playlists to find the podcasts I've already listend to, so that I know which ones I can delete. I wish there was a similar way to keep my PRS500 tidied up with Calibre.

For now I reverted to a ChronoSync action for my news files, so they won't clog up my Calibre library (twice). But I have to remember which articles I've already read and then delete them from my HDD, the deletion will then be synced with my SD card the next time it is connected to my Mac. Not a perfect solution either. Why does everything have to be so complicated? ...

Cheers,


jo.

[kovidgoyal]

The problem is that there isn't a reliable enough mechanism on the PRS500 to achieve true syncing. This is primarily because the 500 has no internal clock and times drift. So there's no reliable way of knowing when something is newer.

[HarryT]

Originally Posted by kovidgoyal

The problem is that there isn't a reliable enough mechanism on the PRS500 to achieve true syncing. This is primarily because the 500 has no internal clock and times drift. So there's no reliable way of knowing when something is newer.

I guess that one way to do it would be to record the timestamp on the external file system in your database, and recopy the file to the Reader if it had changed to a later time.