Quote:
Originally Posted by Atherton25
Okay, I can download the entire fic...
...
Here is the debug log (inside a spoiler and code) I was going to clean the log up - but I didn't know what you may or may not need, so I left it all:
|
FYI, you're not using the latest test version. Many times it will already have fixes. Too bad it's not that easy this time.
This problem happens because that one story has a weird character (0x000C) that isn't recognized when FFF reads the epub's content.opf file back in. In ASCII, it's a
formfeed AKA page break, so it might be intentional, but it's ignored in browser and inappropriate for a utf8 page.
(I'm using the same python library, xml.dom.minidom, to both convert that string to text to write into the content.opf as I do to read it--why it's okay writing it but not reading it is beyond me.)
I acknowledge that FFF could probably be better able to handle this better. But it's working correctly for many non-English languages and I hesitate to change code that works for correct input to better handle incorrect input. Getting it all working across py2 vs py3 and Calibre vs CLI vs web service is a nightmare of trial and error. If it comes up a lot, I will revisit the issue, but for now, let's talk work arounds.
I was not seeing it in my test library because I had FFF set to generate a cover and the 'Inject/update Cover inside EPUB' setting turned on. We use Calibre's Polish to inject the cover and the polish removed that character. So that's one work around for the problem--any Polish that touches the metadata will clear it.
Another work around is to limit the size of the (truly excessive) description for that story (or the site or in general, depending on [section]) to get down to that character:
Code:
[https://www.royalroad.com/fiction/25870]
description_limit:1000
Sorry I don't have a better fix.