Feedbooks to support ePub format

[bowerbird]

dale said:
> The book was a mess of real hyphens needed for compound words
> and hyphens used when a dash was needed.

yes, that's the type of ambiguous coding that needs to be avoided...


> Bold, italics and special symbols get lost in translation to ascii.
> Surely you have noticed this.

i sure have. italics and bold (except on headers) must be marked.
and for my own mirror of the p.g. library, i will probably use utf8,
so special symbols won't be a problem.


> period books use unusual spelling and other specialized
> but unusual constructions with foreign words that can
> fool spell checkers requiring intervention that seems
> not to get done in the process.

i've built a spell-checker designed specifically for this task.
when the time is right, i'll release it to the public...

-bowerbird

[bowerbird]

hadrien said:
> we've got an API that makes it possible for any
> application or website to interact with Feedbooks

so, hadrien, i've built an app that will let people
download books from your site, even en masse.

do you discourage indiscriminate downloading?

would you like for me to distribute the program?

-bowerbird

[Hadrien]

Originally Posted by bowerbird

hadrien said:
> we've got an API that makes it possible for any
> application or website to interact with Feedbooks

so, hadrien, i've built an app that will let people
download books from your site, even en masse.

do you discourage indiscriminate downloading?

would you like for me to distribute the program?

-bowerbird

I really don't mind much. I've noticed that since we've added ePub support, 2 IPs at least, downloaded all of our books as ePub.

Our API wasn't created for such a purpose though, and keep in mind that there's still a few things missing, like footnotes or hyphenation in our current ePub output. The API is here for those who'd like to integrate Feedbooks into another application, website etc...

I'll post a full page explaining how things work tomorrow.

The only things that would be better for us, is having people logged in on the website before they download anything (through us or a third party application). This way we can improve our recommendation system (and with already 20k+ books available on PG, I believe we REALLY need a recommendation system on a public domain website).

[Hadrien]

Originally Posted by bowerbird

where can i get information on your a.p.i. for external apps?

OK, the help page for the API is almost ready, it'll be online today. In the meantime, here's a list of the actions available:

• initializing: test the login/password, get the list of the formats available
• subscription: display the subscriptions for a user (RSS feeds, newspapers etc...)
• search: display the list of books available for any given keyword
• similar: display a list of books that are considered similar
• recommendation: display a random list of featured books if you're not logged in, otherwise, it'll display personal recommendations
• favorites: display the list of favorite books for a user
• history: display previously downloaded books for a user

[Hadrien]

Here's the help page for the API: http://www.feedbooks.com/help/newsstand_api

I'll add a few examples of ruby code, C and C# applications that are using our API in the upcoming weeks.

Here's a few examples of the things you could do with this API:

• A downloader for your newspapers: auto-sync your files to your device
• Make a Flash widget, displaying your favorite books
• A book search engine and downloader for your favorite e-book reader
• A book recommendation system for your website
• etc...

[bowerbird]

thanks hadrien, i'll look it over sometime soon...

-bowerbird

[JSWolf]

bowerbird, why not just use html to do the markup?

[bowerbird]

ok, hadrien, i took a look. but i guess i'd already figured it all out on my own... :+)

jswolf said:
> why not just use html to do the markup?

i don't understand the question. so i'll just make up an answer. ;+)

i don't like .html books, because the browser is a lousy reader-app.
if you want to see what i think a reader-app needs to do, go here:
> http://onlinebooks.library.upenn.edu...t=2004-01-08,3

that post is from way back in 2004, but the list hasn't changed much.
unfortuntely, browser capabilities haven't improved that much either,
at least from the standpoint of how well a browser meets my criteria.

so i'd reject a browser/html workflow entirely, if not for the fact that
putting material on the web is a very handy way of making it _public_.

as far as _applying_ .html markup, i think it's a royal pain in the rear.
that's why i invented my own form of light-markup, so i could obtain
the main functionality i want from documents without doing markup...

