Ebook Formating Tool Wishlist

[kfarmer]

Originally Posted by kovidgoyal

ah well we seem to be talking past each other. I am indeed concerned with the on disk format. The in memory format could be anything he likes, but from the perspective of plugin development, I'd vote for a nice object model that can be exposed in a scripting language.

Absolutely.

Originally Posted by kovidgoyal

And I apologize for saying you don't get open source development, that was a little too harsh.

No worries. Given my employer, this was a tea party

[kfarmer]

Originally Posted by aapezzuto

them) and I have the twins still :-)

Speaking of which, what species are they? The ones on the hands, I mean.

[WillAdams]

Perhaps a more interesting idea would be to work instead on an export routine for LyX which would then allow it to export to a format suitable for conversion to an ebook?

William

[bsandersen]

I've given this some thought (and I hope my belated entry here is not to late to shape your project).

Rather than come up with a complete and stand-alone solution, it might be better to simply provide additions to existing tools to help them support modern eBook formats. My specific recommendation is to provide a set of tools to be used in conjunction with LaTeX (pronounced "Lay-tech")

http://www.latex-project.org

that would support the Sony BBeB (.lrf) format, the MobiPocket format, and perhaps a few others.

If you wish to provide a GUI component using Qt

http://trolltech.com/products/qt

the provide a basic editor for the LaTeX work and then provide a "preview" function that would render the output in the format of the specific eBook reader targeted.

This approach has several advantages from a pedagogical point-of-view: we have now divided the problem into several distinct pieces:
1. LaTeX processing (no GUI component at all)
2. BBeB backend
3. MobiPocket backend
4. Editor
5. Previewer for BBeB
6. Previewer for MobiPocket

Additionally, students will need to work within an existing code base to extend it--something that is more "real-world" than the "start from scratch every time" approach most student projects use.

If the project is structured properly, new eBook formats could be added by subsequent projects. Further, using the comment LaTeX format means a single book source file can produce multiple formats with little compromise.

While WYSIWYG may be all the rage, WYSIWYM (what you see is what you meant) is actually more useful for this type of work.

I wish you and your students well. If there is anything else I can contribute, let me know.

-- Scott

[kovidgoyal]

@bsanderson
Problem is no ebook format supports the features of LaTeX. Also TeX is really designed for fixed-size layout, not reflowable layouts.

[WillAdams]

That's why I suggested an export routine from LyX (which is more-or-less a LaTeX editor), which is a ``what you see is what you mean'' editor.

William

[kfarmer]

Originally Posted by WillAdams

That's why I suggested an export routine from LyX (which is more-or-less a LaTeX editor), which is a ``what you see is what you mean'' editor.

William

Last I used it, LaTeX was very focussed on being able to compose glyphs, which was very useful.. in the sciences. Beyond that there wasn't too much and you hardly hear of it any more. So why LyX instead of a more mainstream editor (eg, a popular word processor, and just write import/export functions for it).

[tompe]

Originally Posted by kfarmer

Last I used it, LaTeX was very focussed on being able to compose glyphs, which was very useful.. in the sciences. Beyond that there wasn't too much and you hardly hear of it any more. So why LyX instead of a more mainstream editor (eg, a popular word processor, and just write import/export functions for it).

It is still the tool used to produce scientific articles in many areas. For example at the computer science department I work LaTeX is what you use.

The important thing with and editor is that the format it uses is standardised and open.

[kfarmer]

Originally Posted by tompe

It is still the tool used to produce scientific articles in many areas. For example at the computer science department I work LaTeX is what you use.

The important thing with and editor is that the format it uses is standardised and open.

I would argue that the *useful* thing with an editor is that the format used is common, but the geek in me in intrigued -- does LyX expose an (easy) DOM?

The downside of LaTeX would be that, IIRC, it's entirely for typesetting content that is both static and visual. Limiting unless you can extend to, say, embedded audio.

