Way to turn off Calibre's horrible code generation?

Brett Merkey · 07-10-2015, 09:49 AM

Calibre conversion from ePub to AZW (or anything else) seems to make a mess of HTML code during conversion. Calibre produces verbose, over-constrained, non-semantic code in epub conversion.

For example:
ePub code: <h2>Chapter One</h2>
becomes after conversion:
<p class="caliber_14"><span class="bold"><span class="italic">Chapter One</span></span></p>

In addition, ordinary para tags are classed and spanned willy-nilly. Is it really necessary to change structural HTML so radically in this operation? Is there a way to potty-train Calibre in this respect?

gbm · 07-10-2015, 10:08 AM

Quote:

Originally Posted by Brett Merkey

Calibre conversion from ePub to AZW (or anything else) seems to make a mess of HTML code during conversion. Calibre produces verbose, over-constrained, non-semantic code in epub conversion.

For example:
ePub code: <h2>Chapter One</h2>
becomes after conversion:
<p class="caliber_14"><span class="bold"><span class="italic">Chapter One</span></span></p>

In addition, ordinary para tags are classed and spanned willy-nilly. Is it really necessary to change structural HTML so radically in this operation? Is there a way to potty-train Calibre in this respect?

In my experience calibre does an excellent job of taking garage in and producing workable out put.

You need to check your source files.

bernie

theducks · 07-10-2015, 11:29 AM

Quote:

<p class="caliber_14"><span class="bold"><span class="italic">Chapter One</span></span></p>

I don't believe this was calibre generated (un modified)

Also, I have never seen Calibre DROP a H tag down to a P

Brett Merkey · 07-10-2015, 02:06 PM

Thank you for a reply 'ducks. Producing semantic code is what I did for a living. That Calibre behavior on conversion (to non-semantic over-constraining HTML) is so frustratingly consistently is why I decided to post. I assure you, I do not invent these "calibre_42" classes. In fact, no human being would. It takes software to be so consistently destructive of good structural code. Dropping h2 tags seems egregious but it happens--and has happened for months. Most, but not all, of my own classes are multiplied and obliterated. For instance, Calibre may detect a footnote in an element, and therefor create a whole new "calibre_103" because a superscript tag will alter computed line-height. It goes on.

I can save the original code and just paste it over the Calibre-produced nonsense (blowing away the bloated Calibre-produced CSS too) but, really, this tedium should not be necessary.

I wish there were a checkbox on conversion: "Leave the HTML structural code alone."

eschwartz · 07-10-2015, 03:22 PM

calibre conversions will always flatten the CSS. You will end up with a finely blended (think food processor) ebook whenever you use calibre to convert a book.

This is done in order to ensure consistency, as calibre's conversion pipelines do things to fix rendering on a variety of devices. To an end user who will not (typically) need to modify the code, this should not be a problem. If it's a problem anyway, you might want to use kindlegen instead.

Question: Does the ebook look wrong on a device after conversion? If so, you *might* want to submit a bug report. If not, you are complaining about a non-issue.

Although as theducks said, calibre should not be misspelling it's own name! That leads me to suspect something is missing here...

