Calibre on RISC OS

Would it be possible for ‘Calibre’ (ebook reader/converter) be made to run on RISC OS?

Thanks

Epub is XML, a simplified kind of XHTML. Someone could possibly cobble something together with the GCC shared libs?

Calibre is more than an EPub reader. It combines an EBook database, a viewer (for many formats), an editor for metadata and tools for connecting with various EPub readers. It’s very complicated, to the point that the author discourages compiling the sources due to various dependencies.
Also don’t forget that EPub is only one of EBook formats. There is LIT, Azw (amazon proprietary?), mobi and PDF. Also CBR and CBZ but I bet you know these (manga). And the nightmare of Adobe Digital Editions…
If someone manages to create/port an EPub reader IMHO this is an area where RO could make the difference. All physical Ereaders that I know are somehow Linux-based and very slow to use.

Calibre is more than an EPub reader.

Oh, I know. My P4 box struggles to run it when I convert older style Kindle books to epub to use on my (non Kindle) reader.

There’s a reader for various formats, FBreader or something? Perhaps better to start with a reader than a fully blown editor?

Physical readers are slow because they do dumb things like apply bottlenecks in weird places. The “ROM” in my one is a glued in SD card. Easy to implement, but no doubt dead slow.

Chris Gransden ported MuView, a PDF/ebook reader that (whilst a bit basic) is quite useful and accurate. I know Richard now uses it in preference to !PDF for PDF handling.

Chris Gransden ported MuView

I’m having no luck getting that to work. It keeps saying “can’t load library ‘libjpeg.so.62’”.

In SharedLib’s abi-2/0 are the files libjpeg/so, libjpeg/so/8, and libjpeg/s0/8/4/0. The first two are symlinks pointing to the last one.
In abi-2/0.vfp is the file libjpeg/so/62/2/0.

I tried creating a symlink libjpeg/so/62 within VFP, but this doesn’t help.

I also tried copying the two VFP versions into the abi-2/0 directory.

So… I’m all out of ideas. Can anybody help?

[may I suggest a command such as “*SOCat” to get SOManager to list all the libraries that it can see, so that missing things might be spotted, if that is the case?]

so that missing things might be spotted

I Think you already have the information you need. Did you doubleClick on !SharedLibs after dropping in the new lib(s)
If so I think the error means it hasn’t found a libjpeg.so.62
Probably doesn’t check into the library much for correctness initially.
My next step would be to try copying or renaming the actual library to libjpeg/so/62
You could have copies of the library with the usual symlink names and it should still work.
It does sound like there has been a naming error at build time though, the vfp directory works OK on my pizero (last week.)
A text search for lib inside the executable will show the libnames it is interested in, should be dots not slashes in there.
Then there is readelf and objdump.

Did you doubleClick on !SharedLibs after dropping in the new lib(s)

I killed SOManager and then doubleclicked on SharedLibs…

so I think the error means it hasn’t found a libjpeg.so.62

That is what it says… I’m just a bit clueless as to how it actually looks for things and why it can’t seem to find what appears to be there.

My next step would be to try copying or renaming the actual library to libjpeg/so/62

Yup – copying seems like a reasonable suggestion. I’ll try that when I next “do stuff” at the computer. It’s Christmas here now, so time to hit the sack…

Copying libjpeg/so/62/2/0 as libjpeg/so/62 works here.

!MuView can read an epub, “My Man Jeeves”.

One step forward, one step back. Copying the file as suggested gets MuView to load and install on the iconbar.

Doing anything with it triggers cascading errors that bring down the entire desktop.

What machine are you using David? Mine’s an ARMv7 (original) Pi2.

Copying libjpeg/so/62/2/0 as libjpeg/so/62 works here.

You already know that it would now be OK to have a /working/ symlink named libjpeg/so/62 instead of duplicating the library.
Copying the library initially does remove the possibility of a symlink error complicating things.
There is only a few bytes involved, using a working symlink as a guide, you can make one in a byte/dump mode.
Otherwise it would be the !GCC ln cmd for the job.

I think the (inherited linux) story goes that one symlink is used for compiling the other for running.
Most the output from Autobuilder will use a symlink system, it would be possible to build with just the library name and no symlinks. I guess you would still want the version information tagged on though.
Edit: Actually the symlink for building would allow any makefile symlink reference to stay the same in case of upgrading the target library version.

What machine are you using David? Mine’s an ARMv7 (original) Pi2.

Titanium. It also works on the RPi3B+. SharedLibs is RPi3 compatible, the same version is used on both machines.

A copy of my full SharedLibs has been uploaded to my pCloud space It’s big 57MB and I don’t think the pCloud shared link is NetSurf compatible.

It’s a bit poke and hope we are assuming that libjpeg/so/62/2/0 == libjpeg/so/62, it might not be completely so. Anyway, works here, FWIW.

P.S. I have just tried on the RPi1 and it works there also.

P.P.S. In this application the Titanium has noticeable lead over the Pi’s.

When I helped Richard (who uses it has his main PDF viewer on his ARMX6) get MuView running, all we did was copy the shared lib as described here. For my own use, I copied another symlink and edited it in StrongEd.

You probably need the VFP SharedLibs files from OtterBrowser/OBrowser as a starting point, as Chris did both ports and this is in the VFP section. I know that both Richard and I had those browsers working before we tried MuView. You can find the latest VFP sharedlibs in the Otter thread in the “Announce” forum. Or use the version on the OBrowser CD etc.

MuView is surprisingly quick, actually, given its size. It mainly suffers from lack of UI development – I’d love to see Chris (or someone) develop it further, but I get the impression that Chris is a pretty busy chap.

I copied another symlink and edited it in StrongEd.

I have done that here now, after I had worked out that byte 4 is the length of the target library filename.

*SOMStatus shows libraries in use.