Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Page order are not correct while reading epub files (only contain imgaes) #788

Open
yihuasteven opened this issue Apr 1, 2023 · 5 comments
Labels
[BIG SHOT] feature aw heck that's a lotta work chief enhancement reader

Comments

@yihuasteven
Copy link

yihuasteven commented Apr 1, 2023

hol up senpai have you checked out the GH Discussions first ?
Your issue/idea might've already been reported by someone else! πŸ±β€πŸ‘€
https://github.com/Difegue/LANraragi/discussions
YES

LRR Version and OS
Docker, Version 0.8.7

Bug Details
First of all, lrr is the comic server I like most.

I have many digital comicbooks in epub format which only contain images. While reading in lanraragi, the page order are not correctly arranged, but the the same epub file page order could be arranged in correct order in some other readers. (Tested in pc & android software like neat reader, calibri, comic server like komga)

Finally I found the problem is the image file name. If the images in the epub file were all named in order, it would be arranged correctly in lanraragi. However, if the images in epub were named randomly, the paper order in lrr would be wrong. I know little about the principle, I guess in epub file there would be a index file to link the page numbers and the image names. I'll show it by some screenshots.

The only methond I have found to solve it is to convert them into pdf files, but this takes much time to do so, and not all the epub files are convertable.

Matching Logs
Post any logs you have encountered when reproducing the bug.
If possible, switch the app to Debug Mode in order to have more logs.

Screenshots
In this file, the images are named in order. In llr, the page order is corret, either.
index and image name are in order
correct order in llr

In this file, the images are named randomly, in other softwares, the page order is correct, but in llr, the page order is wrong.
index and image file name viewed in calibri
not correct

@Difegue
Copy link
Owner

Difegue commented Apr 1, 2023

Thank you for the report - Would you happen to be able to share a small epub file that exhibits the problem so I can try it out?

I suspect we should look at the content.opf file when building the image list for epubs instead of just sorting by image name like we do with everything else.

@yihuasteven
Copy link
Author

yihuasteven commented Apr 2, 2023 via email

@Difegue
Copy link
Owner

Difegue commented Apr 12, 2023

@yihuasteven Sorry for the delay -- unfortunately you will need to upload the epub directly in this issue, attaching them via email does not work. Thanks!

@yihuasteven
Copy link
Author

@yihuasteven Sorry for the delay -- unfortunately you will need to upload the epub directly in this issue, attaching them via email does not work. Thanks!

No problem, here is the equb file. Thanks.
SP-ABC.zip

@Difegue
Copy link
Owner

Difegue commented Apr 28, 2023

Had some time so I took a deeper look in the epub spec:

Annoyingly so, we can't just look at content.opf, since that name is not fixed in the spec and can be anything (it's vol.opf in the epub linked above, for example).

Instead, we have to first look at META-INF/container.xml to know the location of the OPF file:

<?xml version="1.0" encoding="UTF-8" ?>
<container version="1.0" xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
    <rootfiles> 
       <rootfile full-path="vol.opf" media-type="application/oebps-package+xml" />
    </rootfiles>
</container>

Then we can open and parse the OPF file to get the image order:

