EPUB output

[JSWolf]

Originally Posted by marliv

I used installed unicode fonts on my PRS-505 by extra css


but it don't work anymore for body text as in epub css there:


any ideas?

Try removing font-family: "Times New Roman", Times, serif; from the CSS. That's bad code given that it's looking for a font that doesn't exist.

[jayman]

Originally Posted by nrapallo

And if it IS surround by <pre> tags, then your best bet would be to edit the .html file(s) within the .epub (open the .epub up with a zip archiver and edit/extract the .html files) and do the following:

1) at the end of each line within the <pre> tags append a <br /> tag (or two <br /><br /> based on your preference for blank line separation), and

2) replace the surrounding <pre> ... </pre> tags with <p> ... </p> instead.

That should make sure the lines don't run into each other, but still allow each long line to wrap around so that you can see the ending...

BTW, in 2) above, you can play with indents using <p style="text-intent: 2em"> ... </p> or hanging indents using <p style="text-intent: 0em; margin-left: 2em"> ... </p>. Experimentation is your friend!

thanks! will try it.

[nrapallo]

Originally Posted by jayman

thanks! will try it.

Oops, just noticed a typo in the hanging indents <p> code; it should be: <p style="text-intent: -2em; margin-left: 2em">

[SkindleDX]

Hi,

I have input a pdf to output epub to create on Sigil a TOC, that's done and it works, if I open my epub file.

But now I have tried output the epub to a mobi file for my kindle dx, but the TOC is not showing up.

I have put everything on default.

Thank you so much!

Suhan

p.s. does the kindle speech text option also read german? thanks

[jayman]

Originally Posted by nrapallo

And if it IS surround by <pre> tags, then your best bet would be to edit the .html file(s) within the .epub (open the .epub up with a zip archiver and edit/extract the .html files) and do the following:

1) at the end of each line within the <pre> tags append a <br /> tag (or two <br /><br /> based on your preference for blank line separation), and

2) replace the surrounding <pre> ... </pre> tags with <p> ... </p> instead.

That should make sure the lines don't run into each other, but still allow each long line to wrap around so that you can see the ending...

BTW, in 2) above, you can play with indents using <p style="text-intent: 2em"> ... </p> or hanging indents using <p style="text-intent: -2em; margin-left: 2em"> ... </p>. Experimentation is your friend!

Is there any other faster way than doing it? This book I have has a lot of computer text and pre tags. Is there any way in conversion of the book from chm to epub to automatically have the <br /> tags at the end of each line inside the <pre> tags? Otherwise, going through each line is pretty laborious. thanks.

[nrapallo]

Originally Posted by jayman

Is there any other faster way than doing it?

I usually use a RegEx capable Text Editor to do this type of substitution, but only when it's localized to one contiguous span of text. It may be harder to do this "globally" for every <pre> ... </pre> simultaneously. Your best bet would be to set up a macro but this type of stuff is very hard to "pull off" without a lot of trial and error. And to boot, it's probably ever going to be used ONCE since your next book may be formatted differently and "break" your macro!

This book I have has a lot of computer text and pre tags.

Are you sure it's the <pre> tags not being properly recognized by your ebook reader/iPhone? Perhaps, it could be the way it's formatted. Can you post a snippet of one or better yet PM me a copy so that I can further test it. I usually create ebooks from .html and can easily explode .chm to .html using the following code noted in our CHM wiki:

C:\> hh -decompile Destdir Source.chm

However, then to properly structure an ebook from that can take a lot of effort since you usually have to manually reconstruct the index and ordering/links of the .html pages.

Is there any way in conversion of the book from chm to epub to automatically have the <br /> tags at the end of each line inside the <pre> tags? Otherwise, going through each line is pretty laborious. thanks.

I've only manually converted .chm to .html and then to .epub / .prc, but only after I've "cleansed" the extracted .html files. I'm not sure how calibre does this conversion, but I would look at two-stage solution as I do manually.

In the end, this type of conversion DOES take a lot of elbow grease...

[DoctorOhh]