however, it's not like i've become resigned to a browser/html world.
i'm now creating web-aware offline applications that can _get_stuff_
from the web to display it themselves, so you don't need a browser.

if i understand hadrien correctly, that's why feedbooks has an a.p.i.,
so developers can give users an alternative to using a web-browser.

if you can save the user from being forced to make an inconvenient
trip to the browser, why not? convenience is the name of the game.

of course, this approach of an app going directly to a webpage and
grabbing data isn't unusual nowadays; rss-readers do it all the time.
the difference is, they expect the documents they receive to be .html.
my applications expect received documents to be in my .zml format.

i still think it's important to have the ability to convert .zml into .html,
so the documents can be put on the web for users who _cannot_run_
offline apps (e.g., because they can't install them on a work machine);
but for the vast majority of people, i think the enhanced functionality
of my offline viewer-program will win them over, especially when it's
combined with the ease of not having to hassle with applying markup.

for my part, i'm converting the e-texts in project gutenberg into .zml,
and will be mounting them on my own mirror as a .zml demonstration.

i fully expect the long-term maintenance of .zml files will be low-cost,
so i think i'll be able to maintain the entire library all by my lonesome,
even as project gutenberg continues to pump new titles into the world.

-bowerbird

[JSWolf]

But if you do the markup in html, you can have a program then convert to whatever format you want. What does your zml format support that html does not?

[bowerbird]

jswolf said:
> But if you do the markup in html, you can have a program
> then convert to whatever format you want.

if _you_ want to use z.m.l. to create .html, and then convert it into something else,
that's totally fine with me. but i have no desire to do all that conversion busy-work.
or apply any markup in the first place. i want to focus on the writing, and that's all.
i want the _machine_ to format it nicely for me, and apply the markup if i need any.


> What does your zml format support that html does not?

z.m.l. doesn't support anything that .html won't do. in fact, it does a whole lot less.
but the things it _does_ do are all the things that are commonly required by books...

my overall perspective is that _formats_ are highly overrated. the _real_magic_ is
in the _applications_, not the format. my focus is on putting the smarts in the apps,
not in the formats. i want to make the format as dirt-simple to create as possible,
and then have the program do all the grunt-work of providing excellent functionality.

remember how openreader was gonna be this magical format that was going to end
david rothmans "tower of ebabel"? it never had an application that implemented it,
so it went nowhere. until you have an application for a format, the format is useless.

so if .html does the job for you, and you don't mind doing .html markup, go for it...

but me, i'm looking for something simpler. even if i have to program the thing myself.

-bowerbird

[bowerbird]

so the question should be, "what does a zml-viewer do that a browser won't do?"

and for the answer to that question, go visit that web-page i pointed you to earlier.

a web-browser will do maybe 1/4 of my requirements, half if it's lucky.

my zml-viewer will do 95% of them, 100% eventually...

so i think it's gonna be a better e-book viewer than a web-browser.
which ain't saying much, since a browser is such a lousy e-book app.

i think my viewer will be better than most other e-book viewer-apps,
but there's not much use saying that until you can try it out for youself.
and even then, what will matter to you is not _my_ opinion, but yours...

-bowerbird

[igorsk]

I wish you started to use capital letters and leave line wrapping to the forum. Then maybe more people would read your posts instead of skipping them over.

[bowerbird]

do you mind if people "skip over" my posts? because i don't... :+)

-bowerbird

[bowerbird]

hadrien, next week i'll release my app that facilitates downloading feedbooks books,
and i wanna make sure you're fully ok with it before i do, so i'll ask one more time...

-bowerbird

[Hadrien]

Originally Posted by bowerbird

hadrien, next week i'll release my app that facilitates downloading feedbooks books,
and i wanna make sure you're fully ok with it before i do, so i'll ask one more time...

-bowerbird

How does it facilitates downloading ?