Next format for calibre to generate?

[cartz]

My vote is for .imp

[pepak]

Originally Posted by llasram

I'm feeling on a bit of format-generation spree at the moment. Now that calibre has LIT-generation support, which format should I add next? No promises on a timeline, though .

Personally, I would prefer updating the LRF support. At the very least fixing the incorrect handling of nested tags, as per ticket #1406, and if at all possible #1391 and #998.

[llasram]

Originally Posted by pepak

Personally, I would prefer updating the LRF support. At the very least fixing the incorrect handling of nested tags, as per ticket #1406, and if at all possible #1391 and #998.

Given that you have a 505 and not a 500, may I ask why you aren't just using EPUB?

[llasram]

Originally Posted by kovidgoyal

calibre already does cover extraction via full rasterization of EPUBs (see epub-meta) or just add an EPUB to the GUI

Oh, sweet! Way to do all the hard work, Kovid .

[Amalthia]

Originally Posted by llasram

Given that you have a 505 and not a 500, may I ask why you aren't just using EPUB?

I don't use ePub because I already know how to create nice looking ebooks with LRF and last time I heard ePub has a size limitation on how long the book can be, before you have to add some sort of page break? or story break?

[kiklop74]

Software that draws epub in sony reader renders everything using latin-1 character set and not utf-8 hence the format is useless for any other non-latin language text.

That is the reason I do not use epub.

BTW speaking of which is there a chance to modify recipe behaviour to convert downloaded pages into real unicode (utf-16)? Kovid?

[llasram]

Originally Posted by Amalthia

I don't use ePub because I already know how to create nice looking ebooks with LRF and last time I heard ePub has a size limitation on how long the book can be, before you have to add some sort of page break? or story break?

Most of the options to any2epub are the same as for any2lrf. The size limitation is per "markup stream" (individual HTML file) in the EPUB container, but any2epub will automatically split the input up as necessary -- with everything except the handful of book-length works with no chapter breaks you won't even notice it. The benefit is that the AdobeDE rendering engine is a much much better HTML renderer than html2lrf, so you get much higher-fidelity output.

[llasram]

Originally Posted by kiklop74

Software that draws epub in sony reader renders everything using latin-1 character set and not utf-8 hence the format is useless for any other non-latin language text.

That is most definitely not true. EPUB OPS 2.0 documents are XHTML, which inherits the XML default encoding of UTF-8. Accurate rendering then just means ensuring that all encoded glyphs are available, which is merely a matter of embedding font containing any characters not provided by the Adobe default set.

Originally Posted by kiklop74

BTW speaking of which is there a chance to modify recipe behaviour to convert downloaded pages into real unicode (utf-16)? Kovid?

What do you mean by "real unicode"? UTF-8 and UTF-16 are just different encodings of the same character set.

[pepak]

Originally Posted by llasram

Given that you have a 505 and not a 500, may I ask why you aren't just using EPUB?

Because it is slow, doesn't do full justification and it's intra-document links work incredibly poorly. Kovid says that the 505 crashes less often with ePUB than with LRF, but my experience is opposite.

I am not averse to using ePUB. Once a newer firmware with those problems fixed appear, I will simply convert my collection to ePUB and use that, but at the moment, the implementation is too poor to use.

[llasram]

Originally Posted by pepak

Because it is slow,

Crossing boundaries of complex streams can be slow, but that doesn't really affect normal reading. What's the use case where you find using EPUB noticeably slower than LRF?

Originally Posted by pepak

doesn't do full justification

A fair cop, although it should be noted that LRF doesn't allow ragged right and does a pretty terrible job of full justification .

Originally Posted by pepak

and it's intra-document links work incredibly poorly

How so? Example?

Originally Posted by pepak

Kovid says that the 505 crashes less often with ePUB than with LRF, but my experience is opposite.

I haven't noticed major crashing issues for normal content with either, to be honest.

Although more fair to just say that I'm not terribly interesting in improving the LRF support, which would probably require a re-write to make the HTML->LRF engine work as a completely CSS-based HTML renderer. However, if you or someone else would be interested in doing it, I'd be willing to help.

[pepak]

I would, if I knew Python. Unfortunately, my focus is on a different languages.

[kiklop74]

Originally Posted by llasram

That is most definitely not true. EPUB OPS 2.0 documents are XHTML, which inherits the XML default encoding of UTF-8. Accurate rendering then just means ensuring that all encoded glyphs are available, which is merely a matter of embedding font containing any characters not provided by the Adobe default set.

Would you care to elaborate this? The default font in sony reader has all the glyphs I need for the texts I read in Serbian language and they show perfectly in LRF format. However any text in epub format shows these as question marks. Why would I need to embed any font if current font already has the glyphs, or epub rendering uses some other font?

What do you mean by "real unicode"? UTF-8 and UTF-16 are just different encodings of the same character set.

The real unicode means that every character takes 4 bytes and not arbitrary size as in utf-8.

[llasram]

Originally Posted by kiklop74

Would you care to elaborate this? The default font in sony reader has all the glyphs I need for the texts I read in Serbian language and they show perfectly in LRF format. However any text in epub format shows these as question marks. Why would I need to embed any font if current font already has the glyphs, or epub rendering uses some other font?

The Reader LRF renderer actually has a different set of default fonts than the Reader AdobeDE EPUB renderer. It's possible that the glyph complement of the LRF default fonts cover the the codepoints you're using while the EPUB set does not. Could you post or link to an example source document?

Originally Posted by kiklop74

The real unicode means that every character takes 4 bytes and not arbitrary size as in utf-8.

Ah. UTF-16 actually uses 2 bytes for characters in the basic multilingual plane and 4 bytes for characters which are not. You must be thinking of UTF-32? Either way, what benefit do you perceive?

[llasram]

Originally Posted by pepak

I would, if I knew Python. Unfortunately, my focus is on a different languages.

It's easy to learn and incredibly elegant!

[kiklop74]

Originally Posted by llasram

The Reader LRF renderer actually has a different set of default fonts than the Reader AdobeDE EPUB renderer. It's possible that the glyph complement of the LRF default fonts cover the the codepoints you're using while the EPUB set does not. Could you post or link to an example source document?

Take a look at the attached epub file. It was produced using feeds2epub from command line.

feeds2epub --test B92

Originally Posted by llasram

Ah. UTF-16 actually uses 2 bytes for characters in the basic multilingual plane and 4 bytes for characters which are not. You must be thinking of UTF-32? Either way, what benefit do you perceive?

I was thinking that by specifying everything un UTF-32, assuming that the font is also unicode, we will have character match 1-1 and than it should display everything correctly.