hunter must gather, not scatter

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
participants (1)
-
Bowerbird@aol.com