Random differences in blank line conversion in ePub

HarryT · 08-12-2009, 07:46 AM

A slight mystery:

I use ePub to convert my Mobi books to Calibre. All these Mobi books use "<br>" to indicate a blank line.

In some books I've converted, Calibre converts the line to:

<br class="calibrex"/>

This displays as a blank line in Calibre's ePub view, but unfortunately not in the "real" ADE viewer, either on the PC or on my Bookeen Opus.

On other books, Calibre converts some of the lines to:

<p class="calibrex" style="margin:0pt; border:0pt; height:1em">

and this does display correctly as a blank line in ADE and on the Opus.

Unfortunately, though, in these same books, it converts other (identical) lines to:

<p class="calibrex" style="margin:0pt; border:0pt; height:0pt">

which again does not display as a blank in ADE or the Opus.

Is this something which is "fixable"? Shall I raise a ticket?

HarryT · 08-12-2009, 08:24 AM

To add to the above:

If I change the code in the Mobi file from "<br>" to "<div> </div>" then that comes through "unchanged" to the ePub, and displays correctly as a blank line in ADE, but unfortunately it then doesn't display as a blank in Mobi

.

Would it be possible for the Mobi to ePub conversion code in Calibre to change "<br>" to ""<div> </div>" to avoid this problem?

Jellby · 08-12-2009, 08:37 AM

Instead of blank lines, you could use the HEIGHT attribute for the next paragraph in the Mobi file, that should convert fine.

HarryT · 08-12-2009, 08:45 AM

Oh sure, yes, I know that I can edit my existing books to make them convert correctly; as I say, replacing a "<br>" with an empty "<div>" works just fine. Being lazy, though, I was hoping that Kovid could devise a solution which would prevent me from having to do this

.

nrapallo · 08-12-2009, 08:58 AM

Quote:

Originally Posted by Jellby

Instead of blank lines, you could use the HEIGHT attribute for the next paragraph in the Mobi file, that should convert fine.

...or to avoid using Mobipocket-specific tags just replace that height="1em" attribute with the inline style="margin-top:1em" as I now use with Mobi2IMP when converting those non-standard attributes.

Also, you can similarily avoid the width="1em" attribute by replacing it by the inline style="text-indent:1em".

Check if <br style="margin-top:1em"> or <div style="margin-top:1em"> </div> work for you. Similarily, you can use <p style="text-indent:1em"> ... </p> to have that paragraph indent. BTW, you can combine these like <p style="text-indent:1em; margin-top:1em"> ... </p> to make the paragraph have an indent and have a blank line paragraph separation above it.

Heck, I just place that in the <body> tag ONCE for the entire ebook i.e. <body style="text-indent:1em; margin-top:1em">. I also, and this is my preference only, place a minimal left/right margin as well as fully justify text using <body style="text-indent:1em; margin-top:1em; margin-left:2px; margin-right:2px; text-align:justify">!!!

Nothing like sticking to standard HTML code when converting to multiple ebook formats...

HarryT · 08-12-2009, 09:05 AM

Thanks Nick - good suggestions.

nrapallo · 08-12-2009, 09:18 AM

Quote:

Originally Posted by HarryT

Thanks Nick - good suggestions.

Oops, I just reread your issue about converting .prc/.mobi ebooks directly to .epub and my suggestions can't help as Mobipocket Creator inserts those non-standard height= and width= attributes automatically into the .prc ebook. The embedded .html within a .prc ebook that gets extracted and converted by calibre ALREADY has those Mobipocket-specific tags/attributes and so it would be up to calibre to ensure your desired interactions are honoured.

In a bid to help further, can you post what the "calibrex" style is in the .css files within your result .epub. Or just upload your problematic .epub here and I'll see for myself what specific interference cailbre is enacting with that class="calibrex".

Now if you want to make your .epub using the comman line 'ebook-convert' (like I do), then you can use your underlying .html code (with my suggestions above) to make your .epub.

JSWolf · 08-12-2009, 09:35 AM

Another problem with HarryT's conversions also has to do with the indents. The HTML output from Book Designer sticks 4 non-breaking spaces in to make the indent. So those too would need to be edited out and fixed via the CSS.

HarryT · 08-12-2009, 09:45 AM

Quote:

Originally Posted by nrapallo

