jim said:
>   Someone may say they want PDF,
>   and you may generate it for them,
>   but it still won’t work unless you
>   correctly guess what device and
>   format they want the PDF for.

jim, no you may not squirm out of your lesson here
by changing to my side in the middle of the lesson...

you will have to say -- out loud -- you were wrong.


>   if you looked at the statistics of
>   what it is that PG users actually download. 

i will be making the very exact same arguments
against .mobi and .epub, so no, jim, this is not
a way for you to squirm out of the lesson either.


>   Write to a KISS subset of HTML that will "correctly"
>   render to the widest possible number
>   of HTML, EPUB, and MOBI readers.

more obfuscation to avoid admitting the obvious...

now it's a "kiss subset" of .html and not .html itself.

only of course the subset has not been defined, nor
has it proven itself, nor are any of the tools in place.

address all those obstacles to _prove_ that it works,
jim, and then come back with your miracle solution.

some of us have enough experience to know that
what you're talking about might _sound_ good to
someone who doesn't have that same experience,
but it falls apart quickly if you examine it closely.

go over to the d.p. boards, and you will already see
that people are complaining about having to adopt
a restricted subset of .html.  "why can't we use it all?"
"why should be accept a dumbed-down version of it?"

and there are many versions of .html floating around,
from 4.01-transitional to html5 to the xml variants,
to the retarded version of stuff that works on a kindle.

people who know one of these versions will think they
"already know" your version, and you'll have to spend
an inordinate amount of time and energy "correcting"
the work that they do, which will only piss them off...


>   The way “feedbooks.com does it” is to dumb-down

gawd, i forgot how frustrating it is to "argue" with you,
thanks to your lack of any reading comprehension skills.

when i said "look at how feedbooks.com does it", it was
with respect to user-customization of their .pdf output.

it had nothing to do with the way they code their books.

but of course, you don't read well enough to grasp that.

unless, that is, you are _deliberately_ confusing matters,
as yet another maneuver in your attempt to squirm out...

which reminds me...

no, jim, it's also not going to work for you to try to use a
"flood the listserve with inane comments and posts so
that everyone gets fed up and stops reading the thread".

because i am going to come back, on a regular basis,
and point out that you _failed_ to demonstrate a model
where .html files could be used as the "master-format".

i'm gonna keep pointing it out until it is drilled into the
brains of everyone here that that is what you failed to do.
so the next time you come here and try to pitch that crap,
everyone will remember that you never did prove it to work.


>   I already did this BB

no, you didn't do this.  you didn't do anything even close.

you just flapped your trap.  you showed us _zero_ proof.

you say there is big demand for .html, .mobi, and .epub.

yes, i agree.  and we should meet that demand.  agreed!

but that gets us nowhere.

the point is that the .html files currently in the library
often create crappy .mobi and crappy .epub, and they
give users very little capability to create useful .pdf...

most e-books in the library already have an .html version,
so all you have to do is to _make_those_versions_work_...
show marcello how to convert 'em into .mobis and .epubs
that will make _all_ of the .mobi and .epub users happy...

i know you're never going to be able to do that, because
even if reflowable formats solve (some) viewport issues,
they don't solve other issues like curly-quotes-vs-straight,
or block-paragraphs-vs-indented, or justified-vs-ragged.

so people are still going to want to _customize_ their
.mobis and .epubs to their own preferences, if they can.

but even aside from that, given all the wrinkles in the
.html versions that currently exist, you cannot ensure
quality conversions of those .html files to _any_ format.

even a "plain-vanilla" .mobi or .epub.  which, by the way,
might work quite differently in all the viewers out there.
are you going to be tweaking them for different viewers?
before you know it, you'll have 32 versions of each .mobi,
and 32 of each .epub, exactly like you have 32 for .pdf...

yet you still want to argue that .html should be exalted
as _the_master_format_ for all of project gutenberg...

and you seem not to realize how ludicrous that sounds.

here's what you need to do if you want us to be believers.

you need to show people how to make .html that will
convert into excellent .mobi and excellent .epub, and
you need to show people you can have the volunteers
adopt your particular brand of .html as their own, and
you need to show that they can then actually bring in
files that utilize your particular brand of .html, and
you need to show the whitewashers can _maintain_ it,
and finally, that the end-result makes end-users happy.

that's what you need to do, jim.  and you cannot do it.

did you hear me, jim?  i said that _you_cannot_do_it_...

prove me wrong, jim.  go ahead.  prove it.  i dare you.

because if you don't, i'm going to drill it in to everyone
that you have failed to make good on your suggestion...

i promise you i will, jim.  so your choices are very clear.

-bowerbird