Mystery and Crime Churchill, Edward: 42 Keys to Murder v1 7 feb 2009

[mtravellerh]

Straight from the pages of Popular Detective (March 1948) comes this pulpy mystery novelette!

Newspaper correspondent Nick Burney and his wife Sue become a pair of high-powered sleuths when they take the trail after the killing of Homer Hansel, the snooping society editor.

With a nice illustration

[nrapallo]

Georges:

Within the last few .epubs posted (see Reid, Mayne: The Plant Hunters v1 6 feb 2009 as well), any .html contains an odd line ending html tag for a carriage return/line feed, namely, &# 13; (ignore my space between the &# and 13, or else you'll see hard line breaks like the end of the below paragraph and no html code):

<!--mozToc h2 1--><h2 id="calibre_chapter_1">CHAPTER&# 13;
I</h2>&# 13;
&# 13;
<h3>One Column Less</h3>&# 13;
&# 13;
<p>NICK BURNEY, Rock City correspondent for the Las Verdes&# 13;
Sentinel, sat nervously in the battered *Ford&# 13;
*pick-up *while *his *wife, Sue,&# 13;
stopped and started as the lights along Tremont Street turned red and

green and red again. Although midnight had long since passed, Las

Verdes, the gambling metropolis situated in a shallow desert bowl so

big that the mountains seemed small in the distance, was still going

strong.</p>

While it appears that an html browser ignores them, they do cause issues when trying to convert directly to .imp from .epub, as they are treated as "hard" line breaks. A soft line breaks like the "\n" line ending is normal, but a "&# 13;" appears non-standard. BTW, Charlie's .epubs created by Calibre do not exhibit the same line-endings or issues.

Did you recently change settings on your text/html editor? Know what's causing them to be output this way?

Regards,

[mtravellerh]

Originally Posted by nrapallo

Georges:

Within the last few .epubs posted (see Reid, Mayne: The Plant Hunters v1 6 feb 2009 as well), any .html contains an odd line ending html tag for a carriage return/line feed, namely, &# 13; (ignore my space between the &# and 13, or else you'll see hard line breaks like the end of the below paragraph and no html code):

<!--mozToc h2 1--><h2 id="calibre_chapter_1">CHAPTER&# 13;
I</h2>&# 13;
&# 13;
<h3>One Column Less</h3>&# 13;
&# 13;
<p>NICK BURNEY, Rock City correspondent for the Las Verdes&# 13;
Sentinel, sat nervously in the battered *Ford&# 13;
*pick-up *while *his *wife, Sue,&# 13;
stopped and started as the lights along Tremont Street turned red and

green and red again. Although midnight had long since passed, Las

Verdes, the gambling metropolis situated in a shallow desert bowl so

big that the mountains seemed small in the distance, was still going

strong.</p>

While it appears that an html browser ignores them, they do cause issues when trying to convert directly to .imp from .epub, as they are treated as "hard" line breaks. A soft line breaks like the "\n" line ending is normal, but a "&# 13;" appears non-standard. BTW, Charlie's .epubs created by Calibre do not exhibit the same line-endings or issues.

Did you recently change settings on your text/html editor? Know what's causing them to be output this way?

Regards,

Oh yes, this is an autogenerated Calibre code. I have seen that when I edited epubs directly. I have changed my way of working lately, creating epubs and lrfs from html/zip directly and using another slightly changed html source for mobi-> imp. So the coding of the epubs does not interfere on imps.

So better ask Kovid about those. It's definitely not my code. Maybe he knows a workaround for your epub2imp engine.

[nrapallo]

Originally Posted by mtravellerh

Oh yes, this is an autogenerated Calibre code. I have seen that when I edited epubs directly. I have changed my way of working lately, creating epubs and lrfs from html/zip directly and using another slightly changed html source for mobi-> imp. So the coding of the epubs does not interfere on imps.

So better ask Kovid about those. It's definitely not my code. Maybe he knows a workaround for your epub2imp engine.

Thanks for the info.

Now, I also see this line-ending behaviour in .epubs other than yours, so it MUST be a recent (post late Jan. 2009) Calibre change. I guess the version Charlie's using to create .epubs must be an older Calibre version.

I AM trying to get this epub2imp written, but there are a lot of variables to deal with, and then you get issues like this one, which almost convince me to "throw in the towel"... Oh well , off to bother Kovid...

[mtravellerh]

Originally Posted by nrapallo

Thanks for the info.

Now, I also see this line-ending behaviour in .epubs other than yours, so it MUST be a recent (post late Jan. 2009) Calibre change. I guess the version Charlie's using to create .epubs must be an older Calibre version.

I AM trying to get this epub2imp written, but there are a lot of variables to deal with, and then you get issues like this one, which almost convince me to "throw in the towel"... Oh well , off to bother Kovid...

I think Charlie may use some BD-generated format and import that into Calibre to generate the other formats (epub and lrf). I know for sure that he uses BD to create his books. Maybe this hard linebreak occurs only in html-generated epubs.

[kovidgoyal]

is simply the entity representation of the \r (carriage return) character. You can just run a global replace to replace with a space character and you should be fine.

[mtravellerh]

Of course Thanks, Kovid

[nrapallo]

Originally Posted by kovidgoyal

is simply the entity representation of the \r (carriage return) character. You can just run a global replace to replace with a space character and you should be fine.

Oh, another feature... I'll use text substitution to get rid of it altogether.

Thanks for the advice and you can now close http://calibre.kovidgoyal.net/ticket/1792.

[nrapallo]

Originally Posted by mtravellerh

I think Charlie may use some BD-generated format and import that into Calibre to generate the other formats (epub and lrf). I know for sure that he uses BD to create his books. Maybe this hard linebreak occurs only in html-generated epubs.

An issue I'm having with Charlie's BD html is that only <div>'s are used and the CSS formatting works better when surround by <p>'s for .imp ebooks.

My original solution was to replace all div's with p's, but I may retain the div's and wrap them around p's with the same inline style, if any, like:

<p class="calibre_class_5"><span class="bold"><span class="calibre_class_2">Chapter I</span></span></p>
</a>
</span>
<p class="calibre_class_7">****George Colfax was in an outraged frame of mind, and properly so.</p>

or instead:

<p class="calibre_class_5"><div class="calibre_class_5"><span class="bold"><span class="calibre_class_2">Chapter I</span></span></div></p>
</a>
</span>
<p class="calibre_class_7"><div class="calibre_class_7">****George Colfax was in an outraged frame of mind, and properly so.</div></p>

[kovidgoyal]

Originally Posted by nrapallo

Oh, another feature... I'll use text substitution to get rid of it altogether.

Thanks for the advice and you can now close http://calibre.kovidgoyal.net/ticket/1792.

I've already fixed this in calibre, it now runs the global replace on the input HTML

[nrapallo]

Originally Posted by kovidgoyal

I've already fixed this in calibre, it now runs the global replace on the input HTML

Thanks Kovid!

Any idea what started it appearing? A library you started using recently or an updated version of same?

Just curious, no need to investigate if you don't know, off hand.

Thanks again!

[kovidgoyal]

Originally Posted by nrapallo

Thanks Kovid!

Any idea what started it appearing? A library you started using recently or an updated version of same?

Just curious, no need to investigate if you don't know, off hand.

Thanks again!

Not off hand