HTML to MOBI via command line: Can't remove left and right page margins

[otw-adt]

Hello! I'm part of the Archive of Our Own development team, and we'd like to use Calibre's command line interface to offer MOBI downloads of our users' stories. Our users strongly prefer MOBI files with no left or right margins at all, but we're having trouble achieving that. If it's relevant, you can see our planned implementation of Calibre in this pull request. The process amounts to the following:

First, we create an HTML file. Here's a Gist with an example HTML file.

Then we convert that HTML file to MOBI using the following command:

ebook-convert input_file output_file --input-encoding="utf-8" --use-auto-toc --title="story title" --authors="authors" --comments="story summary" --tags="tag" --pubdate="date" --chapter="//h:body/h:div[@id='chapters']/h:h2[@class='toc-heading'] | //h:body/h:div[@id='chapters']/h:div[@class='meta group']/h:h2[@class='heading'] | //h:body/h:div[@id='preface' or @id='afterword']/h:h2[@class='toc-heading']" --mobi-ignore-margins --remove-paragraph-spacing --extra-css=".meta dt { font-weight: bold; }"

We've tried adding the following CSS to the HTML file's stylesheet without any luck:

@page, html, body, div, p, blockquote { margin-right: 0; margin-left: 0; }

We tried specifying 0pt as well, since we know Calibre uses pts for margins.

We also tried including the above CSS with the --extra-css option, removing the --mobi-ignore-margins option, and using --margin-left="0" and --margin-right="0".

We even tried completely removing the CSS that's in the HTML file, just in case one of our styles was to blame.

Finally, I used the KindleImport plugin for Sigil to compare a MOBI file that didn't have margins with the MOBI file we were generating using Calibre. The file without margins had margin attributes (leftmargin="0" bottommargin="0" topmargin="0" rightmargin="0") added to the body tag, so I added those to our HTML file's template. Unfortunately, it didn't help, and when I examined the resultant MOBI file using Sigil, the margin attributes had been removed from the body element.

For reference, I've attached a MOBI file without margins (without_margins.mobi), which we produced using our old system, and one with margins that we produced using Calibre (with_margins.mobi). We've tried versions 3.27.1 and 3.28.0 of Calibre, but we just can't seem to make the margins go away.

We'd be very grateful for any help you can provide!

Thanks,
Sarken

[DNSB]

I've done conversions to mobi from the GUI not from the command line but I ended up using the following in extra.css.

body, p, div, .calibre1, .calibre2, .calibre3, .calibre4, .calibre5, .calibre6, .calibre7 {
    margin-left: 0;
    margin-right: 0;
}

Not sure how much use this will be to you but good luck.

[otw-adt]

Thank you for the suggestion! Unfortunately, it didn't seem to have any effect.

I have another bit of information to add, though, in case it's helpful. If I use the --extract-to option, the pretty.html file that is extracted has height and width attributes on each paragraph and blockquote tag, like so:

<p height="0pt" width="2em">Summary</p>
<blockquote height="2em"><blockquote width="2em"> <i>Cronut wayfarers shoreditch.</i> </blockquote></blockquote>
<pagebreak></pagebreak><p height="2em" width="2em"> </p>
<p height="0pt" width="2em">Lorem ipsum dolor amet iPhone cardigan iceland man braid sriracha, hashtag gentrify. Meditation street art shabby chic, yuccie photo booth kogi humblebrag venmo ugh. Art party freegan godard pickled echo park blog. Tofu gentrify four dollar toast, migas raclette 8-bit cornhole pour-over. Kogi neutra chartreuse post-ironic everyday carry readymade portland ennui franzen kickstarter umami thundercats. Vice literally fanny pack, cloud bread la croix succulents sriracha flexitarian typewriter. Hammock lo-fi live-edge single-origin coffee umami.</p>

Unfortunately, specifying a width in the CSS (e.g. p { width: 100% !important; }) doesn't change the appearance of the MOBI or the HTML in pretty.html.