You have a lot of good ideas. I'm glad that someone that knows what they're doing is helping out.

Originally Posted by nrapallo

Are you sure it's the <pre> tags not being properly recognized by your ebook reader/iPhone? Perhaps, it could be the way it's formatted.

One thought from an amateur. The problem isn't the "<pre> tags not being properly recognized by your ebook reader" the problem is that the tags are properly recognized.

This causes code to scroll right off of the screen. It's a feature not a bug, designed so the code is presented exactly how the programming book wants it seen. The trouble, a reader is only so large and this code prevents wrapping before the end of the given code.

If the user has many books like this a combination of a larger reader or landscape vice portrait might be in order.

[nrapallo]

Originally Posted by dwanthny

This causes code to scroll right off of the screen. It's a feature not a bug, designed so the code is presented exactly how the programming book wants it seen. The trouble, a reader is only so large and this code prevents wrapping before the end of the given code.

If the right margin on the ebook reader is NOT honoured, then it's a bug!

If the user has many books like this a combination of a larger reader or landscape vice portrait might be in order.

Another mode of attack would be to change the font to a fixed point and be as small as is legible, so as to fit the max. amount of line text on the screen before it runs off. If the original .chm had a finite length (which is common for letter-sized pages) then perhaps this approach may work. In my reader, I would simply use:

<pre style="font-family: smallfont; font-size: xx-small">...</pre>

and the text would appear like this .

Within .epub files, that syntax may have to be change to something like

<pre style="font-family: courier; font-size: 1">...</pre>

If this doesn't work, then cropping the lines or reflowing them would be the only alternative (other than getting a large screened ebook reader... ). That's why you would need to remove the <pre> tags, reflow the text using <p> tags and then manually breaking each line with <br /> to avoid them running into each other.

Any way you do it, if the original (e)book was not formatted for small screened ebook readers, then doing so afterward will NOT yield good results! That's why I avoid .pdf ebooks at all cost even though they are wonderfully presented and visually stunning most of the time; substance over form?

[DoctorOhh]

Originally Posted by nrapallo

If the right margin on the ebook reader is NOT honoured, then it's a bug!

Again, not a bug, just outside of the epub specification. <pre> tags don't respect the right margin of any html renderer. Just like the code tags here break the liquid format of this board, when you resize the font, it goes right off the screen.

Originally Posted by nrapallo

Another mode of attack would be to change the font to a fixed point and be as small as is legible, so as to fit the max.

A fixed font combined with landscape might fit most books to a six inch reader. Nice suggestion.

[jayman]

Originally Posted by nrapallo

If the right margin on the ebook reader is NOT honoured, then it's a bug!



Another mode of attack would be to change the font to a fixed point and be as small as is legible, so as to fit the max. amount of line text on the screen before it runs off. If the original .chm had a finite length (which is common for letter-sized pages) then perhaps this approach may work. In my reader, I would simply use:

<pre style="font-family: smallfont; font-size: xx-small">...</pre>

and the text would appear like this Attachment 55624.

Within .epub files, that syntax may have to be change to something like

<pre style="font-family: courier; font-size: 1">...</pre>

If this doesn't work, then cropping the lines or reflowing them would be the only alternative (other than getting a large screened ebook reader... ). That's why you would need to remove the <pre> tags, reflow the text using <p> tags and then manually breaking each line with <br /> to avoid them running into each other.

Any way you do it, if the original (e)book was not formatted for small screened ebook readers, then doing so afterward will NOT yield good results! That's why I avoid .pdf ebooks at all cost even though they are wonderfully presented and visually stunning most of the time; substance over form?

Thanks for the suggestion. Will try it when I get home. Thanks again.

[starrigger]

Don't know if this has been brought up before or not. Something that's been bugging me (in a minor way) is blank line spaces. Generally when I convert something to epub, I tell it to remove blank lines between paragraphs. (Or I might run an existing epub through to do that, if it was made with spaces between paragraphs.) It generally works well.

