New Software: convert plain text files to epub/mobi format

[DaleDe]

Originally Posted by RobertDDL

if only e-book readers (or apps) would give it a little effort -- like, building a TOC from the header tags, which should be a trivial exercise. Or are there those that do?

I really like your UI. Perhaps it could front end Pandoc for even a more versatile product. See our wiki.

Dale

[RobertDDL]

Originally Posted by DaleDe

I really like your UI. Perhaps it could front end Pandoc for even a more versatile product. See our wiki.

Dale

I think this was meant to be directed at the OP, MobiEpubMaker (who, sadly, seems not to participate in this discussion)?

[RobertDDL]

Originally Posted by eschwartz

Let's go one step further, and allow you to manually specify the ToC.
Hey, now we have two files. Why not ZIP them so they stay together? Oooh, look -- EPUB!

I consider EPUB to be a rather crappy format, with way too much unnecessary complexity. You cannot simply create an EPUB file from scratch with a text editor unless you are an expert, while this is easily done with HTML. Chapters have to be separate files, which makes no sense at all and is a major nuisance with editing. I suppose some of EPUB's annoying complexity is owed to its DRM capabilities, but, well, you know what I think about that

Sure, I can parse an HTML file and insert a TOC at its top, but this TOC would not be accessible from within the text while I'm reading, as it is with EPUB or MOBI. It would be an easy task for the e-reader to parse the HTML file upon loading and create a TOC on the fly, but as far as I know, this isn't done. (On my PC, LibreOffice does it nicely enough, though there is a bug when I just open the HTML file -- when I create an empty document and import the HTML file, it works well.)

Originally Posted by eschwartz

AS far as reading HTML goes... I do know the Kindle supports TXT as a format, and will render it in HTML if it is in fact formatted in HTML. The extension must still be .txt for some reason.

I should have said "zipped HTML" -- it's a major advantage to have text, images and style sheet together in a single file. Since you already know about my paranoia, let me voice the suspicion that HTMLZ is shunned by the publishing industry because it doesn't offer DRM capabilities. It would still be nice to have it available, because it would be by far the easiest format to create and to edit, but there seems to be very little suport for it by any reading devices or software.

[MobiEpubMaker]

Thanks for your replies!

Originally Posted by DaleDe

Looks handy. You might want to add publisher to the metadata choices to avoid putting the app name where the author belongs. Do you use the file names for the TOC if the first line is not checked? I take it a blank line is used as a paragraph separator. Does it use an existing CSS if the file exists, or always build a new one?

1. More meta data can be added if anybody want this feature.
2. Yes, it will use file name as title if this option is not checked.
3. If any css file exists in the source file dir it will be selected as css.

Originally Posted by PandathePanda

Well tried it, and is disappointed.

1) Gave it 10 txt files, and it failed to convert most of them. All of them was utf8 files.

2) And this made me pissed a lot. Set the output folder to "user folder" and it deleted everything in my user dir (tried it twice, second time used random files in the dir, and it cleaned the dir again)

My advice for all is too leave this piece of crap alone until it's fixed

1) Can you send me the log file? There is a view log button when convert finished.
2) The software's logic is to make a new folder "epub-out" of your source directory's up level directory. This folder will be emptied. Sorry for the inconvenience. I'll add a warning message next version.

Originally Posted by RobertDDL

It sounds interesting. But, how do the text files have to be formatted? When you say, "Mobi Epub Maker can set the first line of the text file as chapter title" does this mean that each chapter has to be a separate file? (Not a good idea, I think). What about different heading levels? How do italics and bold have to be formatted in the text file? Block quotes? Verses? Blank lines? Footnotes?

Not all of this is indispensible, of course, at least not for a first version -- I'd settle for heading levels 1 and 2, and italics, and blank lines. It's a pity that there seems to be no widely accepted standards for tagged text files (or is there, and I'm just not aware of it?)

1) The text will be formatted by adding html tag to each line of your original text. like this:<p>text line</p>
2)Every file a chapter is just for my own purpose. Because I don't find this function in Calibre. So I decide to make one.
3) Italic/bold style can't be supported by text file so it can't be supported by this software.
4)Maybe I can add a text editor if that is most people wanted.

[eschwartz]

Originally Posted by RobertDDL

I consider EPUB to be a rather crappy format, with way too much unnecessary complexity. You cannot simply create an EPUB file from scratch with a text editor unless you are an expert, while this is easily done with HTML.