<?xml version="1.0" encoding="UTF-8" ?>
<package version="2.0" unique-identifier="MOXBID" xmlns="http://www.idpf.org/2007/opf">
  <metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
    [...]
  </metadata>
  <manifest>
    <item id="ncx" href="xml/vol.ncx" media-type="application/x-dtbncx+xml"/>

    <item id="Page_1" href="html/1.html" media-type="application/xhtml+xml"/> 
    <item id="Page_2" href="html/2.html" media-type="application/xhtml+xml"/> 
    <item id="Page_3" href="html/3.html" media-type="application/xhtml+xml"/> 
    <item id="Page_4" href="html/4.html" media-type="application/xhtml+xml"/> 
    <item id="Page_5" href="html/5.html" media-type="application/xhtml+xml"/> 
    <item id="Page_6" href="html/6.html" media-type="application/xhtml+xml"/> 
    <item id="Page_7" href="html/7.html" media-type="application/xhtml+xml"/> 
    <item id="Page_8" href="html/8.html" media-type="application/xhtml+xml"/> 
    <item id="Page_9" href="html/9.html" media-type="application/xhtml+xml"/> 
    <item id="Page_10" href="html/10.html" media-type="application/xhtml+xml"/> 
    <item id="Page_11" href="html/11.html" media-type="application/xhtml+xml"/> 
    <item id="Page_12" href="html/12.html" media-type="application/xhtml+xml"/> 
    <item id="Page_createby"  href="html/createby.html" media-type="application/xhtml+xml"/> 
    <item id="Page_cover"     href="html/cover.jpg.html" media-type="application/xhtml+xml"/>

    <item id="cover_img" href="image/cover.jpg" media-type="image/jpeg" properties="cover-image" />

    <item id="img_1" href="image/vol-000458.jpg" media-type="image/jpeg"/> 
    <item id="img_2" href="image/vol-008535.jpg" media-type="image/jpeg"/> 
    <item id="img_3" href="image/vol-004233.jpg" media-type="image/jpeg"/> 
    <item id="img_4" href="image/vol-007116.jpg" media-type="image/jpeg"/> 
    <item id="img_5" href="image/vol-008993.jpg" media-type="image/jpeg"/> 
    <item id="img_6" href="image/vol-007881.jpg" media-type="image/jpeg"/> 
    <item id="img_7" href="image/vol-000962.jpg" media-type="image/jpeg"/> 
    <item id="img_8" href="image/vol-008719.jpg" media-type="image/jpeg"/> 
    <item id="img_9" href="image/vol-008906.jpg" media-type="image/jpeg"/> 
    <item id="img_10" href="image/vol-004248.jpg" media-type="image/jpeg"/> 
    <item id="img_11" href="image/vol-003600.jpg" media-type="image/jpeg"/> 
    <item id="img_12" href="image/vol-005270.jpg" media-type="image/jpeg"/> 
    <item id="img_createby" href="image/createby.png" media-type="image/png"/>
    <item id="css" href="css/style.css" media-type="text/css"/>
    <item id="font01" href="misc/Courier.ttf" media-type="application/x-font-ttf"/>
  </manifest>
  <spine toc="ncx">
    <itemref idref="Page_cover" />

    <itemref idref="Page_1" /> 
    <itemref idref="Page_2" /> 
    <itemref idref="Page_3" /> 
    <itemref idref="Page_4" /> 
    <itemref idref="Page_5" /> 
    <itemref idref="Page_6" /> 
    <itemref idref="Page_7" /> 
    <itemref idref="Page_8" /> 
    <itemref idref="Page_9" /> 
    <itemref idref="Page_10" /> 
    <itemref idref="Page_11" /> 
    <itemref idref="Page_12" /> 
    <itemref idref="Page_createby" /> 
  </spine>
  <guide>
      <reference type="cover" href="image/cover.jpg" title="封青" />
  </guide>
</package>

Turns out that the OPF file itself doesn't contain the order of the images either, just the list of the images -- The actual order needs to be figured out by parsing the html files..

In this epub, the first image in the OPF file is image/vol-000458.jpg, but opening 1.html shows it's actually image/vol-007881.jpg. (what kind of madman does this i stg)

So basically, in order to have perfect image order support for epub, you need to implement the epub spec in full.

I'm going to put this in volunteers welcome, but I think it'd be quite an ordeal...
An EPUB Parser perl library could help here. (Alternatively, we could just use an epub reader javascript library in the front-end but that'd require a bunch of custom code as well)

In the meantime @yihuasteven, what I can recommend would be to use an OPDS Client alongside your LRR server (with page streaming turned off) - Most OPDS clients are designed for EPUBs and will download and parse the full file themselves.

@Difegue Difegue added this to the Volunteers welcome milestone Apr 28, 2023
@Difegue Difegue added enhancement [BIG SHOT] feature aw heck that's a lotta work chief and removed bug labels Apr 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[BIG SHOT] feature aw heck that's a lotta work chief enhancement reader
Projects
None yet
Development

No branches or pull requests

2 participants