-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[Feature] Support DjVu metadata #4314
Conversation
Awesome, I've been meaning to look into this but never got around to it! I'll have some time to review it tonight. |
This implements the getMetadata() function for DjVu documents, following in the style of the same for the PDF implementation. This just dumbly copies all the metadata key-value pairs into a lua table. The intent is to give the frontend everything we possibly can and let it figure out what to do with the info, an example of which can be found in the companion pull request koreader/koreader#4314.
2b74203
to
d5c5844
Compare
Is there something left to do in this PR? This is really cool feature to have. And BTW how often nightly builds are triggered? |
Yes, base still needs to be bumped. So it'll actually work. :-) Nightlies are triggered every day around 6 CET. |
@Frenzie Thanks for merging base. This PR should be all working now! |
It has been (a few minutes after you merged base PR). |
You guys work quick! Thanks! |
Thanks for caring about DjVu! ;-) |
Overview
As of f71627c, DjVu support for metadata is faked by setting the document tite to the file's basename. This is fixes that. It is the frontend companion to koreader/koreader-base#753, as such the continuous integration will inevitably fail until base integrates those changes.
If there's a better protocol for this kind of split pull request, please let me know.
Notes
This is my first foray into koreader's codebase as well as lua programming, so please forgive any boneheadeness. I tried to model the
DjvuDocument:getProps()
method after its namesake infrontend/document/pdfdocument.lua
.The silliness with capitalized keys versus lowercase, as mentioned in the code comment, comes from the covention mentioned in djvused(1). I considered
lower()
ing allprops
keys into a new table, but I figured that, with just six keys, it's best to be explicit about the identifications.Anyway, if I've made obvious mistakes or there is a better way to do things, please let me know. I hope this turns out to be useful.