On the other hand, converting is easy.

Chapters have to be separate files, which makes no sense at all and is a major nuisance with editing.

No they don't. It is customary however to do so for organizational purposes, as you seem somewhat unique in thinking one file is easier.

I suppose some of EPUB's annoying complexity is owed to its DRM capabilities, but, well, you know what I think about that

Sure, I can parse an HTML file and insert a TOC at its top, but this TOC would not be accessible from within the text while I'm reading, as it is with EPUB or MOBI.

No it isn't. The HTML ToC is just a page in the book, entirely independent of the navigation ToC.
The two can even be totally different, if you wish to amuse yourself and startle readers.

It would be an easy task for the e-reader to parse the HTML file upon loading and create a TOC on the fly, but as far as I know, this isn't done. (On my PC, LibreOffice does it nicely enough, though there is a bug when I just open the HTML file -- when I create an empty document and import the HTML file, it works well.)

Surely you meant "when libreoffice converts my HTML into a word document and injects a navigational ToC into the ZIP package containing the document resources".

Which come to think of it is what calibre does when it converts HTML, too.

Since you are determined to edit EPUB with a text editor, I challenge you to likewise try editing a word document using a text editor, before you compare EPUB to ODT.

Or just use an EPUB editor.

I should have said "zipped HTML" -- it's a major advantage to have text, images and style sheet together in a single file. Since you already know about my paranoia, let me voice the suspicion that HTMLZ is shunned by the publishing industry because it doesn't offer DRM capabilities. It would still be nice to have it available, because it would be by far the easiest format to create and to edit, but there seems to be very little suport for it by any reading devices or software.

Nothing stops HTMLZ from having DRM capabilities except lack of caring. It is a format without a cause, nothing but an unstructured EPUB.

[eschwartz]

Originally Posted by MobiEpubMaker

1) The text will be formatted by adding html tag to each line of your original text. like this:<p>text line</p>
2)Every file a chapter is just for my own purpose. Because I don't find this function in Calibre. So I decide to make one.
3) Italic/bold style can't be supported by text file so it can't be supported by this software.
4)Maybe I can add a text editor if that is most people wanted.

So this really supports HTML? If you require HTML tags for structure...

Might as well go all the way and support HTML bold/italics.
On which note, there is a standard called "markdown" which supports bold/italics.

P.S. calibre can import or convert multiple HTML files as one, just so long as the other files are linked from the first one.

[DaleDe]

Originally Posted by RobertDDL

I consider EPUB to be a rather crappy format, with way too much unnecessary complexity. You cannot simply create an EPUB file from scratch with a text editor unless you are an expert, while this is easily done with HTML. Chapters have to be separate files, which makes no sense at all and is a major nuisance with editing. I suppose some of EPUB's annoying complexity is owed to its DRM capabilities, but, well, you know what I think about that

I think ePub is a rather versatile format and not crappy. There is no reason to make one from scratch. If you want to do it automatically you can use a program like Atlantis Word Processor to make a ePub directly from RTF, DOC, etc. No knowledge of anything other than simple word processor required. Or if you want to use a more nuts and bolts approach you have Sigil at your disposal or the Calibre editor.

You do not have to make separate files although this can make it easier to process. None of the annoying (to you) complexity is based on DRM. The file format is HTML with some decent consistency closing tags along with images, an optional but useful CSS and a separate TOC along with some metadata in a file. How much simpler can it be? Free form perhaps that is not parseable by a computer? You can even use a simple text markup language if you prefer and convert it. You can read about ePub in our wiki.

Dale

[RobertDDL]

I apologize, I shouldn't have said crappy. I am aware that there are good tools available for creating and editing ePub -- I create ePubs from LibreOffice using writer2epub when I have to, and it serves my purposes well enough. And no, I am not determined to edit ePub with a text editor, I've just stated that I can't, and I prefer formats where I can. I simply do not see the advantages of the added complexity, compared to HTML (and ePub is more complex). And I've mentioned LibreOffice just as proof that book-sized HTML texts can be satisfactorily rendered. When I have a large text file that I want to read on my computer, I edit it, tag it, convert it to HTML (with my own tool), and read it in LibreOffice. When I want to read it on my ebook reader, I have to convert it to ePub, or I wouldn't have a TOC. Not much trouble -- just, as I've said, I do not see the advantage (though ePub with its smaller files and its built in TOC may be easier to handle by a device with small memory and slow processor?)

