EPUB output

[DoctorOhh]

Originally Posted by mwbiggs

5. ERROR: The Case for Lilith 1st ed v021 epub10 - Mark Biggs.epub/The Case for Lilith_1st_ed_v021_epub10_split_001.htm(207): attribute "link" not allowed at this point; ignored
6. ERROR: The Case for Lilith 1st ed v021 epub10 - Mark Biggs.epub/The Case for Lilith_1st_ed_v021_epub10_split_001.htm(207): attribute "vlink" not allowed at this point; ignored

These two errors are pointing out attributes that control link color for visited and unvisited links. Seems odd in an epub and even on a web site they are usually controlled via CSS.

You might consider opening the html file in Sigil then saving that as a epub, then running it through a epub to epub conversion in calibre to set font size indent etc... Sigil has html tidy built in to clean obvious errors.

Or you can do your editing in Open Office.org's Writer and save to epub using the Writer 2 ePub extension downloaded here. The developer has a forum here at MobileRead for this extension.

[seajewel]

I actually haven't noticed the problem of Calibre removing Scene Breaks. I also set it to remove lines between paragraphs--I hate wasting space that way, personally, and I just double checked, and at least in the books I converted, the scene break lines were not removed. I am bothered, however, that lines that are meant to be poetry, for instance, at the beginning of a chapter, have the first line indented after conversion, instead of being all orderly without indentation as in the original book before conversion. So a poem that would look like

Random poetry
blah blah blah

gets converted to

Random poetry
blah blah blah

It's a minor issue compared to removing scene breaks, but I wonder if there's any way for calibre to detect this sort of thing and not indent the first line of poems. I have to have the indents because I remove lines between paragraphs, else the page looks too busy, but I would prefer not to have indents in poetry.. any thoughts?

ETA: i guess i should just try to mess around with some editing by hand through SIGIL. I just wanted to add that I love Calibre, and it has made my experience owning a Sony 505 the best that it could be! Thanks!

Originally Posted by kovidgoyal

There is no reliable way to distinguish the cases, for example, centered text may or may not need a blank line before it (instead it could have a larger margin-top and margin-bottom), or the author may not have intended it to have spaces. While a given technique may work on some set of cases, it wont work on all, so rather than have "magic" behavior, I chose to keep it simple and predictable.

[kovidgoyal]

Off the top of my head, that would cause problems with consecutive lines of short dialog, for instance.

[Ticallion]

I'm not sure if this has been reported yet, I hope it will prove helpful though. I've been wanting and trying to convert my BookDesigner created LRFs to EPUB, but noticed Calibre kept messing up the links and making them either not function at all or jump to wrong pages. Such as selecting Chapter 1 would jump to Chapter 2, then using the back-link on Chapter 2 would jump to Chapter 1 instead of going back to the TOC as it should and does in the original LRF.

Well after trying once more, I opened a Converted EPUB in Sigil to check the code. I noticed what's been happening is Calibre is adding "#xx" where xx represents some numbers, to the end of each link both in the TOC and chapter headers. An example of a chapter header:

<a class="calibre5" href="../Text/53.xhtml#74">Part 1</a>

After removing "#74" in Sigil then saving the EPUB, now the link is working properly. Is there some reason Calibre is adding that extra stuff after ''xhtml'' and is there some way to perhaps prevent it? I have over 80 LRFs I'd like to convert to EPUB.


EDIT: Alright, now I know how to preserve spaces in the converted EPUB too. It seems Calibre is at least putting some code where the space should be. For example:

<p class="calibre1"><span>Text here.</span></p>

<p class="calibre1"></p>

<p class="calibre1"><span>Text here.</span></p>

The line "<p class="calibre1"></p>" is where the space is supposed to be, but it's not being read or whatever after conversion. So simply using find and replace, I changed the calibre1 part of the line to say calibre5, then in the stylesheet made calibre5 have a top and bottom margin setting of 1em. Now the output file looks exactly like the LRF.

So overall, the process involves a bit of work but not too much. First removing all the "#XX" parts then replacing the space codes.

[Phil_C]

Originally Posted by Ticallion

EDIT: Alright, now I know how to preserve spaces in the converted EPUB too.

This would be a lot of work for 700+ LRF's.

This goes back to the issue where Calibre ought to be able to retain the original LRF paragraph spaces. I don't want to add spaces throughout. I don't want to remove spaces throughout. Just leave my spacing alone!

Instead, with neither of these options checked, Calibre ruins my epub by adding spaces between all paragraphs (AND the existing TOC entries).

I'm still hoping that Kovid or one of the developers here can do something about this. That would make all of our LRF's future-proof.

[Ticallion]

No doubt it is tedious work, especially since it seems from EPUB to EPUB the calibre# changes codes. In one EPUB the paragraphs will use calibre10 then then the next it could use calibre15, not sure why it does that when they're all made in the same fashion in BookDesigner.

From what I understand though, it is someone else who made the LRF plugin and has abandoned it. Seems like what needs to be done is make the plugin change that space line code to input a different calibre# instead of one that is matching the paragraph code.

[DoctorOhh]

Originally Posted by Ticallion

