Mobipocket output

[llasram]

Originally Posted by Gudy

Unless I'm missing something major, the whole mechanism seems to be completely b0rked in 0.4.133.

It appears to work just fine to me. I'm going to guess that the source you're converting from contains CSS with a more specific rule which is trumping your override rule's single-element 'p' selector. Try something like "html body p { text-indent: 1em; margin: 0; }". If that doesn't work either, open a bug on the calibre trac and attach a file which is failing to convert as expected.

Originally Posted by Gudy

As a general usability complaint, I find it rather unacceptable that I need to resort to handcoding CSS in order to set something as basic as a paragraph indent in EPUB and MOBI files, especially since there is a far simpler way available for LRF files.

Hmm. I may agree with you, especially given situations like what I believe is your current issue. Paragraph marking is probably one of the formatting areas users most frequently wish to control, and might deserve a direct interface which can use use some sort of heuristics to detect normal paragraphs and style them accordingly.

Originally Posted by Gudy

In the same vein, having to use XPath expressions to detect chapter headings pretty much ensures that I will never use that feature in calibre but will instead hand-massage the html file before import.

What sort of interface would you prefer to see?

-Marshall

[kovidgoyal]

Originally Posted by Gudy

As a general usability complaint, I find it rather unacceptable that I need to resort to handcoding CSS in order to set something as basic as a paragraph indent in EPUB and MOBI files, especially since there is a far simpler way available for LRF files. In the same vein, having to use XPath expressions to detect chapter headings pretty much ensures that I will never use that feature in calibre but will instead hand-massage the html file before import.

Paragrpah indents will eventually be settable with a simple control. As for XPath, I think it is easier to use than the various LRF settings, if you spend 5 minutes reading the XPath tutorial in the calibre User Manual

[Amalthia]

Originally Posted by kovidgoyal

Paragrpah indents will eventually be settable with a simple control. As for XPath, I think it is easier to use than the various LRF settings, if you spend 5 minutes reading the XPath tutorial in the calibre User Manual

I think for people unfamilar with css or Xpath it's not as easy to figure out what you need to do to set settings. I think the LRF conversion is more intutive for people that are starting out with little or no knowledge of programming or html coding.

I'm still not quite sure what to do with xpath but I have used command line to try some stuff out?

And I've also run into troubles using css to make paragraph indents. The code should work but it doesn't always? I found that I have to convert the file. Turn off the program, re-open and convert the file again and on the second pass the indents stick. It's worked like that two times...and maybe with the newer version the css you gave me will do the trick on first try.

But considering Epub and Mobi are still in beta I expect a few bumps in the road and am willing to try and figure out what's happening.

However, I don't think I'm your average user.

edit: forgot to mention...having said everything I said I'm still rather excited about the ablity to set paragraph indents like I do for the LRF settings.

[kovidgoyal]

At some point I will get around to coding an XPath expression builder, but for the time being, you have to enter them by hand.

[Gudy]

Originally Posted by Amalthia

And I've also run into troubles using css to make paragraph indents. The code should work but it doesn't always? I found that I have to convert the file. Turn off the program, re-open and convert the file again and on the second pass the indents stick. It's worked like that two times...and maybe with the newer version the css you gave me will do the trick on first try.

Some more experimenting revealed that this is precisely the problem, yes. Changes in the CSS Override input box only take effect after completely restarting Calibre. This is true, at least for Mobipocket, in both 0.4.133 and 0.4.134

Originally Posted by kovidgoyal

Paragrpah indents will eventually be settable with a simple control. As for XPath, I think it is easier to use than the various LRF settings, if you spend 5 minutes reading the XPath tutorial in the calibre User Manual

I'm definitely looking forward to the simple settings. :-)

As for XPath vs. the LRF settings, with the latter it took me 30 seconds of thinking about what I'm supposed to enter into those fields and exactly one failed attempt until I had the chapters detected and page breaks inserted exactly where I wanted them. I have no doubt that XPath is far more powerful and versatile a tool, but I doubt I would have gotten up to speed with XPath within two minutes...

[mtravellerh]

Originally Posted by Gudy

Some more experimenting revealed that this is precisely the problem, yes. Changes in the CSS Override input box only take effect after completely restarting Calibre. This is true, at least for Mobipocket, in both 0.4.133 and 0.4.134



I'm definitely looking forward to the simple settings. :-)

As for XPath vs. the LRF settings, with the latter it took me 30 seconds of thinking about what I'm supposed to enter into those fields and exactly one failed attempt until I had the chapters detected and page breaks inserted exactly where I wanted them. I have no doubt that XPath is far more powerful and versatile a tool, but I doubt I would have gotten up to speed with XPath within two minutes...

Ah, to be quite plain about it, Kovid's XPath default expression is REALLY a catch-all put there to well catch nearly all chapters. If you have a specific file, one simple expression including a tag per hierarchic level is generally enough.

It might be a good habit for anyone involved in bookmaking in some way to just mark TOC files (parts, sections, chapters) in a uniform hierarchical way with tags or at least with uniform class labels and not use those tags or labels for other tasks.

[Gudy]