[Jellby]

I create and edit epubs with a text editor (vim). It requires some manual work, but not much more than creating HTML with a text editor, once you have the templates.

[eschwartz]

Originally Posted by RobertDDL

I apologize, I shouldn't have said crappy. I am aware that there are good tools available for creating and editing ePub -- I create ePubs from LibreOffice using writer2epub when I have to, and it serves my purposes well enough. And no, I am not determined to edit ePub with a text editor, I've just stated that I can't, and I prefer formats where I can. I simply do not see the advantages of the added complexity, compared to HTML (and ePub is more complex). And I've mentioned LibreOffice just as proof that book-sized HTML texts can be satisfactorily rendered. When I have a large text file that I want to read on my computer, I edit it, tag it, convert it to HTML (with my own tool), and read it in LibreOffice. When I want to read it on my ebook reader, I have to convert it to ePub, or I wouldn't have a TOC. Not much trouble -- just, as I've said, I do not see the advantage (though ePub with its smaller files and its built in TOC may be easier to handle by a device with small memory and slow processor?)

And what about my point, that you are doinng precisely what you profess to dislike every time you convert HTML to ODT and read it in LibreOffice...

[Hitch]

Originally Posted by eschwartz

And what about my point, that you are doinng precisely what you profess to dislike every time you convert HTML to ODT and read it in LibreOffice...

I'm utterly confused by the whole discussion. We edit ePUBs in NoteTab Pro all the time. What's the difficulty?

An ePUB is an htmlz file, for all intents and purposes. It's a bunch of html files (or one, if you want to deal with the size, and make a book that people can't read on some readers), with a nav TOC that *can* be made auto-magically by either Sigil or Calibre (or Atlantis, whatever); an OPF, to tell it what's where, and an NCX, ditto. Both of which not only can, but MUST, be made/edited in a text editor, or a dedicated ePUB-maker like Sigil.

Honestly, there must be something else here that I'm missing, because there's just nothing complex about an ePUB. AT its simplest, one HTML file; a nav TOC if you want one; an NCX for device nav, and and OPF, so the device knoweth where stuff IS. What's complicated about that, really? The OPF and NCX, versus using HTMLZ? Everything else is exactly the same, and if you use Sigil, you can plop your HTML file in there, and if you've used header styles (h1-6), it will build everything that you consider "complicated" FOR you.

I think, push-comes-to-shove, that if you're keen on text editors, I'd rather be dealing with an ePUB, than Word or ODT, quite honestly. ePUB, at its heart, is all about the HTML. Hell, it IS a zipped-up webpage; it simply uses the NCX and OPF in lieu of a website's on-page menu, for navigation and structure. {shrug}

Sorry to join in with the thread-jack. But it's just oddball to me.

Hitch

[eschwartz]

Hitch -- if someone just has this gut feeling that EPUB hates them, who am I to argue?

I figure I will have better luck just showing the parallels to things they already deem acceptable, rather than trying to sway them on the inherent logic that "OPF+NCX is the only real difference" and "it isn't all that complicated anyway" and "editors exist to abstract away both of them anyway".

[AlexBell]

Originally Posted by Hitch

<-- snipped -->

Both of which not only can, but MUST, be made/edited in a text editor, or a dedicated ePUB-maker like Sigil.

<-- snipped -->

ePUB, at its heart, is all about the HTML. Hell, it IS a zipped-up webpage; it simply uses the NCX and OPF in lieu of a website's on-page menu, for navigation and structure.

<-- snipped -->

Hitch

Or an HTML editor, for those of us who dabbled in website design in the olden days.

[RobertDDL]

Originally Posted by eschwartz

And what about my point, that you are doinng precisely what you profess to dislike every time you convert HTML to ODT and read it in LibreOffice...

I've mentioned LibreOffice here as proof that a TOC can be generated on the fly by parsing a HTML file for header tags. I simply wish that my ebook reader and some lightweight e-book reading software on my PC could do the same -- I just don't see the need for a separate TOC. I still don't understand the benefits of having NCX and OPF, but I stand corrected by all of you that the problem isn't the complexity of ePub, but just my indolence

[dickloraine]

But why should I want to parse a file every time I open it? An ebook is static, I don't edit it. So better to do this one time instead of always. Additionally: what abou very large or complex files? How much time would I have to wait to parse them? And complex files could be even impossible to parse automatically.