|
i held up one response i'd written to kovidgoyal, to let others
have a chance in this conversation, without realizing that i'd
included a few responses to other people in that same post,
so here they are, separated out now...
***
nate said:
> I hope you aren't really comparing yourself to Mobipocket.
well, i'm not _french_, so i don't have the cool _accent_...
plus, in case you didn't notice, there _is_ a small difference
between _6_ figures (which is my minimum asking price)
and _7_ figures (which mobipocket was actually sold for)...
but if there's something you think mobi programmers did
that another programmer cannot do, well, then what is it?
(you can forget the d.r.m., because i'm religiously opposed.)
besides, the absence of a mobi mac version means i'm unimpressed.
***
chuck said:
> If the semantics of the book are automatically added into
> the PG text as XML tag pairs then three benefits will result:
> 1) An XML schema checker can validate that the semantics are valid.
> 2) An XSLT style sheet can easily, and on the fly, convert the book
> to ASCII, PostScript, HTML, Etc.
> 3) New style sheets can leverage existing annotated books to
> support new formats.
these are pretty much the standard arguments for x.m.l. markup...
and yeah, the main problem is step #3, in that there aren't any
"existing annotated books", and no easy way to create them...
> Given the existing support for parsing and processing XML
if you are aware of tools that actually provide "existing support",
you might want to go over to the distributed proofreaders forums
and let them know how they can use them, because they want 'em.
> it would be straightforward (although perhaps not easy), to
> create a copy editing tool which sucked in a book, added its
> best guess at what the semantics were (and there is great work
> to leverage from the ZML work here) and then generate
> an annotated result.
and this is the main reason why i'm _not_ turning my source code loose.
i don't want people using my hard-won routines to create x.m.l. markup.
> One might hope that all copy editors/proof readers can agree
> that something "Is a heading" without having to agree on how
> headings should be presented, or treated in the book presentation.
there's little disagreement on what the structures are in a given book.
human readers have figured that out fine for a few hundred years now,
thanks to the expertise of our whip-smart typographers along the way.
the difficulty is in programming this "intelligence" into a conversion tool.
the first tactic my antagonists over on the p.g. listserves tried to use was
that this required "artificial intelligence" that was too complex to program.
what i told them, and what i'll tell you as well, is that it's not all that hard...
you just have to work at it, and work at it some more, and then even more.
but it _can_ be done. i did it. and, you know, i'm not even mobipocket...
of course, you _could_ always just wait until i've mounted my mirror...
because then you'll be able to take advantage of the z.m.l. labeling of
every structure in every book, and use it to apply your heavy-markup.
oh, but then your heavy-markup won't be able to do anything more
than my light-markup, it'll just be more complicated to maintain and
more complicated for developers to add value. but, you know, you'll
have the library in the heavy-markup state you prefer, which is nice,
for you, i guess... maybe it'll help you you sleep better at night... :+)
but chuck, thank you, sincerely, for staying constructive in your post.
-bowerbird
|