The problem is, there are some lines you want left blank: scene breaks, spaces between chapter number and text, etc. Is there any way of telling Calibre to leave these blanks alone? I'm not sure how it would know the difference, but Calibre is a very clever program, and I wondered if there was a way.

[Phil_C]

Originally Posted by starrigger

Don't know if this has been brought up before or not. Something that's been bugging me (in a minor way) is blank line spaces. Generally when I convert something to epub, I tell it to remove blank lines between paragraphs. (Or I might run an existing epub through to do that, if it was made with spaces between paragraphs.) It generally works well.

The problem is, there are some lines you want left blank: scene breaks, spaces between chapter number and text, etc. Is there any way of telling Calibre to leave these blanks alone? I'm not sure how it would know the difference, but Calibre is a very clever program, and I wondered if there was a way.

Exactly! The answer is supposed to be a lot of editing in HTML, which I don't do. Not all of us have the time/inclination to spend on this. My collection of several hundred ebooks (mostly formatted by me in Book Designer) is in lrf. I foresee that someday these will have to be converted to epub.

It seems to me that the Calibre conversion process ought to recognize this situation. After all, if there is a blank line in the existing document, there must be a reason for it. And the conversion process should see and account for it. Why is the current option all or nothing? Why can't Calibre see a blank line and just leave it there?

[Starson17]

Originally Posted by Phil_C

Why can't Calibre see a blank line and just leave it there?

I can't answer this, and I have no idea what the problem is. I'm sure it's quite obvious to you and to those who experience your problem, but not to others (at least not to me). Of course, you have no obligation to clearly explain what happens and why you don't like it, but there are some developers out there, and some of them may be willing to give you a hand by at least looking at the issue to see if it has a simple solution.

Even if there's no one who can help you, I'm interested in what the problem is, if you feel like giving more detail.

[Phil_C]

Originally Posted by Starson17

I can't answer this, and I have no idea what the problem is. I'm sure it's quite obvious to you and to those who experience your problem, but not to others (at least not to me). Of course, you have no obligation to clearly explain what happens and why you don't like it, but there are some developers out there, and some of them may be willing to give you a hand by at least looking at the issue to see if it has a simple solution.

Even if there's no one who can help you, I'm interested in what the problem is, if you feel like giving more detail.

starrigger explained it above, but Ill try again.

There are certain blank lines in most any novel, e.g. to denote a change in scene, or after an epigraph at the beginning of a chapter, or after a chapter title.

Calibre has only two choices for paragraph spacing: ALL or NONE.

So when converting lrf to epub, Calibre either: 1) places blank lines between ALL paragraphs of the novel, or 2) removes ALL blank lines including the ones I want to keep as in my examples above.

What I want is to keep the original paragraph spacing --- none, except for special cases as above.

The Calibre manual says something about editing the HTML code in each individual ebook to account for this. That is no solution when I want to convert hundreds of books from lrf to epub for use on future readers.

It seems to me that if a blank line exists in my lrf, it must somehow be coded as such (how else could it be there?), so Calibre ought to be able to leave it as is.

In the Calibre Look and Feel conversion choices, there is a box for removing spaces between paragraphs, and a box for adding blank lines between paragraphs. I don't want either. If I leave both unchecked, the converted epub SHOULD retain the original spacing from the original ebook. Instead, the result is the same as if I checked the add blank lines box.

If this could be corrected, I could easily convert my hundreds of files to epub. All help is appreciated.

[Starson17]

Originally Posted by Phil_C

starrigger explained it above, but Ill try again.

That was clear, and I appreciate it.

If this could be corrected, I could easily convert my hundreds of files to epub. All help is appreciated.

I still don't know if I can help. I particularly am not interested in working on lrf format (sorry, it's deprecated and I don't use it), but if your problem lies elsewhere, I might be interested. To find out, turn on debug and convert a problem file to EPUB. Then look in the debug folders and advise when the problem appears. Is it in the very first folder, or later? Is this an lrf problem only, or a conversion problem in general? Does the problem appear when going to epub from HTML, LIT or any other formats?