Oops, I just reread your issue about converting .prc/.mobi ebooks directly to .epub and my suggestions can't help as Mobipocket Creator inserts those non-standard height= and width= attributes automatically into the .prc ebook. The embedded .html within a .prc ebook that gets extracted and converted by calibre ALREADY has those Mobipocket-specific tags/attributes and so it would be up to calibre to ensure your desired interactions are honoured.

In a bid to help further, can you post what the "calibrex" style is in the .css files within your result .epub. Or just upload your problematic .epub here and I'll see for myself what specific interference cailbre is enacting with that class="calibrex".

Now if you want to make your .epub using the comman line 'ebook-convert' (like I do), then you can use your underlying .html code (with my suggestions above) to make your .epub.

Thank you, Nick, that's very kind.

If you download my ePub version of "The Barchester Chronicles" from:

https://www.mobileread.com/forums/showthread.php?t=53280

and go to chapter IV in the first book (the chapter called "Hiram's Bedesmen"), a couple of pages into the chapter you'll see a list of names, separated by blank lines. That version uses blank "<div>s" and displays the blank lines correctly.

Compare that with the version I've attached to this message. It has "<br>s" for blank lines, and ADE (and the Opus) simply omit the blank lines.

In both cases, the source for that chapter is the "_split_7" file in the ePub.

nrapallo · 08-12-2009, 10:07 AM

I can't see what would be the culprit as the <br class="calibre3"/> doesn't have any interference from the CSS

Code:

.calibre3 {
    display: block
    }

But perhaps it is a gloablly defined problem from using <body text="#000000" class="calibre"> with the CSS being

Code:

.calibre {
    background-color: #fff;
    display: block;
    font-family: Times New Roman;
    font-size: 1em;
    font-weight: normal;
    line-height: normal;
    margin-bottom: 0;
    margin-left: 5pt;
    margin-right: 13pt;
    margin-top: 0;
    page-break-before: always;
    text-align: justify
    }

where 'margin-top: 0;' doesn't allow any white line spacing between block tags.

It may even be a more subtle issue of using that html code

Code:

<div class="calibre4">mark </div>
<br class="calibre3"/>
<div class="calibre4">his </div>

since the first <div> doesn't usually cause a line-break and the subsequent <br> just advances to the start of the next line and the second <div> also doesn't cause any line advance/break...

HarryT · 08-12-2009, 10:53 AM

I suspect it's a bug in ADE, Nick. If you display the code in a web browser, the blank lines show up OK.

Thank you for taking the time to look at it - I appreciate it.

kovidgoyal · 08-12-2009, 01:10 PM

Hmm another ADE workaround. Open a ticket for it and I'll have a look at it when I have a moment.

HarryT · 08-12-2009, 01:12 PM

Will do. Just an "it would be nice to have" thing; certainly not important. My main question was really why there is a seeming inconsistency in the way that Calibre "translates" blank lines, as asked in the initial thread of the post.

kovidgoyal · 08-12-2009, 01:23 PM

depends on context, calibre does a lot of processing to try to ensure that as much of the input CSS is translated as correctly as possible, and then ADE for example does not support <br> tags that are top level children of <body> so calibre tries to convert them into something that has an equivalent effect in ADE and in various browsers.

HarryT · 08-13-2009, 03:31 AM

Thanks, Kovid.

08-12-2009, 07:46 AM	#1
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Random differences in blank line conversion in ePub A slight mystery: I use ePub to convert my Mobi books to Calibre. All these Mobi books use "<br>" to indicate a blank line. In some books I've converted, Calibre converts the line to: <br class="calibrex"/> This displays as a blank line in Calibre's ePub view, but unfortunately not in the "real" ADE viewer, either on the PC or on my Bookeen Opus. On other books, Calibre converts some of the lines to: <p class="calibrex" style="margin:0pt; border:0pt; height:1em"> and this does display correctly as a blank line in ADE and on the Opus. Unfortunately, though, in these same books, it converts other (identical) lines to: <p class="calibrex" style="margin:0pt; border:0pt; height:0pt"> which again does not display as a blank in ADE or the Opus. Is this something which is "fixable"? Shall I raise a ticket?

08-12-2009, 08:24 AM	#2
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	To add to the above: If I change the code in the Mobi file from "<br>" to "<div> </div>" then that comes through "unchanged" to the ePub, and displays correctly as a blank line in ADE, but unfortunately it then doesn't display as a blank in Mobi . Would it be possible for the Mobi to ePub conversion code in Calibre to change "<br>" to ""<div> </div>" to avoid this problem? Last edited by HarryT; 08-12-2009 at 08:28 AM.