As for downgrading tags from <h2> --> <p>, if you are truly converting to MOBI (AZW doesn't exist) as opposed to AZW3, that may be your problem. I am pretty sure the mobipocket7 format (popularly known as MOBI, though Amazon muddies the waters by giving it the .azw extension) does not support such bleeding-edge HTML technology as header tags.

It also doesn't support CSS.
That's why they invented AZW3 (KF8) -- to fix those problems. Why are you using ancient, inefficient, primitive, barebones formats?/

Brett Merkey · 07-10-2015, 04:11 PM

@eschwartz,
Yes, I am talking azw3 here. The format does not really matter. If I use Calibre to produce clean HTML structure directly in AZW3, if I convert to ePub, then the code I am complaining about is again generated by Calibre. This is a Calibre issue.

The actual "look" of the book does not change for a reader. This is not (yet) my concern. I am concerned about code maintenance and editing. For this reason, I want simple, stripped, semantic HTML--leaving the presentational complexity to the stylesheet.

What we see from Calibre conversions is bloated, hard to maintain structural code. I see no reason for Calibre to do this.

eschwartz · 07-10-2015, 04:30 PM

Okay, good to know.

So as I said -- calibre, by design, will flatten CSS. Considering most books are not coded with your high standards (and trust me, I know where you are coming from) this is a good thing! There are valid reasons for calibre to do so.

The one problem with calibre's flatten-the-CSS approach is that it spits out a hard-to-edit book. This issue has been brought up numerous times, and Kovid is adamant that his approach is correct. This will not change.

As far as code maintenance and editing goes -- keep your original, master copy. Perform all modifications there. Then use calibre to recompile an end-use AZW3. Do not perform modifications directly in the AZW3 -- because then you will end up with differences between the AZW3 and the EPUB!

Always edit your master format.
Keep your master format safe. calibre doesn't touch that, and doesn't want to.

Might I ask why you want to convert an EPUB to AZW3, in order to edit the AZW3, just so you can convert it back to EPUB???

cybmole · 07-10-2015, 04:35 PM

Why are you using calibre if you hate it so much. Why not take your semantic coding skills and build us something better, if you have the talent.

dickloraine · 07-10-2015, 04:42 PM

I always thought, calibres conversion feature is aimed at readers not authors. It is there to convert from one existing format to another. Automatically, regardless of the quality of the source.
If you want to make a quality eBook, then use the calibre editor. Or Sigil. To produce a kindle file, there is kindlegen from amazon themselves. Or even convert with calibre. You won't edit the file anymore, since you would do that in the source file.

Brett Merkey · 07-10-2015, 04:56 PM

@eschwartz,
Thanks for the trouble of the reply. Appreciated.
" This issue has been brought up numerous times, and Kovid is adamant that his approach is correct. This will not change."

Well, a policy statement. Fine enough for me. I am used to that approach dealing with upper management of the international monopoly I retired from.

I enquire no further. It is what it is. You make a good suggestion. I will keep my good code in storage and only feed helpless clones of it into Calibre's jagged jaws...

eschwartz · 07-10-2015, 05:08 PM

Well, conversions won't change the original format anyway.

Just as long as you don't convert TO your master format.

Anyway, it's always good to have clarity on what precisely the query is in order to determine the answer. Happy to help clear things up.

07-10-2015, 09:49 AM	#1
Brett Merkey Not Quite Dead Posts: 194 Karma: 654170 Join Date: Jul 2015 Device: Paperwhite 4; Galaxy Tab	Way to turn off Calibre's horrible code generation? Calibre conversion from ePub to AZW (or anything else) seems to make a mess of HTML code during conversion. Calibre produces verbose, over-constrained, non-semantic code in epub conversion. For example: ePub code: <h2>Chapter One</h2> becomes after conversion: <p class="caliber_14"><span class="bold"><span class="italic">Chapter One</span></span></p> In addition, ordinary para tags are classed and spanned willy-nilly. Is it really necessary to change structural HTML so radically in this operation? Is there a way to potty-train Calibre in this respect?

07-10-2015, 04:11 PM	#6
Brett Merkey Not Quite Dead Posts: 194 Karma: 654170 Join Date: Jul 2015 Device: Paperwhite 4; Galaxy Tab	@eschwartz, Yes, I am talking azw3 here. The format does not really matter. If I use Calibre to produce clean HTML structure directly in AZW3, if I convert to ePub, then the code I am complaining about is again generated by Calibre. This is a Calibre issue. The actual "look" of the book does not change for a reader. This is not (yet) my concern. I am concerned about code maintenance and editing. For this reason, I want simple, stripped, semantic HTML--leaving the presentational complexity to the stylesheet. What we see from Calibre conversions is bloated, hard to maintain structural code. I see no reason for Calibre to do this. Last edited by Brett Merkey; 07-10-2015 at 04:14 PM.

07-10-2015, 04:30 PM	#7
eschwartz Ex-Helpdesk Junkie Posts: 19,422 Karma: 85397180 Join Date: Nov 2012 Location: The Beaten Path, USA, Roundworld, This Side of Infinity Device: Kindle Touch fw5.3.7 (Wifi only)	Okay, good to know. So as I said -- calibre, by design, will flatten CSS. Considering most books are not coded with your high standards (and trust me, I know where you are coming from) this is a good thing! There are valid reasons for calibre to do so. The one problem with calibre's flatten-the-CSS approach is that it spits out a hard-to-edit book. This issue has been brought up numerous times, and Kovid is adamant that his approach is correct. This will not change. As far as code maintenance and editing goes -- keep your original, master copy. Perform all modifications there. Then use calibre to recompile an end-use AZW3. Do not perform modifications directly in the AZW3 -- because then you will end up with differences between the AZW3 and the EPUB! Always edit your master format. Keep your master format safe. calibre doesn't touch that, and doesn't want to. Might I ask why you want to convert an EPUB to AZW3, in order to edit the AZW3, just so you can convert it back to EPUB??? Last edited by eschwartz; 07-10-2015 at 04:33 PM.

07-10-2015, 04:56 PM	#10
Brett Merkey Not Quite Dead Posts: 194 Karma: 654170 Join Date: Jul 2015 Device: Paperwhite 4; Galaxy Tab	@eschwartz, Thanks for the trouble of the reply. Appreciated. " This issue has been brought up numerous times, and Kovid is adamant that his approach is correct. This will not change." Well, a policy statement. Fine enough for me. I am used to that approach dealing with upper management of the international monopoly I retired from. I enquire no further. It is what it is. You make a good suggestion. I will keep my good code in storage and only feed helpless clones of it into Calibre's jagged jaws... Last edited by Brett Merkey; 07-10-2015 at 05:01 PM.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Disable cover generation when adding books in Calibre?	rebl	Library Management	8	03-18-2013 06:56 AM
Cluttered Calibre style code in EPUB	rurdyrucker	Calibre	4	04-08-2012 02:17 AM
Ability to schedule to turn on/off Calibre?	JayKindle	Calibre	9	03-18-2012 12:23 PM
Regarding Calibre source code compiling	shivas	Introduce Yourself	4	12-23-2009 09:52 AM
Help with Error code from Calibre that I can't decifer	hefrench	Calibre	1	10-09-2009 12:01 PM

07-10-2015, 02:06 PM	#4
Brett Merkey Not Quite Dead Posts: 194 Karma: 654170 Join Date: Jul 2015 Device: Paperwhite 4; Galaxy Tab	Thank you for a reply 'ducks. Producing semantic code is what I did for a living. That Calibre behavior on conversion (to non-semantic over-constraining HTML) is so frustratingly consistently is why I decided to post. I assure you, I do not invent these "calibre_42" classes. In fact, no human being would. It takes software to be so consistently destructive of good structural code. Dropping h2 tags seems egregious but it happens--and has happened for months. Most, but not all, of my own classes are multiplied and obliterated. For instance, Calibre may detect a footnote in an element, and therefor create a whole new "calibre_103" because a superscript tag will alter computed line-height. It goes on. I can save the original code and just paste it over the Calibre-produced nonsense (blowing away the bloated Calibre-produced CSS too) but, really, this tedium should not be necessary. I wish there were a checkbox on conversion: "Leave the HTML structural code alone."

07-10-2015, 03:22 PM	#5
eschwartz Ex-Helpdesk Junkie Posts: 19,422 Karma: 85397180 Join Date: Nov 2012 Location: The Beaten Path, USA, Roundworld, This Side of Infinity Device: Kindle Touch fw5.3.7 (Wifi only)	calibre conversions will always flatten the CSS. You will end up with a finely blended (think food processor) ebook whenever you use calibre to convert a book. This is done in order to ensure consistency, as calibre's conversion pipelines do things to fix rendering on a variety of devices. To an end user who will not (typically) need to modify the code, this should not be a problem. If it's a problem anyway, you might want to use kindlegen instead. Question: Does the ebook look wrong on a device after conversion? If so, you might want to submit a bug report. If not, you are complaining about a non-issue. Although as theducks said, calibre should not be misspelling it's own name! That leads me to suspect something is missing here... As for downgrading tags from <h2> --> <p>, if you are truly converting to MOBI (AZW doesn't exist) as opposed to AZW3, that may be your problem. I am pretty sure the mobipocket7 format (popularly known as MOBI, though Amazon muddies the waters by giving it the .azw extension) does not support such bleeding-edge HTML technology as header tags. It also doesn't support CSS. That's why they invented AZW3 (KF8) -- to fix those problems. Why are you using ancient, inefficient, primitive, barebones formats?/

