LNReader
Better export to epub
I finally found the time to work a bit on the library and implemented it in LNReader with a few changes for better compatibility.
- changed lineheight and textsize to be rem based instead of px
- changed epub text to be wrapped in div with id chapter instead of a chapter element, since the epub standard doesn't accept custom elements.
- added to id chapter to the readerscreen chapter element.
This PR closes:
- #861
- #797
- #777
- #696
- #745
- works as expected
- shouldn't be viewed in the first place
- prevents filename duplications
- #740
- not app/library related
Why should we export reader ui to epub?
Where do I export the reader ui?
` + (css as string).replace(/chapter/g, '#chapter')
Btw, you could use implemented FileManager.pickerFolder to pick a folder with resolved path.
Bug report: The numeration of xhtml files is based on the sort order set on the novel entry. Force it as ascending.
How to reproduce: -pick an entry, download 10 chapters, set chapter list to descending order, export, check chapter files
Feature request:
Make chapter file numbering start from chapter 1
The majority of webnovels dont have a chapter before chapter 1.
Why? when I edit epubs it gets confusing. Since most webnovels follow perfectly the numbering without derails, maybe it's a better thing.
Feature request: Make chapter file numbering start from chapter 1
Not planed, since only a minority of users will open the epub
F-r Add warning in case the downloaded chapters have hole in between. chapter 1-8 — downloaded chapter 9-16 — NOT downloaded chapter 17-100 — downloaded
It would be nice to know. Not necessary tho. Hole: like in the example above, means undownloaded stuff between two groups of downloaded chapters.
Performance issue: Export speed slower in beta(tested on latest), both 2100+ chapters
beta(2:25):
https://github.com/user-attachments/assets/db111b97-305d-4c40-8c79-b7b35d5fa730
Stable(1:10):
https://github.com/user-attachments/assets/2b7bf3f0-3cff-467e-b223-f71c189e9cc9
Detail: i tested on a beta build that doesnt have the changes of this pr..Commit 7cf8692. It's as fast as stable. I assume this pr modifications are the cause.
Bug
Export failed due to missing images in a chapter. The chapter is downloaded but somehow the images werent, maybe an app bug or the plugin failed to pick them.
-Novelfull 1.0.0, Cultivation chat group, chapter 841
Solution: override or/and make a window appear that says that these chapter failed for some reason
=== EDIT: Also happens when an image is referenced in a html file AND is missing.
Example: I imported an epub. The import process deletes images that are NOT used, so some were deleted. When I tried to export the imported entry, it could not export due to the same error.
Export error:
It comes from an imported EPUB entry.
922k.txt
note: RENAME the extension from .txt to .epub (github doesnt accept epub files)
Import the epub, then try to export it.
Flaw
Directory error after 2 min of exporting:
The problem is that I used a path that was picked in the past, and somehow it disappeared, so it gave the error.
Solution:
-Check the directory avaiability first, to make the error pop up immediately and not waste 2 minutes.
Feature request:
Perma-edit chapters content with customJS upon export.
A way to edit the content of downloaded chapter based on customJS upon export. A little checkbox somewhere here:
Instead of hoping that the epub readers support epub3, Perma-editing is a sure hit. Even Moonreader doesnt support epub3.
Suggestion: Way to inject directly JS or CSS, ignoring the code in customJS and CSS of the app. It's a little cumbersome to go there, paste the code and then come back to the entry to export.
It's more comfortable.
Suggestion: Way to inject directly JS or CSS, ignoring the code in customJS and CSS of the app. It's a little cumbersome to go there, paste the code and then come back to the entry to export.
It's more comfortable.
Why would you want that? What exactly is the use case to have js/css specific only for the epub. Especially when most epub readers don't support it.
Why would you want that? What exactly is the use case to have js/css specific only for the epub. Especially when most epub readers don't support it.
Just more comfortable. Since js can already be included, allow to directly do it from this place, it's just a shortcut:
Also, IF you have the intention of implementing the Perma-edit feature above, the "especially when most epub readers don't support it" wouldnt matter anymore.
Well it won't come with this PR, for now I need to find the time to finish this one.
A perma edit would be the best solution to it, however this would also need a lot of work.
Bug or Flaw: If in the destination folder there is a file with the same name (and extension), the file will be overwritten (forced) by the latest one.
Add a (1) or something like that if that occours. Context: I tried to export a Paged Entry, and then merge with calibre. This bug made me create different folders just to accomodate the exports of each page
Flaw: Export fails, Permission denied because storage permissions have not been given.
- Upon export start, make app.check if storage permissions have been given, IF NOT make a permission request window popup.
At the start, because currently the permission denied appears at the end of the export internal "elaboration".
You might want to add this from my post,
I've finally figured out why some epubs fail and why some chapters will be skipped in an epub reader!
It's all because of the unallowable characters! If the story title has a character like : in it, then the epub will fail to export. You can get past this by simply editing the title with "Edit Info" to remove the characters likely to cause it to fail (almost always punctuation characters, I assume).
Similarly, in the structuring, the epub format does not allow ID's or idref's that include certain characters like quotation marks (in the opf or toc files??) that were derived from the chapter titles (the length of those chapter titles might also matter?); hence, these chapters will be skipped. Please fix, as soon as possible. Thank you for everyone's hard work.
Bug:
tried to export with beta export version:
-tried with ur latest epub export commit:
Of course, same entry
Bug (or Flaw):
-Some special characters in the sumnary should probably be converted to html entities
result:
Used: @#€%-+&()/*"':;!?№$¢₱£¥‰℅—–_·±<[{]>}★„“”«»‚‘’‹›⋮¡¿‽…~\`|•√π÷׶∆\=°^✓™®©⟩⟨♪ωαβΩΠμ§≠∞≈
Resulted epub (rename the extension from .txt to .epub cuz github doesnt allow .epub ti be uploaded here):
Hidden_Marriage.txt
Ps: that same epub when imported on MoonReader simply does not display the epub summary, making it empty
EDIT: after some testing, 3 characters needed to be converted to be accepted by LNReader import and MoonReader Import (summary shows for moonreader now):
•these characters: &, <, and >
Bug
< or > in chapter titles make the export produce a flawed epub (fake html tags).
After the export u can find the flaw like this (toc file):
It's a problem because even MoonReader simply deletes that chapter from the list when imported:
epub:
FFFTier_System_SSSRank_Wife.txt
(rename the file name extension to .epub because github doesn't allow .epub files to be uploaded)
PS: that novel has been taken from NᴏvelFire source (en) PSS: on LNReader, when imported on latest build, it simply renames all the chapter list with chapter0, chapter1, ignoring the toc
Bug
If a chapter has an image, AND also a missing image(so 2 images), upon exporting, the app will fill that missing image with the one that exists, duplicating it.
On website (it's the same on LNReader): https://github.com/user-attachments/assets/eca3e0aa-b1bd-4509-8bef-bb1c625202db
Imported epub (MoonReader):
https://github.com/user-attachments/assets/268f6cde-bb33-4661-a901-1deae054ccd3
Image that exists (1st):
Image that doesnt exist(2nd):
The plugin in question is CentralNovel(portugese), Kono Subarashii(novel), chapter is the 6th (prologue is chapter 1)
PS: I suggest to test on that source now, lest it disappear in the future and become untestable (idk where to find another source with same problem)