Modify ePub plugin dev thread

[kiwidude]

Originally Posted by jackie_w

On the few epubs I've tested to remove the inline @font-faces, they are correctly removed but a blank line remains.

That was sort of intentional - as a cop-out to making sure I made the least intrusive change to the epub possible. Right now my regex for doing the replacement ends at the closing brace }. i.e.

@font\-face[^}]+?}

I guess the question for the regex gurus is what would be a "safe" addition to that, given the permutations of how styles might be laid out in the original file. Can I get away with this for instance?

@font\-face[^}]+?}\s+

Originally Posted by jackie_w

After modifying an epub, the calibre last_modified date column does not change. Is this deliberate? It may have always worked like this but I never noticed before.

There should be nothing new about that behaviour from previous versions. I'll see if I can figure out what it is supposed to do to get that field updated.

[theducks]

Originally Posted by kiwidude

Finally (to anyone) - I'm thinking of adding an option to the plugin to remove line-height declarations from css files. They cause me nothing but grief - I don't understand why the publisher should dictate that particularly when it just goes badly wrong and text either appears squashed or too spaced out. Usually I manually blitz them in Sigil. I "presume" they have some purpose for some device somewhere, I guess my question is can anyone tell me what that purpose is, and whether they might find such an option useful?

For most cases removal of Line-height is OK. There are places where it would really mess things up (Usually around Dropcaps and images)
Instead of removal: simply comment the line out , leaving the value in place for a quick repair

[jackie_w]

Originally Posted by kiwidude

I guess the question for the regex gurus is what would be a "safe" addition to that, given the permutations of how styles might be laid out in the original file. Can I get away with this for instance?

@font\-face[^}]+?}\s+

I'm not a guru either, but the addition of the \s+ LOOKS harmless. If \s only matches space, tab, newline then it shouldn't remove anything vital

What could possibly go wrong?

Another opinion re: line-height...
I only zap some occurrences (manually, of course), those which affect main body text. I've had problems with long chapter headings if the font is large and the line-height isn't set to 1.3 or higher. Also in agreement about Dropcaps. If the setting isn't 'just right' for your chosen font, it can look terrible. Difficult to achieve a 'perfect' result automatically, I think. I don't suppose most people are this obsessive, though.

[kovidgoyal]

You want \s* not \s+

[kiwidude]

Thx Kovid, good spot.

Re the line-height/dropcaps thing. I've not got a lot of love for dropcaps . Probably because I don't believe my Kindle supports them, and I also don't think that webkit/Sigil or whatever renders them "properly" either. So I personally have no issue of obliterating the "drop" by removing the line height and turning it into a large first letter.

I can appreciate however if you wanted to keep them then fair enough you would not want to run this option. What I had more in mind was some of those really nasty pdf scans into rtf which have hundreds of styles (and certainly nothing as fancy as drop-caps!). Maybe this is the wrong solution for that and I should just stick to Sigil regexes.

[theducks]

Originally Posted by kiwidude

Thx Kovid, good spot.

Re the line-height/dropcaps thing. I've not got a lot of love for dropcaps . Probably because I don't believe my Kindle supports them, and I also don't think that webkit/Sigil or whatever renders them "properly" either. So I personally have no issue of obliterating the "drop" by removing the line height and turning it into a large first letter.

I can appreciate however if you wanted to keep them then fair enough you would not want to run this option. What I had more in mind was some of those really nasty pdf scans into rtf which have hundreds of styles (and certainly nothing as fancy as drop-caps!). Maybe this is the wrong solution for that and I should just stick to Sigil regexes.

Usually there is only 1 dropcap style, so how about this idea:
A user configurable count threshold before removal/disabling

[JSWolf]

Originally Posted by jackie_w

...and I hope kiwidude ignores your request. Why are you constantly banging on about this, insisting that everyone else should want to see covers the way you want them? Surely the idea of using every user's personal calibre default for cover aspect ratio should keep everyone happy.

If you bought a pBook that has the cover looking off, would you be happy with it? eBook, same thing (IMHO).

[JSWolf]

Originally Posted by theducks

For most cases removal of Line-height is OK. There are places where it would really mess things up (Usually around Dropcaps and images)
Instead of removal: simply comment the line out , leaving the value in place for a quick repair

I was going to say something similar but you beat me to it. I have to agree that removing all line height can possibly cause some problems.

[JSWolf]

Originally Posted by kiwidude

Thx Kovid, good spot.

Re the line-height/dropcaps thing. I've not got a lot of love for dropcaps . Probably because I don't believe my Kindle supports them, and I also don't think that webkit/Sigil or whatever renders them "properly" either. So I personally have no issue of obliterating the "drop" by removing the line height and turning it into a large first letter.

Even if you turn a dropcap into a large first letter, you still need a line-height of 0 to keep that first line of the paragraph to not have extra space between it and the second line.

[kiwidude]

Originally Posted by JSWolf

Even if you turn a dropcap into a large first letter, you still need a line-height of 0 to keep that first line of the paragraph to not have extra space between it and the second line.

True. But compared to a first letter which floats in the middle of nowhere I can live with that .

I've dropped the idea as I said above. In an ideal world it would really be a Sigil plugin if it supported such things, that way you could more easily have the fine control if you wanted it.

[jackie_w]

Originally Posted by JSWolf

If you bought a pBook that has the cover looking off, would you be happy with it? eBook, same thing (IMHO).

Well, I'd certainly be unhappy if I bought a pbook with 2 great black (or white) bars down the sides, which is what you're advocating we all should want for our ebooks.

Anyway, we'll never agree on this, let's just leave it

[JSWolf]

Originally Posted by jackie_w

Well, I'd certainly be unhappy if I bought a pbook with 2 great black (or white) bars down the sides, which is what you're advocating we all should want for our ebooks.

Anyway, we'll never agree on this, let's just leave it

But in this case, they are grey stripes. Personally, I do prefer seeing the cover image look the way it's meant to look. I find that if I notice that the aspect ratio is wrong, it ruins the look of the cover for me. It is akin to stretching a 4:3 TV picture to fit a 16:9 screen.

[theducks]

Originally Posted by JSWolf

But in this case, they are grey stripes. Personally, I do prefer seeing the cover image look the way it's meant to look. I find that if I notice that the aspect ratio is wrong, it ruins the look of the cover for me. It is akin to stretching a 4:3 TV picture to fit a 16:9 screen.

Streach-o-vision.
Bleah
You might as well watch that movie on a phone

Pan and scan is not much better. P&S absolutely ruined the keys scene in ET

[kiwidude]

@Kovid - I've spent a number of hours looking into the conversion pipeline in relation to covers... and my head hurts

In particular - the epub_input.py plugin does some "fiddling" to generate a calibre_raster_cover.jpg and associated entries in the manifest along with a "titlepage" entry in the guide. However by the time it gets to the "structure" part of the pipeline, that seems to have magically disappeared and other logic from somewhere has come into play. Whats that all about - I "assume" it isn't just legacy code and actually has a scenario where it makes sense? Perhaps for non epub output or something?

I've found CoverManager being invoked by the epub_output.py plugin at the end, but I'm trying to figure out "what else" is taking place of relevance to covers in between during a conversion. Any other hints you can offer to look at?

[kovidgoyal]

I'm afraid I dont keep the details of cover handling in my head. I'd have to trawl through the code myself. IIRC the idea is that epub input creates a raster cover and a reference to the html cover (removing it from the spine), if the html cover is defined in the metadata. The rest of the conversion pipeline does nothing with covers, the various output plugins either use the raster cover, or for epub output do something complicated like replacing the html cover or adding one depending on the cover situation in the input document.