Multi-reply
Quote:
Originally Posted by Redshifter
I can't get animated GIFs from Archive of Our Own to load into EPUB format. They show as still images. Is there some specific setting I'm supposed to setup? Thanks for all the help you provide.
|
By default, FFF automatically resizes images if they are bigger than a configurable size which (probably) breaks animated gifs.
Set
no_image_processing:true in personal.ini under an appropriate section (
[defaults] for every story,
[archiveofourown.org] for every AO3 story, or
[<storyUrl>] for individual stories) to get the image exactly as on the web site.
The other suggestions given before may also be true.
Quote:
Originally Posted by baba_marta
1. Regarding empty <p> tags on AO3 (and probably other sites):
On the one hand, these are used by authors as section breaks. On the other hand, they're often just messy HTML and result in space lines where none should be, i.e. after every single paragraph. keep_empty_tags will deal with the latter but also break the former. I saw that this topic had been discussed on Github in a now closed thread.
Could a kind of optional restriction for keep_empty_tags be a solution? Something along the lines of: If an empty tag occurs more than x times per chapter, remove it. Otherwise keep it, as it's likely a legitimate section marker. |
Similar to the
replace_br_with_p feature (which uses some heuristics to find and replace br paragraphs with p tags while preserving scene breaks), I will accept contributed code (ideally as a github PR & FFF needs to be py2/py3 compatible still) for such a feature. But I'm not interested in implementing that myself.
I would suggest instead of a simple x times per chapter it should take into account chapter length. x breaks per word count or even char count. I routinely see chapter lengths from 300-30,000+ words.
Quote:
Originally Posted by baba_marta
2. Another HTML issue on AO3 that's caused by their own text importer and is often overlooked by authors:
<em> tags are sometimes split off into newlines with a whole lot of whitespace around them. The "frontend" result is faulty-looking punctuation, i.e. spaces where none should be, either before or after the italicised text in question.
I hope I'm making sense here -- it's essentially something like this: \n\s*<em>\n\s* or \n\s*<\/em>\n\s* resulting in: " Text." or "Text ."
Is there any way to find and fix this directly using regex? The only option I've found is replace_metadata, which comes close but (probably?) doesn't look at chapter content.
|
I believe I've looked into that before. As I recall, trying to apply something like that introduced as many problems as it fixed, removing spaces that should be there.
FYI, it is a deliberate design decision that FFF does
not offer generalize automated editing of story text. I judge it too likely that people will damage their text--a single mistake could easily result in no output at all. Or arguably worse, remove text while looking correct to a cursory inspection.
Plus testing it would involved downloading over and over again, stressing our favorites sites.
Quote:
Originally Posted by baba_marta
3. I'm a bit of a neurotic minimalist when it comes to opfs. I take it that what's included in them is hardcoded? I haven't been successful in adjusting any of it without going directly into writer_epub.py and commenting out what I don't need -- inelegant, this, so maybe there's a better solution.  |
The content.opf file of the epub? That 99.99% of users never see and is entirely intended to be machine readable metadata?
Aside from what <dc:subject> tags to include (see setting
include_subject_tags), it is not configurable as such. Metadata that doesn't exist for a particular story generally isn't included.
If you have cases of the contents of FFF's generated content.opf causing actual problems with an epub reader, I'd like to hear about it. But I'm not interested in changing it for reasons of personal aesthetics.