(You may wonder why I harp on this -- it's important to establish at the start the limitations you're willing to accept for any particular project. EG, whether or not you want to support users re-templating your data grid to be the shape of a fish, as is the popular skinning nightmare at my office.)

[WillAdams]

As I noted, LyX has moved away from LaTeX, and more towards being an agnostic document editor --- it has support for exporting to docbook format after a fashion, so supporting some sort of html should be feasible:

http://wiki.lyx.org/LyX/DocBook

w/ pdftex, latex can do embedded files of various sorts, incl. audi.

If desired, one could use shapepar to put your paragraphs in a fish shape --- you could draw the fish using xfig and use shapepatch and transfig to convert to the \shapepar polygon def.

http://www.ctan.org/tex-archive/help.../shapepar.html

William

[kfarmer]

Originally Posted by WillAdams

w/ pdftex, latex can do embedded files of various sorts, incl. audi.

Neat

Once upon a time, this was a non-issue, but I think it's just a matter of not-much-time. I could see a childrens book, say, with buttons to hear Angela Landsbury doing a dramatic reading.

[aapezzuto]

WYSIWYM is definitely the approach I will be using, but until starting the research on this, I had only ever seen that acronym once. TeX and the subsequent LaTeX are wonderful markup languages, that focus on doing what they do well. LaTeX is an extension of TeX and was developed as a way to generate glyphs... It was done so well that it is the standard, and in my life I have never seen another way to text format math equations of any real complexity. Past that though, TeX is a lot like having 1 style sheet for all your documents, its consistent, and since its well designed... people like the way it looks.

Docbook is amazing! Though I don't plan on implementing its level of features and crazy data handling, I do have significant respect for it. Though its not the only thing I have gleaned thus far, I have definitely learned that I will have to define the scope of this application very strongly before anything else can move forward. Limiting the complexity of the sort of document it can markup will add a level of simplicity and stream-lining that I rely want to see.

[aapezzuto]

Originally Posted by kfarmer

Speaking of which, what species are they? The ones on the hands, I mean.

albino pygmy marmosets
http://news.nationalgeographic.com/n...eys-photo.html

one of them died

[bsandersen]

I agree completely that the best thing to do for your project is establish the set of requirements prior to launching students against it. I had begun making such a list for inclusion in my previous post but quickly discovered it would be a very big job (certainly more of a job than appropriate for this list).

If some derivative of LaTeX sounds too ambitious, how about using something like runoff (groff, troff, etc.) with its simple command set, long history, and ample supply of sample documents it could be a good direction to follow. (I confess I had begun looking at this idea myself...) For most works of fiction, history, or other disciplines that do not require graphical elements, this command set is more than adequate. A simple "include JPG" command would probably cover the rest.

I still believe that the text processing (non-GUI), preview (GUI), and control aspects (also probably a GUI--but a command line version would also be VERY nice) is a good way to divide the problem. Gee! Model-view-controller... imagine that! {grin}

-- Scott

[ath]

Originally Posted by aapezzuto

So as we are building the project outline and specification, and coming up with use cases, what would the community like to see in such a tool?

Very simple: Support for every functionality the corresponding *reading* tool provides, and particularly for the optimal use of such functions that are difficult to handle 'manually'.

For instance: If the reader supports discretionary hyphens -- that is, allows the text formatter to suggest good places to do end-of-line hyphenation -- I would like to be able to select a hyphenation dictionary that I (as a book producer) trust and prefer, and to hyphenate all words in the text according to that dictionary, as well as disable or modify some of those hyphenation.

If hyphenation by algorithm, I should be allowed to plug in my own algorithm or configuration data: and thus, I will need support for creating them in the first place.

U.S. hyphenations are an abomination in Br.Eng. text ... and very probably vice versa.

I would suggest that WYSIWYG is out -- it doesn't clearly do anything useful except give a false sense of confidence in the user that he actually is able to control something. Far better, I think, to force the user/book formatter to realize that he/she doesn't have a clue about what the reader will do, unless proofreading is done on the actual devices with the actual readers.