07-10-2015, 04:35 PM	#8
cybmole Wizard Posts: 3,720 Karma: 1759970 Join Date: Sep 2010 Device: none	Why are you using calibre if you hate it so much. Why not take your semantic coding skills and build us something better, if you have the talent.

07-10-2015, 04:42 PM	#9
dickloraine Guru Posts: 631 Karma: 7544080 Join Date: Apr 2013 Location: Berlin Device: PRS 350, Kobo Aura	I always thought, calibres conversion feature is aimed at readers not authors. It is there to convert from one existing format to another. Automatically, regardless of the quality of the source. If you want to make a quality eBook, then use the calibre editor. Or Sigil. To produce a kindle file, there is kindlegen from amazon themselves. Or even convert with calibre. You won't edit the file anymore, since you would do that in the source file.

07-10-2015, 05:08 PM	#11
eschwartz Ex-Helpdesk Junkie Posts: 19,422 Karma: 85397180 Join Date: Nov 2012 Location: The Beaten Path, USA, Roundworld, This Side of Infinity Device: Kindle Touch fw5.3.7 (Wifi only)	Well, conversions won't change the original format anyway. Just as long as you don't convert TO your master format. Anyway, it's always good to have clarity on what precisely the query is in order to determine the answer. Happy to help clear things up.