Remove extr.c? about koreader-base HOT 5 OPEN

The two pieces of code: extr.c and pdfattach complement each other and were written for the purpose of working around Amazon's limitation of rejecting non-PDF/mobi files from submission to their cloud storage accessible directly from Kindle device. Namely, one would take a DjVu (or mp3 or whatever) and use pdfattach to attach it (multiple files supported) to a PDF file. Then he would send this PDF to Amazon Cloud and access it from Kindle. Then, using kindlepdfviewer, he would extract those files which are needed and view them. This is the whole purpose of it.

The pdfattach utility is quite simple (almost trivial), but extr.c is, imho, a nice illustration how to access PDF objects directly (using mupdf) and autonomously. IMHO, it should be removed after such "attachment API" is actually implemented in Koreader, not before.

PS. I assume you meant kindlepdfviewer when you wrote kindlevncviewer as this has nothing to do with VNC.

from koreader-base.

Yes, of course I meant KPV. OK, I agree. We should have the API for accessing attachments - since that is a useful feature in any case, I guess. I'm not sure if we should actively promote the Amazon Cloud storage, errm, feature, but that's a different issue.

from koreader-base.

Btw, in case someone looks at the actual source code of extr.c I should mention that the obvious memory leak in the function save_attachments() is intentional (strdup(3) is called, but no free(3)), because this is an utility designed to be executed and exited, thus destroying its address space on termination. There is no free(3) for strdup(3) because it would slow down the program unnecessarily. But if the function is copied "as is" inside a long-lived program like koreader then the memory leak should be fixed first, obviously. Otherwise on each save attachment operation it would leak a tiny bit of memory.

from koreader-base.

I' m not sure if extr.c can still be compiled with Mupdf 1.5. It hasn't been compiled since Mupdf 1.4.

from koreader-base.

It uses the standard pdf_load_page()/pdf_open_stream()/pdf_dict_gets() interface that is unlikely to change in a million years, let alone in a minor revision upgrade from 1.4 to 1.5. Having said that, I haven't checked whether it still compiles or not.

Now, if you really must remove these two utilities, please go ahead and do it. I have created a separate repository here:

https://github.com/tigran123/pdf-attach-extract

So if you need them in the future to refer to when writing attachment display/extraction API in koreader you can always refer to the above repository.

from koreader-base.