elsewhere, hunter said:
>   if you follow gutvol-d you already know that
>   many consider the HTML guiguts produces
>   and that many PPers choose to produce otherwise
>   is a disaster when viewed on most readers and as epubs
>   which is the most popular format for
>   users downloading pg books.
>   So the whole convert to HTML feature is one huge bug.

hunter, just one word:  careful!

first, i can see quite well that you _qualified_ that
-- perhaps quite meticulously, to your mind --
with the "when viewed as" phrase which followed.

but your audience, over there in the d.p. forums,
turned off their rational brains just as soon as you
said the .html they lovingly produce "is a disaster".

they never even got to the condition of specification.

i know this is true, because i used to use that trick
against 'em all the time.  but _my_intention_ was to
make them stop listening, while still covering myself.

you, on the other hand, _want_ them to listen to you.

so you really need to be careful about that.

***

but i think, aside from that, you got the fact wrong.

to my mind, nobody here is complaining about the
.html output from guiguts.  i know that _i_ am not.
i don't even know what kind of .html guiguts makes.
it might be bad, or might be good, i just don't know.

what i _do_ know is that it's the output of a script,
thus can probably be depended on to be consistent.

so even if it is bad, it's bad in a _dependable_ way...
meaning the odds are good that it can be corrected
by using a procedure which is, likewise, automated.

(whether or not marcello's app does that correction
is an open question, but a correction is _possible_.)

the real "problem children" are the "snowflakes",
the .html versions which contain "unique" .html,
inconsistent with the majority of the other books.

just as one big example, there are lots of ways to
indicate a header, using .html, or .css, or _both_...

(ask a dozen people on this list, and you will get
at least a half-dozen different ways of doing it.)

and even though most of them can't be considered
"wrong", the simple fact is that, if we allow 'em all,
it becomes virtually impossible to write a converter
that can discern all of them, i.e., spot the headers...

and, obviously, if a converter can't recognize even
something as crucially important as the _headers_,
it's not gonna be able to make a quality conversion.

one reason i used this as the example is because
all these different ways of indicating the headers
essentially produce an equivalent _functionality_.
at most, they give a different "look and feel", but
it'd be easy for all of us to agree on the "purpose".

none of your postprocessors are so heavily invested
in their own particular snowflake style of _headers_
that they couldn't switch to some consensus method.

another reason i used headers as the example is that
it is possible to _find_ books -- in the library now --
where the purposes and functionalities of the headers
are being compromised, because the headers are _not_
being correctly recognized.  this is the kind of problem
that you need to bring to the attention of your people.

it's a real problem, that exists right now, in the library.

you can say "look at this book you worked so hard on".
and then point out that "the headers are not working;
they're not doing what they're supposed to be doing".

perhaps they didn't appear in the table-of-contents,
because they weren't getting recognized as headers.

or maybe they showed up as dinky wimpy side-notes,
rather than being big and bold, like headers should.

whatever the case, show people how their "snowflake"
methodology sabotaged the functionality of their book.

let them know that their _solution_ to this problem is
the use of a workflow that produces consistent output.

now, sometimes you are going to find that the glitch
is _not_ in the input that you feed p.g., but rather in
marcello's converter...  your people are going to say
"well, look, i did the headers the way i'm supposed to,
and they _still_ didn't show up correctly in the .epub."

and hunter, your answer is that _your_ converter _will_
create the correct output, when it's given correct input.

so y'all won't need marcello's damn converter no more.

-bowerbird