- gutvol-d - lists.pglaf.org

too bad he pooped out
by Bowerbird＠aol.com 11 Nov '12

11 Nov '12

it's really too bad that jim pooped out just when he was about to make his version of "huck finn" more valuable by allowing each page of the text to be directly compared to the relevant scan. so i did the work to restore pagebreaks. and then mounted the book in my interface: > http://zenmagiclove.com/huckj/wisdom.py as usual, you can adjust the size of the scan in your browser by resizing the window, and, of course, by the various other zoom modes. jim's errors are, for the most part, still there. as are any new ones which i have introduced. plus the end-line hyphenates were joined, so verisimilitude is not exactly what it should be. but i'd say that the main point has been made. -bowerbird

2 1

Re: [gutvol-d] about to finish up with huck
by Bowerbird＠aol.com 09 Nov '12

09 Nov '12

gee, jim, even when i specifically frame the issue, you seem incapable of acting in an intelligent way. the time-stamps _prove_ you spent _less_ than 10 minutes reading my post, thinking about it, and composing a reply. perhaps you need to read a little bit more carefully, and think about the conversation a little bit more thoughtfully. (right. like that's ever gonna happen. nice try, bird.) > Sure you are BB, go back and reread what you wrote > way back when I introduced this tool to this thread. i'm quite sure i was supportive of unwrappers back then, because i have _always_ been supportive of unwrapping... > Not at all, its trivial to find where a line of text > matches are particular page "matches are particular page"? what does that mean? > Not at all, its trivial to find where a line of text > matches are particular page since any modern > text display tool, including DJVU and PDF/A displays > include a "find" option to allow you to search on text. when the text was embedded in the .djvu or .pdf, yes... but that's not always the case. besides, you're then advocating that a search be run -- with the person entering a chunk of text from the line -- for every line you want to check. that's not optimal. i've done it that way. after a while, it gets to be painful. it's doable. but it's a far cry from being the _best_ way. (especially since you're juggling different applications.) it's far better to set up some kind of search criteria -- "show misspelled words", or "show italicized words" -- and have the tool automatically summon the scan for the appropriate page at the next hit on the search. (just the fact that you've integrated your text-handler and your scan-handler into _one_ app is a huge win.) the way you do it might "work", but it's not _efficient_, in the sense that it would scale into a process that can handle hundreds of books, let alone tens of thousands, in a way that the human cost justifies the digital benefit. (and you know we have millions of books online, right?) oh, and by the way, maybe just maybe if jim would have spent a minute to think about it, he would have realized that the reason a text-search in .djvu or .pdf _can_ lead you to the page-scan that contains that text is _precisely_ because those formats _retain_ that page-number info... if they tossed it out, the same way that jim tosses it out, then they would be in the same situation that he is in... then again, maybe just maybe jim could've spent _years_ thinking about that issue, and never had that realization. > Again, BB, the problem is that you live > in a BB-centric world where you believe > that the BB-approach is the "only way to fly." well, that certainly added to the value of this dialog, jim. (oh, and jim?, it's a good thing that .djvu and .pdf _also_ seem to live in my bb-centric world where we keep track of the relationship between every line of text and its scan, or you wouldn't have had anything idiotic to say up above.) > Well, again, PG could start by fixing their > on-going paragraph formatting problems. > That ain't exactly a high-tech problem! right after -- and i mean _right_after_ -- you talked about me "living in my own world", you went off and climbed up on your good ol' paragraph hobby-horse. i guess anything that allows you to make a connection, no matter how tenuous, to go off and ride that thing is all that you need, jim. but hey, at least we're done here. -bowerbird

1 0

Re: [gutvol-d] about to finish up with huck
by Bowerbird＠aol.com 09 Nov '12

09 Nov '12

jim said: > You are only interested in > wasting other people's time. jim, i think it's quite amusing, and very interesting, to be reminded why i stopped talking to you at all... because you act so idiotically some times. actually, make that _most_ of the time. so even when you make good points -- and you do, at times, make good points -- it's still not worthwhile to step through the manure of your obstacle-course... the new version of your text that you created there doesn't do _me_ any good. but it does lots for _you_. so i didn't "waste" your time. it's the exact opposite. to the contrary, i had you engage in a little task that upped the value _considerably_ for your pg#32325... (at least for the people who can locate your new file, and know that it has value in relation to pg#32325.) because now your "huck" can be directly compared to a scan-set archive.org essentially makes "canonical", by virtue of its being known and available world-wide. in comparison, the pg-rewrapped version of that text -- albeit otherwise exactly the same -- is _worthless._ so you didn't "waste" your time. you spent it _wisely_. > I seem to remember Marcello expressed an interest in it > [if only like BB to tear down the efforts of other] again, jim, stop with the idiotic actions/expressions. because, you know, if you do _enough_ idiotic things, people will start to _call_ you an idiot. for good reason. because only an idiot will do idiotic things _repeatedly._ i try to avoid such an attribution, because it is based on your _personality_, rather than your _actions_ -- like christians say, "hate the sin, but love the sinner" -- but you know that when you persist, it's difficult... so... i am certainly not "tearing down your efforts"... indeed, i'm just about the only person here who is making any argument that an unwrapper is useful. > for simple tasks such as unwrapping Huck it takes > literally about two seconds when run on a slow machine unwrapping could take two hours, and still be worthwhile. since it could save people about twenty hours in proofing. (and since we're talking about two hours for the computer, while we are off having a long lunch or a nice dinner, then it's merely a good excuse for a long lunch or a nice dinner.) > http://freekindlebooks.org/Dev/32325_unwrap.txt great. except that doesn't have any pagebreaks in it. makes it hard to check a line of text with the pagescan if you don't know what page the line of text occurs on... so, you know, you missed the whole point of the exercise. > I leave you to do the pagebreaks, why would i do them? i'm not interested in your e-book. > I leave you to do the pagebreaks, > if you were actually really interested, > which you aren't. i'm not interested in making your e-book more valuable. why would i be? i'm interested in the general question of what p.g. needs to do to make its e-books valuable enough to care about. but any particular book? well, not so much. especially not your version of "huck", since i already have _my_ version of "huck", which i know is the superior one... remember? i found a bunch of italics you had missed? > The point being that you keep trying to claim that > wrapping/unwrapping is some kind of impediment. i don't need to "claim" there is value in the ability to verify some digital text by comparing it to the relevant pagescan in a manner that is as direct as possible. that's _obvious_. the benefit derived from such functionality is clear and huge. only idiots would try to contest the worth of that capability. and yes, without any shred of doubt _whatsoever,_ having rewrapped text does indeed hinder such direct comparison. so, again, only an idiot would ever question that assertion. now, whether unwrapping can be done in such a way that it is so quick-and-easy that it fails to be any "impediment", i'm wide open to being convinced of that. i _hope_ it's true. but i've spent enough time unwrapping text that i'm skeptical you have made it quick-and-easy enough for "anyone" to do. but again, i _hope_ you have. i _want_ to believe you. i do. still, you haven't yet shown that to us. you've shown us that _you_ can do it. not that _anyone_ can. don't get me wrong. it's a great first-step. and it provides fantastic promise that we _could_ make it easy for anyone... but it's only the first step of the journey, not the end-point. you need to have other people do it, and say "it was easy", if you want to be convincing with your assertion that it's so. as it is, you have left much of your process enshrouded. we know that one of your files was the p.g. text. but what was the file that gave you the linebreaks? what kind of prep did you need to do to these files? (as a for-instance, did you delete the p.g. legalese?) how long did prep take? the entire process? and so on. give us the answers to these types of questions, jim, and have someone else do it, so we can hear their answers... > The point being that you keep trying to claim that > wrapping/unwrapping is some kind of impediment. it _is_. anything that gets in the way is an impediment. show us that you can _remove_ that impediment easily. > The point being that you keep trying to claim that > wrapping/unwrapping is some kind of impediment. > It isn't. Neither are pagebreaks, obviously, > because if one can put back in the original whitespace > known as "linebreaks" then it is even more trivial to > put back original whitespace known as "pagebreaks" and again, if it's _trivial_, then why didn't you do it? > which your workflow is interested am, and I am not. if you're uninterested in creating the best workflow, what are you even doing in this conversation at all? > You are only interested in wasting other people's time. the only waste of time that's happening here, now, is the one where i'm wasting my time responding to you. if you want to be productive, jim, you can do any of these: 1. restore the pagebreaks to the file you just made. 2. document the process you used to unwrap "huck". 3. write up a manual for your unwrapping program. 4. publicize your unwrapping program to the world. 5. rewrite your unwrapping program as a web-app. 6. describe the pseudo-code used in your program. and again, jim, just so i don't have to say it -- again! -- in my _next_ reply to you, should i be stupid enough to disregard the task of extraction from the adkins tar-pit, i know fully well that it's _possible_ to do unwrapping... i have done it, myself, countless times. i also know that the task can be relatively simple (emphasize "relatively"), because sometimes i have been able to make it simple... (i also know that sometimes it can be a bear.) _further_, i ascribe value to unwrapping, and will _welcome_ a tool that makes the task more quick and easy and transparent. i care about this; i spend my _own_ time on these matters. i may be the _only_ person on this list who cares about it. so don't take the stupid route of arguing these points, jim. because i don't have the patience to let you waste my time. if you want to do any of the 6 things above, then have at it. otherwise, opt out. -bowerbird

2 1

Re: [gutvol-d] about to finish up with huck
by Bowerbird＠aol.com 09 Nov '12

09 Nov '12

i said: > even there, the information isn't _that_ useful, > primarily because it's extremely difficult to > proof a rewrapped text against its scan-set. jim said: > It would be if there weren't software to > automatically unwrap the wrapped text. well, except your program doesn't run on my machine, jim. :+) besides, i don't think you've released your program, have you? not even to the list here, let alone to the world at large. right? further, although i have written such a program several times, i am still not satisfied that it is friendly and transparent enough, even for the relatively sophisticated person i'd expect as a user. and the brief exposure i had to some output from your program seemed like it was even more unfriendly than what mine gives... so i'm kinda skeptical. but fine, i'm always open for a demo. wrap your p.g. version of huck to the scan-set you used. better yet, give your app to someone else, and write up instructions for them (and all of us) how they can do it. don't forget that you need to include the pagebreaks too. and it would be best if you got the end-line-hyphenates exactly right, but it's ok if you join them on the top line or the bottom line, as long as it's consistent throughout. you just do the text. i'll code a tool to splice in the scans. take your time, jim. but if it's as quick-and-easy as you say... -bowerbird

2 1

about to finish up with huck
by Bowerbird＠aol.com 08 Nov '12

08 Nov '12

i said: > so it appears italics might be harder than we think. > even two passes, or three!, doesn't assure success. carlo said: > Something that DP discovered in 2004, and has led to the 2005 > reorganization making proofreading and markup separate tasks. um, perhaps i wasn't clear, or maybe carlo just missed the point, but i was saying that, even when we limit the focus to formatting, heck even _just_ italics, two or three passes might not be enough. now, if he needs me to be even more blunt, i'll say for carlo that even the two rounds of formatting at d.p. _might_ not be enough to assure a questioning observer that all of the italics were found. (and in case anyone might want to include the proofing rounds, you should know that proofers are instructed _not_ to do _any_ marking of italics, an instruction which is enforced quite strictly; moreover, many of the formatters _remove_ formatting that was done by proofers; there's even a button to erase it automatically.) i don't believe anyone has checked d.p. output thoroughly enough to make a judgment as to the completeness of their italics markup. (and here i'm not talking about the so-called "semantic" markup of italics which the so-called "best practices" document over there is now trying to install. i mean _missing_ the markup, _completely_.) so, no, carlo, your observation here has no relevance to my point... *** i understand that jim has informed the list which scan-set he used for his "huck". that's good information. but i don't intend to use it. my intent wasn't to criticize his performance, or in any way judge it. i don't think he did worse than any regular person, certainly not me. (i haven't even done a systematic search for italics myself, and won't. because i know i'm not too good at it; learned that a long time back.) the point is, though, that it doesn't do any good for this list to know the scan-set he used; that information needs to be in the p.g. e-text. and even there, the information isn't _that_ useful, primarily because it's extremely difficult to proof a rewrapped text against its scan-set. in other words, it's not enough to just tell us the scan-set you used. unless you give the end-users a version of your text which they can quickly and easily compare to the scan-set, they'll gravitate toward the entities that _do_ give them the basic capability of confirmation. but once again, i'm getting slightly ahead of myself. so, until later... -bowerbird p.s. robert, are you getting all your markup questions answered? because this probably isn't the best place to be asking about what needs to be done to make stuff work in the world of .epub/.mobi. i suggest you instead follow the #eprdctn twitter hashtag, which is used by people who are actually marking up e-books for a living...

2 1

Use of style attribute?
by Robert Gibbins 07 Nov '12

07 Nov '12

On 11/6/2012 Lee Passey wrote various examples of using the style atribute, for example: <h4 style="page-break-before:always><br />Chapter One</h4> At the end of the append, he wrote: > On the other hand, ><div class="center"> >with a corresponding CSS of >div.center{ text-align:center; } >doesn't make sense to me. The <div> isn't a "center", and there is no >reason you would want to alter its presentation. If it's supposed to be >centered, and there is no real presentational alternative, just put the >styling right on the element to be styled. Personally I rather like this idea as it neatly gets me out of another problem I thought was unavoidable, namely the need to have a whole series of classes in a generic css file which only differ by a parameter value, for example: /* - - - Left margins */ div.margin-left-1 {margin-left: 0.5em} div.margin-left-2 {margin-left: 1em} div.margin-left-3 {margin-left: 1.5em} div.margin-left-5 {margin-left: 2.5em} div.margin-left-7 {margin-left: 3.5em} div.margin-left-10 {margin-left: 5em} div.margin-left-15 {margin-left: 7.5em} div.margin-left-20 {margin-left: 10em} div.margin-left-25 {margin-left: 12.5em} (What would be nice is to have parameters in class definitions to get round this, hypothetically somewhat as follows: <* - - - Left margins */ div.margin-left(n number) {margin-left: n em} Syntactically this is nonsense, but I hope it is reasonably clear what I would like to be able to do.) Lee's scheme seems to offer another way round this problem, namely that one would merely at the appropriate point in the text mark up with <div style="margin-left: n em">text content</div> thus not needing any css classes at all. However the reason I didn't go this way to start with is that use of the style attribute appears to be deprecated in both the epub 2 and epub 3 specifications. I assume this means that sooner or later the standard will drop support for it. Have I misunderstood? Bob Gibbins

2 2

Re: [gutvol-d] use of style attribute?
by Bowerbird＠aol.com 07 Nov '12

07 Nov '12

robert said: > the reason I didn't go this way to start with is that > use of the style attribute appears to be deprecated > in both the epub 2 and epub 3 specifications. where did you get that impression? > Have I misunderstood? i think you have. i'd check that again if i were you. -bowerbird

1 0

Preventing vertical margin collapsing across page breaks
by Robert Gibbins 07 Nov '12

07 Nov '12

Some time ago I realised that although one can (at least in an epub reader) force a "page break" by dividing an html page into multiple divisions, each of which has the style {page-break-before: always}, the (vertical) margin-bottom of the last element in a previous page and the margin-top in the succeeding page collapse into each other using the usual HTML rules on vertical margin collapsing. The practical effect of this is that unless the last element of the previous page is exactly at the bottom of that page, the margin-top of first element of the succeeding page effectively does not appear in the succeeding page. Currently I get round this problem by starting each division which forces a page-break with: <div class="margin-top-anchor>&nbsp</div> Where the css contains: div.margin-top-anchor {line-height: 100%; margin-top: 0em; margin-bottom: -1em} i.e. so that each division starts (I hope) with a zero height line which 'anchors' the margin-top of the next element onto its own page. I had to think of this myself, once I realised what the problem was, and it does feel a bit like an ugly kludge (for example the zero height line still has a non-breaking space at its start). I wonder if any one knows a better way to achieve the same end. Bob Gibbins

3 3

about to finish up with huck
by Bowerbird＠aol.com 06 Nov '12

06 Nov '12

i'm about to finish up "the adventures of huck finn". it has certainly been an interesting ride, to be sure... i'll do a thorough debriefing later this week, but... just to take care of one thing i'd discussed before, i located even more italics which had been missed, thanks to text scraped from the mark twain project (who, it seems, used a different edition themselves, so we've now seen at least 3, and maybe 4, so far). so it appears italics might be harder than we think. even two passes, or three!, doesn't assure success. neither david nor jim seem to have done very well. (i can't quantify their performance, since as far as i know, neither one of them specified their source, but it's pretty safe to say they missed some italics.) maybe formatters at d.p. are very good at italics... that would not surprise me. but it also would not surprise me to discover many p.g. books currently have many errors in regard to having missed italics. of course, if one doesn't have the scans to _check,_ it makes it pretty difficult to know if there are flaws. which might be considered as a "blessing", i guess... unless it's considered a _curse_, and a damning one. because, without the scans, you can't prove that you have it _correct_, either, which you might want to do. but now i have strayed into the debriefing territory... so i will close for today... also, i've already had requests for my cleaned text for "pride and prejudice" and "the adventures of huck finn", so p.g. is welcome to go take them if p.g. wants them. i'm not gonna "submit" them, but if you _want_ them... but if you _do_ take the text, please get the scans too. -bowerbird p.s. i will shortly be unleashing a big explosion as well. (working on "huck" was my way of procrastinating that.) been doing python stuff and javascript code all this year, and i'm about to tie it to my previous work and... boom! so if anyone wants to preview my samples, let me know.

3 2

it's time for p.g. to find a new webmaster
by Bowerbird＠aol.com 01 Nov '12

01 Nov '12

somebody had to say it. so i did. -bowerbird

1 0