The line "<p class="calibre1"></p>" is where the space is supposed to be, but it's not being read or whatever after conversion. So simply using find and replace, I changed the calibre1 part of the line to say calibre5, then in the stylesheet made calibre5 have a top and bottom margin setting of 1em. Now the output file looks exactly like the LRF.

So overall, the process involves a bit of work but not too much. First removing all the "#XX" parts then replacing the space codes.

Now that you have specific information, create one ticket for each problem you identified with the details you've discovered. Maybe one or both problems will be fixable without massive man-hours.

Originally Posted by Phil_C

This goes back to the issue where Calibre ought to be able to retain the original LRF paragraph spaces. I don't want to add spaces throughout. I don't want to remove spaces throughout. Just leave my spacing alone!

Your spacing only exists in the Sony reader.

If LRF was a simple html container like Lit, Mobi or ePub then it would be easy, but LRF is not that simple. LRF doesn't use CSS or html defined paragraphs, its a propriety format that uses objects defined by Sony.

Kovid refused to even provide an avenue from LRF for the longest time. But he finally broke down and took the many hours needed and wrote a plugin to allow folks to easily convert their lrf files to other formats such as epub. This conversion provided a perfectly functional epub, not a perfect duplicate of the original lrf.

Thank You Kovid!

Originally Posted by Phil_C

Instead, with neither of these options checked, Calibre ruins my epub by adding spaces between all paragraphs (AND the existing TOC entries).

Calibre doesn't ruin your ePub, you ruin your lrf trying to change it to something its not. Calibre does its best interpreting a propriety format, then gives you options to tweak it. If you wish perfection edit the resultant ePub with Sigil.

Originally Posted by Phil_C

I'm still hoping that Kovid or one of the developers here can do something about this. That would make all of our LRF's future-proof.

Maybe there is a developer on this forum that has 1000s of LRFs and this person will see the need to fine tune the LRF input plugin. Until this happens you might want to lobby Sony for a converter to epub since they decided to kill the LRF format in the first place.

You could use Google and look elsewhere for a converter. I'm relatively sure you won't find one that provides a more functionally readable output then calibre, but if you do find a great alternative please let us know.

[Ticallion]

Okay, I submitted two tickets for each problem. Looks like there are a ton of other things on there though.

Something else I've noticed after some testing; it seems like the code is a lot cleaner and easier to work with when you do LRF to MOBI to EPUB, instead of straight LRF to EPUB. When doing MOBI to EPUB, you get proper "calibre#" codes in the stylesheet and not much else. But doing that style doesn't even show the converted spaces in the code.

When doing LRF to EPUB, you only get a few calibre codes and then some other ones that show as ".bs#". Seems to mess up the title page (if you have one) when you do some tweaking. Strange.

[DoctorOhh]

Originally Posted by Ticallion

Okay, I submitted two tickets for each problem. Looks like there are a ton of other things on there though.

You can never tell what might be fixed. At least with a ticket it won't get lost and has a chance.

Have you looked in debug at the initial lrf2html to see what it looks like?

[Phil_C]

Originally Posted by dwanthny

If LRF was a simple html container like Lit, Mobi or ePub then it would be easy, but LRF is not that simple. LRF doesn't use CSS or html defined paragraphs, its a propriety format that uses objects defined by Sony.

Thanks for the insight into the problem.

Originally Posted by dwanthny

Maybe there is a developer on this forum that has 1000s of LRFs and this person will see the need to fine tune the LRF input plugin.

I live in hope.

Originally Posted by dwanthny

Until this happens you might want to lobby Sony for a converter to epub since they decided to kill the LRF format in the first place.

Agreed. I think Sony made the right decision to switch to epub, but they absolutely and automatically should have furnished a converter. But I think we all know that the words "lobby Sony" are synonymous with knocking your head against a wall.

[Phil_C]

Originally Posted by Ticallion

Okay, I submitted two tickets for each problem.

Thanks for that...

[Ticallion]

He closed the tickets with this quote: "calibre's LRF input plugin only supports LRF created by calibre. I have no interest in addng support for BD LRF files. Patches welcome."

I have no idea how to make patches, isn't there anyone around who knows about fixing this type of thing? Actually, this problem exists for non-BD LRFs as well, from what I recall. I've tried to convert other LRFs to EPUB, the spacing problem is still there. I'm sure the link bug is as well.

[johnb123]

Probably a dumb question, but when I convert some .lit of .rtf to epub there are unwanted line feeds in the middle of a sentence. The first occurs in the middle of a line, then it adds another. In Sigil's code view there is a <p> before each line and a </p) ath the end.
Deleting these in the html view gives a continuous document with no breaks.

How do I convert properly with Calibre, or amend the CSS file to better display the files?

thanks.

[DoctorOhh]

Originally Posted by johnb123

How do I convert properly with Calibre, or amend the CSS file to better display the files?

The odds are high that these form breaks exist in your source file. As far as basic format structure is concerned, calibre is very good at converting Lit and rtf files.

GIGO

You have two choices.

1. Clean up or find a different source file.
or
2. Clean up the output file.

[Ticallion]

Could anyone give some idea about how to make a user patch or even what specific files would need tweaking for fixing up the LRF to EPUB conversion? i know next to nothing about programming, but thought it'd be worth a try unless there would be a lot of lines of code that need to be changed.