hunter said:
> I agree there is in fact
> a golden opportunity
> to change the face of PPing
> by using guiguts to
> encourage better practices
> by changing default behavior
> and flagging bad practices.
yes, there _is_ a golden opportunity here.
and that's why i want you to think bigger.
much bigger.
your vision has been constricted by
the overwhelming crush of requests
pitched at a relatively trivial level
by the guiguts users over at d.p.
a new menu structure, for instance,
might be quite nice, but it's merely
painting the bikeshed another color.
a nicer color, yes, but nonetheless...
you could be frying much larger fish...
now, i'm not saying you shouldn't have
responded to the needs of those users,
however small, because that's important.
what i _am_ saying is that, at the same time,
that level of close focus is counterproductive
to the horizon view required by this situation.
i'll get to that shortly, but first we gotta do this...
> I would be happy to include ZML scripts
> and test cases with guiguts if they are
> shared with me.
i'm not gonna share any code with you.
there are too many people at d.p. who
have made me their enemy for me to be
actively aiding them in any direct way...
so no sharing. no way, no how.
and even if i _would_ share code with you,
you shouldn't take it, because those people
will not hesitate to turn on you if you did...
they might even reject future work by you
simply because you are _talking_ with me.
that's how petty-minded they are. really.
so any code you write has to be clean-room.
but that's not a problem. because it's simple.
further, i'll be releasing my own system that
does this same thing, for the general public
-- except, of course, without any of the silly
d.p. conventions -- so you'll have a model...
plus we can always talk, if you want to do so,
and i'll be happy to answer, on this listserve,
any questions you might have along the way.
***
i'll start by telling you what kind of code it is
that you need to write, for that horizon view...
well, actually, no, let's not do it that way.
instead, let me just tell you what i would like
to be writing, let's say 10 months from now,
to describe the "history" of what you will do,
written as an article for your favorite website.
here's the story, 10 months back to the future:
> blah blah blah about d.p. and guiguts
>
> and then pick up the story here...
>
> throughout the first half of this year (2012),
> hunter refined the text-to-html routine in
> guiguts, with an eye on "derivative formats",
> namely .mobi and .epub. he targeted each
> format with specifically-customized .html,
> and generated their required auxiliary files,
> so they could be produced "mid-workflow".
>
> because postprocessors could use hunter's
> converter-routine while doing their work,
> continuously confirming that it was correct,
> they grew comfortable with the process, and
> found that it saved them time and energy...
> plus the derivative formats were excellent.
>
> the derivatives also created more interest in
> smoothreading, even though some old hands
> still preferred to smoothread ascii versions.
>
> in light of this usefulness and their quality,
> p.g. started accepting hunter's derivatives
> in early spring, and by the year's mid-point,
> it was clear to all that this is a big success,
> since complaints about p.g. mobile formats
> almost immediately dropped to a dribble.
>
> "that's the best part," hunter said, "knowing
> that end-users are enjoying my derivatives.
> it's tremendously satisfying. i'm gratified."
>
> moreover, morale at d.p. is improving --
> the evil marcello had finally been defeated!
> -- and output even increased, by a full 15%.
>
> in an interview, hunter said it was simple:
> "the volunteers use d.p. pseudo-markup to
> indicate things like blockquotes and poems,
> italics, and especially the chapter headers,
> so i just translated it all into real .html and
> after that, it was a matter of figuring out
> the auxiliary files. overall, it wasn't hard.
> the proofers and formatters are the ones
> who do the work. you should thank them."
so, hunter, that's what i think you should code.
if you're interested, let me know, and we'll start.
i'll give you 10 tips. each will take me 1 minute.
no long lectures, or complications, i promise...
> If I understand, it is up to the WWers
> to decide whether to accept vanity epubs.
ok, let's be clear that we are _not_ talking about
"vanity" .epubs, whatever those things might be.
i think what you are saying is that p.g. generates
their own .epubs, and won't accept outside ones.
you are going to have that policy changed.
more specifically, hunter, you're gonna provide
the good reason that p.g. changes their policy.
via d.p., you will hand p.g. a conversion-app
that'll convert most books submitted by d.p.
into all the derivative formats, and do it well.
and y'all will _inform_ p.g. that d.p. wants p.g.
to use _this_ conversion-app, not marcello's,
because your app gives better results than his.
you'll insist that d.p. will not cater to marcello,
so p.g. insistence on it will lead to a dead-end.
and because your app does give better output,
and because p.g. cannot afford to tell you "no",
p.g. will accept your terms. it basically has to...
you don't have to do this as a "confrontation"...
marcello won't like it, no matter how you do it,
but you can smooth it over with everyone else.
it's clear to everyone, though, that d.p. people
don't like marcello. so when you tell p.g. this
is the only way d.p. will proceed, they'll agree.
so, to rephrase, your .epubs won't be "vanity".
they will be _the_standard_.
> Perhaps they would be more willing
> if someone gave them a tool to check epubs,
> i.e. explode them and check for a cover,
> valid HTML, etc.
once you complete the workflow transformation,
nobody will even have to bother to check an .epub.
you'll just know that it's right, because you know
that the script that made it does things correctly.
indeed, until you _know_ that, with certainty, you
haven't yet succeeded at re-making the workflow.
and here's the thing. you won't even send over the
derivative formats. p.g. will churn 'em on-the-fly.
you'll send over the .txt version, and that'll be that.
you won't even send over a "dedicated" .html version.
and again, this won't be hard. the derivative formats
will be the easiest. the only version which will cause
_any_ kind of friction will be the dedicated .html one.
and that's because a few postprocessors are used to
generating their special one-of-a-kind "snowflakes";
they'll scorn the "robotic" look of the dedicated .html.
but once they consider that the option is to continue
doing their "snowflakes" which get routed instead to
_marcello's_butcher-script_, they'll come around too.
which brings up this final note. marcello will try to
retain his power by taking your script as his own and
insisting that p.g. remain in control over conversions.
you need to let p.g. know that you are the boss here.
if d.p. wants to change something in the script, it will.
it's not gonna have to go and ask p.g. for permission.
p.g. can modify the script for books from other places,
but books from d.p. must be handled by the d.p. script.
or else before you know it, you'll find that you have to
dance according to the music being played by marcello.
mark my words on this.
so make sure d.p. stays in control. your people have
more experience on digitization than marcello has...
and once all your "snowflake" people decide that they
must resolve their inconsistencies, to dodge marcello,
you'll find that it won't take long to reach a consensus.
especially when they've realized that they don't have to
dumb-down their prize .html to make good derivatives.
they just have to find a common method of expression.
and once they do, they can just run a script to get that,
so they save time and energy, thus can do more books.
this is how you show this is really in their best interest,
that they don't have to sacrifice their values in any way.
gather them together, hunter, and you'll be their hero.
> Perhaps a system for crowdsourcing corrections
> could also be used for distributed PPing.
yes, but now is not the time to be distracted by that.
> I am working towards
> encapsulating guiguts functionality
> into libraries that could be used
> in a web based approach.
yes, that's nice, but again, bigger fish to fry...
believe me. once you do what i'm telling you,
all those other things will just fall into place...
once the workflow creates high-quality books
naturally and automatically, the content will
just start _flying_ out of the place. believe me.
-bowerbird