[kovidgoyal]

Convert to azw3 not mobi and you will be fine. MOBI is an obsolete format does not have any support for CSS, so CSS gets mapped to custom HTML attributes. Only a very liited subset of CSS can be supported in this fashion.

kindlegen will for instance vreate mobi files that are actually azw3 files with an included mobi stub for older devies (you can do the same thing in calibre using --mobi-type=joint)

[kovidgoyal]

And just FYI (IIRC) width and height in mobi tags refer to indent and margin respectively.

[otw-adt]

We do need to continuing supporting the old mobi format, so it's disappointing we can't reproduce the existing margin-less behavior with Calibre, but thank you for the information!

[otw-adt]

We considered making the switch to --mobi-file-type=both after all, and I just wanted to come back here and give a heads up for anyone who might come across this thread in the future: neither AZW3 nor the new or both MOBI formats will work with Amazon's Send to Kindle option, so if Send to Kindle support is important for your users, you'll have to stick with the old MOBI format and all of its limitations.

Hope this helps save someone else some time!

[shalym]

Originally Posted by otw-adt

We considered making the switch to --mobi-file-type=both after all, and I just wanted to come back here and give a heads up for anyone who might come across this thread in the future: neither AZW3 nor the new or both MOBI formats will work with Amazon's Send to Kindle option, so if Send to Kindle support is important for your users, you'll have to stick with the old MOBI format and all of its limitations.

Hope this helps save someone else some time!

Hmm...I send dual (new) mobis using Send to Kindle all the time. I did it again just now, to make sure that it was still working for me. I also tried emailing a dual mobi to my Kindle archive, and that worked as well.

What error are you getting when you try to send it?

Shari

[otw-adt]

It's an email with the subject "There was a problem with the document(s) you sent to Kindle." It says:

The following document, sent at 06:47 AM on Sat, Aug 18, 2018 GMT could not be delivered to the Kindle you specified:
* the pier in santa monica.mobi


The Kindle Personal Document Service can convert and deliver the following types of documents:

• Microsoft Word (.doc, .docx)
• Rich Text Format (.rtf)
• HTML (.htm, .html)
• Text (.txt) documents
• Archived documents (zip , x-zip) and compressed archived documents
• Mobi book

Images that are of type JPEGs (.jpg), GIFs (.gif), Bitmaps (.bmp), and PNG images (.png).
Adobe PDF (.pdf) documents are delivered without conversion to Kindle DX, Second Generation and Latest Generation Kindles.

Adobe PDF (.pdf) can be converted to Kindle format and delivered on an experimental basis.

If the document that failed belonged to one of the above document types, please ensure the document is not password protected or encrypted. Note that the Latest Generation Kindles support password protected PDFs.

Helpful tips for personal document attachments:

• The file size of each attached personal document should be less than 50MB (before compression in a ZIP file)
• The email submitted should not contain more than 25 attached personal documents

This doesn't seem to be entirely new. We currently use an entirely different, non-Calibre system to create old format MOBI files, and users have reported that converting them to the newer MOBI format in Calibre and using Send to Kindle fails with the same message. I'd thought that might get fixed when we changed the HTML file we generate MOBIs from, but that doesn't seem to be the case.

[kovidgoyal]

You cannot send new style MOBI via send to kindle. You can send either old style MOBI or joint MOBI.

[otw-adt]

When I said new style MOBI, I meant the ones generated with --mobi-file-type=both, as described in a previous message. That's what gave the error I posted.

Sorry for the confusion!

[shalym]

Originally Posted by otw-adt

When I said new style MOBI, I meant the ones generated with --mobi-file-type=both, as described in a previous message. That's what gave the error I posted.

Sorry for the confusion!

That's exactly what I send, and sent yesterday using the Send to Kindle app, and then I sent a different one of the same type via email. Both came through just fine.

Shari