suggestions for epub library? about kindlepdfviewer

[hwhw]

I think it doesn't render. It is an approach to parse the structure, but when it comes to Hypertext support, we'd want a good rendering backend.

I'm not entirely sure if this really fits in this reader. Then, of course, it would be nice. But that will probably mean to use something like Webkit anyway. This might be a job for coolreader for now. Well, I'm not sure.

PS: What I've thought about before was to integrate a EPUB to PDF conversion step. I'm still dreaming of a (Xe-)TeX based rendering, which would also be typeset very neatly. But then I haven't found tools for the EPUB to TeX step either.

[hwhw]

Well, since I was mentioning Coolreader: its CREngine supports EPub... It's C++, so it will be slightly more complicated to integrate, but that might even work. It wouldn't add major new dependencies and it does the rendering on its own... I think it would be a good fit. But maybe we should slow down a bit :-)

[houqp]

Oops, I forget that it does not render. You are right, CREngine is a better alternative.

Yes, we should slow down, djvu support is not complete yet. I am just in curious :)

[houqp]

I just went through CREngine's API, and wanna give it a try ;P

[hwhw]

More than welcome, of course. I'm going to be quite busy with other things during this week, I hope to get back coding on kindlepdfviewer next weekend.

[houqp]

Should I write Lua module directly in C++ or write a C compatible CREngine wrapper first?

[hwhw]

Whatever fits best, I think. As long as it renders to BlitBuffer compatible data, it will interoperate with the rest. Another layer of abstraction would not gain a lot, I think. So C++ would be fine. And there's already C++ code that we depend on. Maybe, at some point in the future, we can modulize everything a bit so that one could e.g. chose to use only some dedicated part of the software.

It might make sense at some point to switch from compiling those Lua libraries into a single executable to build dynamic libraries that can be "require"d from a generic Lua interpreter. I started with the link-everything approach when the app only consisted of one executable plus one Lua file :-) Now, we're far beyond that point. And I'd really like to factor out the inclusion of fonts and CMaps and rather want them to be external resources. Unfortunately, this would require a small patch to the muPDF build. Maybe they'll accept it upstream. Anyway, this isn't due until a few weeks from now, I think.

[houqp]

Whatever fits best, I think. As long as it renders to BlitBuffer compatible data, it will interoperate with the rest. Another layer of abstraction would not gain a lot, I think. So C++ would be fine. And there's already C++ code that we depend on. Maybe, at some point in the future, we can modulize everything a bit so that one could e.g. chose to use only some dedicated part of the software.

Modularization looks good :)

OK, then I will try using C++ module first (Haven't touched C++ codes for one years ;P). I just coded a ugly working demo and will clean it up tommorow.

And I'd really like to factor out the inclusion of fonts and CMaps and rather want them to be external resources. Unfortunately, this would require a small patch to the muPDF build. Maybe they'll accept it upstream. Anyway, this isn't due until a few weeks from now, I think.

It seems that CREngine is not able to make use of the built-in font from MuPDF, either I have to patch it or I might missed something. It will be better if these fonts are external resources.

[dpavlin]

Argh. I thought it will include relevant comment and not only pull request pointer.

It's segfaults on start. I'm missing fonts, which should be in ./fonts if I'm not mistaken. Where do I get them?

[houqp]

damn it, I also replied to #81. :p

Yes, you need to put fonts in ./fonts directory.

[dpavlin]

I'm probably compiling it wrong:

Program received signal SIGSEGV, Segmentation fault.
0x0868a1b5 in UnicodeToUtf8(lString16 const&) ()
(gdb) bt
#0  0x0868a1b5 in UnicodeToUtf8(lString16 const&) ()
#1  0x086fb80c in LVDocView::propsUpdateDefaults(LVFastRef<CRPropAccessor>) ()
#2  0x0870ee49 in LVDocView::LVDocView(int) ()
#3  0x0868212e in openDocument (L=0x89ea058) at cre.cpp:46
#4  0x0856853e in luaD_precall (L=0x89ea058, func=<optimized out>, nresults=-1) at ldo.c:319
#5  0x08568a58 in luaD_call (L=0x89ea058, func=0x8a7a2f8, nResults=-1) at ldo.c:376
#6  0x08564b20 in f_call (L=0x89ea058, ud=0xbfffeb98) at lapi.c:800
#7  0x08567ce2 in luaD_rawrunprotected (L=0x89ea058, f=0x8564b00 <f_call>, ud=0xbfffeb98) at ldo.c:116
#8  0x08568db8 in luaD_pcall (L=0x89ea058, func=0x8564b00 <f_call>, u=0xbfffeb98, old_top=600, ef=0) at ldo.c:463
#9  0x08565f72 in lua_pcall (L=0x89ea058, nargs=4, nresults=-1, errfunc=0) at lapi.c:821
#10 0x0857badf in luaB_pcall (L=0x89ea058) at lbaselib.c:377
#11 0x0856853e in luaD_precall (L=0x89ea058, func=<optimized out>, nresults=2) at ldo.c:319
#12 0x08574745 in luaV_execute (L=0x89ea058, nexeccalls=5) at lvm.c:587
#13 0x08568aa8 in luaD_call (L=0x89ea058, func=0x89ea334, nResults=-1) at ldo.c:377
#14 0x08564b20 in f_call (L=0x89ea058, ud=0xbfffee48) at lapi.c:800
#15 0x08567ce2 in luaD_rawrunprotected (L=0x89ea058, f=0x8564b00 <f_call>, ud=0xbfffee48) at ldo.c:116
#16 0x08568db8 in luaD_pcall (L=0x89ea058, func=0x8564b00 <f_call>, u=0xbfffee48, old_top=180, ef=0) at ldo.c:463
#17 0x08565f72 in lua_pcall (L=0x89ea058, nargs=0, nresults=-1, errfunc=0) at lapi.c:821
#18 0x0804e987 in main (argc=5, argv=0xbfffef34) at kpdfview.c:72

Do you have any special tweaks for building epub branch other than things commited?

[houqp]

um... I think there is no special tweaks...

Could you set the DEBUG_CRENGINE macro in cre.cpp and run it again? It dumps more information. CREngine does not check NULL pointers in many places and often causes segfault in unexpected places.

Also make sure that required css files are put in data directory.

[houqp]

Closing this for now, follow up discussion about CREngine should go into #77.