Ebook Formating Tool Wishlist

[HarryT]

Originally Posted by aapezzuto

Right now, with the readers and formats available, I think lots of people would rather have a highly tuned, device optimized pdf...

<shudder>

Speak for yourself!

There's absolutely no way I'd want PDF.

[aapezzuto]

Originally Posted by HarryT

<shudder>

Speak for yourself!

There's absolutely no way I'd want PDF.

for the most part i agree, but the way the hardware handles footnotes, there are certain books / authors that I find much less enjoyable without the footnotes being... well at the foot.

[NatCh]

PDF is fine if it's sized correctly for the display. I don't use it because LRF is handier, but I'd at least consider it if there was a handy tool that spat it out, and supported the sort of formatting options we've got in BD.

[nesagwa]

Dunno if it applies here, but a tool to edit the Title and the Author of a book (the actual file itself, not the way libprs does it) and maybe a way to edit the books text to correct small formatting / spelling errors. A way to add cover art to existing ebook files. Something to edit the TOC.

All without crazy mark up language and on a mac would be incredibly useful for me at least.

[JSWolf]

To find out about the LRF specification, go to http://prslabs.com/ and register for an account. There are documents on the format there in very good detail.

[HarryT]

Originally Posted by NatCh

PDF is fine if it's sized correctly for the display. I don't use it because LRF is handier, but I'd at least consider it if there was a handy tool that spat it out, and supported the sort of formatting options we've got in BD.

The issue I have with it is that I frequently change the font size to suit the lighting conditions - in poor light, or if I'm tired, I read with a larger font. I couldn't do that with PDF.

[kfarmer]

Originally Posted by aapezzuto

I have been approached by a friend who is soon to graduate with a CS degree to outline him a reasonable 200-500 hour project. What we have come up with is an ebook formating program, written in C++, using QT, and thinking in epub. Its main goal is to be able to replace book designer as a more plug-in friendly opensource project. 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?

I am well aware of the talent in both programing and formating we have here, so I am excited to see what we come up with.

Python's a good choice; it was my favorite until I started working in C#. I'd opt for IronPython, but that's because I (personally) know that framework better and would be able to write plugins for it using whatever language.

You'd still have the cross-platform capabilities, thanks to Mono.

If you were able to split apart the UI from the non-UI bits, and make some standalone parsing/generation modules, that would be useful just as a reference for others. Make the interface pluggable, and you can get some interesting possibilities (you want to run this on an iPhone, maybe?).

In short, make an engine around which you wrap a shell. Pull this off well, and I can think of a fair number of good things that could come of it.

[kfarmer]

Originally Posted by JSWolf

To find out about the LRF specification, go to http://prslabs.com/ and register for an account. There are documents on the format there in very good detail.

I have yet to successfully register. The confirmation email never arrives.

Seen this before, though, if they blacklist self-hosters.

[kovidgoyal]

Originally Posted by kfarmer

If you were able to split apart the UI from the non-UI bits, and make some standalone parsing/generation modules, that would be useful just as a reference for others. Make the interface pluggable, and you can get some interesting possibilities (you want to run this on an iPhone, maybe?).

In short, make an engine around which you wrap a shell. Pull this off well, and I can think of a fair number of good things that could come of it.

That already exists in libprs500 in python, dive in http://libprs500.kovidgoyal.net/wiki/Development

[igorsk]

The document on PRSLabs describes only LRS (the source XML), not the binary LRF format.

[aapezzuto]

Originally Posted by kfarmer

If you were able to split apart the UI from the non-UI bits, and make some standalone parsing/generation modules, that would be useful just as a reference for others. Make the interface pluggable, and you can get some interesting possibilities (you want to run this on an iPhone, maybe?).

In short, make an engine around which you wrap a shell. Pull this off well, and I can think of a fair number of good things that could come of it.

Having worked with Greg on several other projects I would be surprised if he designed it any other way.

As I have been going over the basic design concept I keep finding little holes in epub, that make me want to consider making a native structural xml file. Perhaps something like a striped down version of DocBook or some other only structural base format. If a good number of input and output formats are provided at release, does anyone care what format the program "thinks in" is?

[kfarmer]

Originally Posted by aapezzuto

Having worked with Greg on several other projects I would be surprised if he designed it any other way.

As I have been going over the basic design concept I keep finding little holes in epub, that make me want to consider making a native structural xml file. Perhaps something like a striped down version of DocBook or some other only structural base format. If a good number of input and output formats are provided at release, does anyone care what format the program "thinks in" is?

A canonical format shouldn't be lossy (ie, epub -- or whatever -- should be a superset of every supported format). Beyond that, there's no reason to care: epub just becomes another supported format.

[tompe]

Originally Posted by kfarmer

A canonical format shouldn't be lossy (ie, epub -- or whatever -- should be a superset of every supported format). Beyond that, there's no reason to care: epub just becomes another supported format.

There is a good reason to care. The choice of format might influence how much code you can reuse or get for free. The format should also be a format that have good support in form of parsers and a format that is easy to work with in different language. That is because the work done with formats and how to translate between them is generally useful if you want to implement something similar in another language.

[kfarmer]

Originally Posted by tompe

There is a good reason to care. The choice of format might influence how much code you can reuse or get for free. The format should also be a format that have good support in form of parsers and a format that is easy to work with in different language. That is because the work done with formats and how to translate between them is generally useful if you want to implement something similar in another language.

Those are implementation details that only devs should be concerned about, not users, as the question was posed.

.....

Okay, so my still-waking eye inserted "users", but the point remains -- whatever canonical form that app uses has very *little* to do with interoperability, since interoperability is a function of what inputs are supported, and code reuse is not important to well-*functioning* code. Reuse is a convenience to the developer, not the user.

[tompe]

Originally Posted by kfarmer

Okay, so my still-waking eye inserted "users", but the point remains -- whatever canonical form that app uses has very *little* to do with interoperability, since interoperability is a function of what inputs are supported, and code reuse is not important to well-*functioning* code. Reuse is a convenience to the developer, not the user.

Well, for an open source project one use of it is to reuse the code. Only seeing code reuse as a convenience for the developer is a mistake.