Forum: Author Hangout

Try to convert the .epub to .mobi,

That gave me a glimmer of hope. But it didn't work. Either did converting from .AZW3 to .mobi.

There must be a bug in Calibre converting to .mobi.

that's particular to Amazon, in that they force a one-character inset that you can't override

Actually, the indent in the .mobi is larger than it is in the .epub from the same source. Much more than one character.

Actually, the indent in the .mobi is larger than it is in the .epub from the same source. Much more than one character.

Sorry, but I was thinking of those for backquotes, but then again, maybe Amazon finally relented and removed their previous, long-standing one-character space indent limitation.

I'm waiting to hear back from Lazeez if I can upload the .AZW3 file to Bookapy for their Kindle version (I've always uploaded .mobi).

When I first saw that, I wondered the same thing. Of course, the reason is that the ONLY difference between the two is that the AZ is the inclusion of DRM (Digital Rights Management copying restrictions). However, there are various tools available to strip the DRM restrictions from AZW3 files anyway, so ...

It's one thing to say 'You can ONLY submit DRM free stories' and it's another entirely to say 'We'll STRIP any DRM restrictions from your submissions'!

It's one thing to say 'You can ONLY submit DRM free stories' and it's another entirely to say 'We'll STRIP any DRM restrictions from your submissions'!

I just published the novel on Bookapy (waiting on the moderators). I was going to only publish the .epub and PDF versions on Bookapy since the .mobi version is bad and a Kindle version will be on Amazon, but I want to support Bookapy over Amazon so I uploaded the AZW3 version. We'll see what the moderator does.

And another user on kboards said:

Don't download MOBI! Download EPUB and use Calibre to convert to AZW3

Only, there's the bit about Lazeez accepting it. For all we know, he'll just convert it back to MOBI. I suspect issue is DRM, or maybe there are other triggers which cause conversion complications, but it's basically in his hands.

Only, there's the bit about Lazeez accepting it. For all we know, he'll just convert it back to MOBI.

He never replied to my question so I published it as .AZW3 and it's out there. Did he change it to .mobi? I have no idea. And since the problem is in Chapter 43, it's way beyond the sample pages so I can't see it.

Which book is it?

"Lonely War Widows."

It's the first book on Bookapy's home page.

So I modified the code to allow it as a test and see what the readers say. If they complain I may have to change my mind about accepting azw3 files.

Thanks.

So I modified the code to allow it as a test and see what the readers say. If they complain I may have to change my mind about accepting azw3 files.

As far as this is concerned, I don't mind submitting the mobi file separately for Bookapy (unlike AWZ3 for everywhere else), but as Switch noted, that option is going away due to changes in Calibre.

If you want to preserve the MOBI format requirement, let us know soon. I can easily maintain two separate versions (desktop and laptop), though that'll get difficult in the long run as Calibre continue churning out changes. Also, I've kept a VERY complete list of previous versions, retaining all of the relevant Apple dmg installation files, if anyone needs on for Bookapy postings.

And since the problem is in Chapter 43, it's way beyond the sample pages so I can't see it.

We've had this discussion before, and I'm pretty sure that Lazeez told me that authors can download copies of their own books, free of charge, although the form never suggests it. Instead, when you click on "Purchase", the mechanism is the same except it doesn't actually charge you anything—allowing you to confirm formatting—which is particularly handy for those authors who aren't comfortable formatting their own ePubs, AZW3s or Mobis.

my source file is a .HTML file

I tried saving the .docx file as a filtered HTML in Word and using that as the input to Calibre. The results were the same for .mobi.

As long as Bookapy accepts .AZW3 for Kindle, I'm fine. It seems to be a .mobi problem.

I'm not sure, as I typically only use block quotes when creating SOL-bound SOL files. For every other format, I use the specific paragraph style definitions, which deftly avoid the problem altogether.

ePubs follow the html instructions fairly strictly (with a few glaring exceptions), while SOL strips ALL but a few in-text html commands, forcing the use of the kludgy < blockquote>< /blockquote> command.

I typically only use block quotes when creating SOL-bound SOL files. For every other format, I use the specific paragraph style definitions

I used the term blockquote as a block of text, not as the HTML blockquote. I do it with left and right indents in my paragraph definition (in Word). My need is for a letter the character is reading. The letter is set off from the rest of the page by deeper left and right indents and is in italics.

I used the term blockquote as a block of text, not as the HTML blockquote. I do it with left and right indents in my paragraph definition (in Word). My need is for a letter the character is reading.