Originally Posted by mtravellerh

It might be a good habit for anyone involved in bookmaking in some way to just mark TOC files (parts, sections, chapters) in a uniform hierarchical way with tags or at least with uniform class labels and not use those tags or labels for other tasks.

Probably, yes. The thing is, I don't often make books myself. I've converted about two dozen books to FB2 for my own use using Bookdesigner, and this was my first attempt to go beyond that single format. So I'm still working out an optimal work flow. I've gone Word .doc -> Bookdesigner -> .html -> Cleanup with VIM -> Calibre with this one, but that's probably not optimal at all, especially since the BD html output leaves a lot to be desired as a basis for further work on a book.

[Amalthia]

I have a question about <br > tags. For some reason when I convert to mobi there is an extra space added after using them. So they kind of act like paragraph breaks. Is there anyway to make the break tag work like a regular break tag? I don't use break tags often but they are a big part of my TOC and with LRF my TOC is single spaced. I'd like to replicate that result with my mobi files.

[giddion]

Is it possible now that Calibre has MOBI output to save the updated meta data?

I don't want to do the full convert because I don't want to reformat the ebook, I'm happy with the format, I just want to put a better cover in the file and add series information to the meta.
Mobi2Mobi_gui will let me update some of the meta but it doesn't give series and it doesn't have the great lookup function Calibre has to find the correct cover graphic and meta data.

[llasram]

Originally Posted by Amalthia

I have a question about <br > tags. For some reason when I convert to mobi there is an extra space added after using them. So they kind of act like paragraph breaks. Is there anyway to make the break tag work like a regular break tag? I don't use break tags often but they are a big part of my TOC and with LRF my TOC is single spaced. I'd like to replicate that result with my mobi files.

It sounds like what's probably going on is that you have <br/> tags directly in the <body/>. In XHTML and HTML <br/> tags aren't actually allowed there, so the way they get interpreted varies with the renderer. MSReader and (most? all?) the Mobipocket viewers will renderer a <br/> in the <body/> following a block as a blank line, but AdobeDE will only render the blank line if there are two <br/> tags.

Anyway, try wrapping your table of contents or whatever in a <div> </div> tags so that your <br/> tags aren't directly in the <body/>.

[llasram]

Originally Posted by giddion

Is it possible now that Calibre has MOBI output to save the updated meta data?

Er, yes? It should be automatic. If you import a Mobipocket version, update the metadata, then "save to disk" as Mobipocket, it should just write out a copy of the Mobipocket version w/ the updated metadata.

[kovidgoyal]

Originally Posted by llasram

Er, yes? It should be automatic. If you import a Mobipocket version, update the metadata, then "save to disk" as Mobipocket, it should just write out a copy of the Mobipocket version w/ the updated metadata.

It will in the next release. There were a couple of bugs in the mobipocket metadata setting code that needed to be fixed first.

[giddion]

Originally Posted by kovidgoyal

It will in the next release. There were a couple of bugs in the mobipocket metadata setting code that needed to be fixed first.

Ok thank you very much, I was about to reply that I have tried the save as mobi and the cover graphic isn't being saved. Have to admit though I didn't double check whether the rest of the meta updated, was going to go back and check that before my reply - can still check which elements updated and which didn't if it would be helpful.

[Amalthia]

Originally Posted by llasram

It sounds like what's probably going on is that you have <br/> tags directly in the <body/>. In XHTML and HTML <br/> tags aren't actually allowed there, so the way they get interpreted varies with the renderer. MSReader and (most? all?) the Mobipocket viewers will renderer a <br/> in the <body/> following a block as a blank line, but AdobeDE will only render the blank line if there are two <br/> tags.

Anyway, try wrapping your table of contents or whatever in a <div> </div> tags so that your <br/> tags aren't directly in the <body/>.

yeah I tried that but it only worked for one table of contents and I have about 5 or 6 stories mixed into one file and they have summary, title, author notes and etc...it doesn't look so great when it's paragraph indented but when I tried to use css to remove the paragraph indents for just those sections it didn't work.

Basically, yes I'm using <br > tags within the body of the html but what I still don't get is why when I convert to LRF the <br > tags work like they do on web browsers but when I convert to MOBI it adds an extra line.

[llasram]

Originally Posted by Amalthia

Basically, yes I'm using <br > tags within the body of the html but what I still don't get is why when I convert to LRF the <br > tags work like they do on web browsers but when I convert to MOBI it adds an extra line.

The any2* tools are mostly for e-book conversion, and in MSReader and Mobipocket a <br/> tag there will create a new blank line. If calibre didn't convert such <br/>s then people converting books from those formats would find that they were missing blank lines in e.g. their EPUB versions.

More abstractly, the problem is that you should never be using the <br/> tag in hand-written HTML. You should use semantic markup around anything you want to be rendered as a block-level box and use CSS to set appropriate display and margins.

For example:

<div class="lines">
  <div class="line">This is on a line!</div>
  <div class="line">This is on another line!</div>
</div>

Then have CSS like:

.lines { margin: 0; }
.line { margin: 0; }

The CSS2.1 spec has lots of examples.