08-12-2009, 10:07 AM	#10
nrapallo GuteBook/Mobi2IMP Creator Posts: 2,958 Karma: 2530691 Join Date: Dec 2007 Location: Toronto, Canada Device: REB1200 EBW1150 Device: T1 NSTG iLiad_v2 NC Device: Asus_TF Next1 WPDN	I can't see what would be the culprit as the <br class="calibre3"/> doesn't have any interference from the CSS Code: .calibre3 { display: block } But perhaps it is a gloablly defined problem from using <body text="#000000" class="calibre"> with the CSS being Code: .calibre { background-color: #fff; display: block; font-family: Times New Roman; font-size: 1em; font-weight: normal; line-height: normal; margin-bottom: 0; margin-left: 5pt; margin-right: 13pt; margin-top: 0; page-break-before: always; text-align: justify } where 'margin-top: 0;' doesn't allow any white line spacing between block tags. It may even be a more subtle issue of using that html code Code: <div class="calibre4">mark </div> <br class="calibre3"/> <div class="calibre4">his </div> since the first <div> doesn't usually cause a line-break and the subsequent <br> just advances to the start of the next line and the second <div> also doesn't cause any line advance/break...

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
[Old Thread] epub -> mobi conversion; blank page after image	joubert	Calibre	10	03-07-2011 05:26 PM
Line Spacing on PDF to Epub conversion	poodlemama	Calibre	2	05-03-2010 08:28 PM
get rid of blank line html code	Blurr	Calibre	4	12-28-2009 09:20 PM
Sigil 1.6 - deleting blank line very slow	lol	Sigil	2	12-24-2009 11:54 AM
epub to pdf conversion: blank page inserted before any section	Nicoo	Calibre	0	12-06-2009 06:10 PM

08-12-2009, 08:37 AM	#3
Jellby frumious Bandersnatch Posts: 7,515 Karma: 18512745 Join Date: Jan 2008 Location: Spaniard in Sweden Device: Cybook Orizon, Kobo Aura	Instead of blank lines, you could use the HEIGHT attribute for the next paragraph in the Mobi file, that should convert fine.

08-12-2009, 08:45 AM	#4
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Oh sure, yes, I know that I can edit my existing books to make them convert correctly; as I say, replacing a "<br>" with an empty "<div>" works just fine. Being lazy, though, I was hoping that Kovid could devise a solution which would prevent me from having to do this .

08-12-2009, 09:05 AM	#6
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Thanks Nick - good suggestions.

08-12-2009, 09:35 AM	#8
JSWolf Resident Curmudgeon Posts: 73,835 Karma: 128597114 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	Another problem with HarryT's conversions also has to do with the indents. The HTML output from Book Designer sticks 4 non-breaking spaces in to make the indent. So those too would need to be edited out and fixed via the CSS.

08-12-2009, 10:53 AM	#11
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	I suspect it's a bug in ADE, Nick. If you display the code in a web browser, the blank lines show up OK. Thank you for taking the time to look at it - I appreciate it.

08-12-2009, 01:10 PM	#12
kovidgoyal creator of calibre Posts: 43,826 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	Hmm another ADE workaround. Open a ticket for it and I'll have a look at it when I have a moment.

08-12-2009, 01:12 PM	#13
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Will do. Just an "it would be nice to have" thing; certainly not important. My main question was really why there is a seeming inconsistency in the way that Calibre "translates" blank lines, as asked in the initial thread of the post.

08-12-2009, 01:23 PM	#14
kovidgoyal creator of calibre Posts: 43,826 Karma: 22666666 Join Date: Oct 2006 Location: Mumbai, India Device: Various	depends on context, calibre does a lot of processing to try to ensure that as much of the input CSS is translated as correctly as possible, and then ADE for example does not support <br> tags that are top level children of <body> so calibre tries to convert them into something that has an equivalent effect in ADE and in various browsers.

08-13-2009, 03:31 AM	#15
HarryT eBook Enthusiast Posts: 85,544 Karma: 93383043 Join Date: Nov 2006 Location: UK Device: Kindle Oasis 2, iPad Pro 10.5", iPhone 6	Thanks, Kovid.

Advert

Advert