I do the same, though it works equally well with news broadcasts, road signs or even telepathic messages. Basically, anything that's NOT normal dialogue or descriptive.

However, I normally separate 'indented text' for 'block quote'. Indented text is what you get via Style Definitions, whereas block quotes is what you get when you rely on SOL's automatic formatting (i.e. not my own), since SOL specifically strips out ALL non in-line formatting.

Notice the editor is for EPUB and AZW3. Not MOBI.

Technically, you edit the source file, which transfers to the ePub and AZW3 formats, so it's possible it may (at some point) also transfer to the other formats if and when they adopt the functionality in future updates. But the idea is that you set it once, and it carries over. MOBI is inherently more limited (ex: number of available preset fonts, formatting options, etc.) That still, the 'open architecture' (i.e. no DRM) is still a major consideration, though it's hardly required (since anyone can manually remove the DRM protections whenever they want.

As far as MOBI going away, I don't know this for a fact, but I expect that simply means that the MOBI format will simply become unsupported going forward (i.e. no more updates of any kind), not that you won't be able to continue using it.

As for as SOL (Lazeez) is concerned, I agree with you. Given the added features both in the current standard and whatever they come up with in the future, AZW3 is the safer standard. Though I'd expect Lazeez to eventually develop his own anti-DRM for submission, or simply reject DRM submissions entirely. But beyond that, Bookapy supports ALL of my Amazon formatting (via ePub, at least), so I don't see it being an issue.

Ernest, this is the CSS for both EPUB and AZW3:

For the blockquote paragraphs:

block_16 {
display: block;
font-style: italic;
margin: 0 36pt 6pt;
padding: 0
}

For the normal paragraphs with the first line indented:

block_12 {
display: block;
text-indent: 21.6pt;
margin: 0 0 6pt;
padding: 0
}

I don't have an HTML editor to see what it is for the MOBI. But I bet it's not the same.

I find having the measurements in pt (points) interesting as all of the documents I've seen said you should use ems for all types of e-book margins and indents. My default paragraph and blockquote styles are:

body {
color: black;
display: block;
font-size: 1.0em;
font-style: normal;
font-variant: normal;
font-weight: normal;
line-height: 1.0em;
text-align: left;
text-indent: 1.5em;
padding-top: 1.0em;
margin: 0
}

quote {
color: blue;
display: block;
font-size: 1.0em;
font-style: italic;
font-weight: normal;
line-height: 1.0em;
text-align: justify;
text-indent: 0;
padding-top: 1.0em;
margin: 0 2.2em 0 2.2em
}

From your article: "As you can see, both the em and percent units get larger as the base font-size increases, but pixels and points do not."

Are you telling me that if pt is used, the reader can't change the font size on their e-reader? I doubt anyone with an e-reader would accept that.

ETA: Calibre's e-reader allows the font size to be changed.

Are you telling me that if pt is used, the reader can't change the font size on their e-reader? I doubt anyone with an e-reader would accept that.

No, readers should be able to specify that (though it's easy enough to override, but with a limited number of available fonts for ANY eBook format, it really doesn't matter, as you really can't monkey with them much anyway, since they 'default' to a specific font anyway.

It just means that .05pt; means that the image will be exactly that small (i.e. 5 image pixels on your display, typically whatever HD image capabilities you have), whereas 1.1em; is always 1.1 the width of each font's character size.

I wouldn't be surprised if it's not how it works actually, but that's how it should logically be.

For many monitors, point sizes and pixels are relatively close, especially on newer high-definition, sublineal (unable to distinguish with the naked-eye) screens. However, font sizes vary considerable!

the font size would increase, but the indent set in pt would not, staying exact same relative to the screen regardless of font size.

Yeah, that's what it seems to do.

For images it is often handy to use % for width which of course also scales.

The nice thing about that is that, since it uses relative adjustments, you only need to stipulate one dimension, rather than both width and height. There's nothing worse than manually calculating an image size and screwing up how it displays!

As far as the image width argument, that's also how WORD documents submitted to Kindle are processed, as 'relative' sizes, where the image typically take up the full page unless you specify the percentage of the page (or the maximum image size limits it).

I find having the measurements in pt (points) interesting as all of the documents I've seen said you should use ems for all types of e-book margins and indents.

Yeah, I use the em; sizing for everything, as it allows users to modify their favorite fonts themselves, without you overwriting it with you own standards (though I tend to override them on my own, simply to ensure that a particular formatting won't screw up the 'look and feel' of my own internal formatting).