- gutvol-d - lists.pglaf.org

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

d.p. releases first public draft of document on html "best" practices
by Bowerbird＠aol.com 01 Nov '12

01 Nov '12

since nobody else seems to want to mention it... d.p. finally released the first public draft of its long-awaited position on html "best" practices. (read the thread to see why "best" is in quotes.) > http://www.pgdp.net/phpBB2/viewtopic.php?t=52308 since its release has been anticipated for so long, it strikes me as being just a touch underwhelming. but maybe there's more substance there than i see. -bowerbird

3 3

Requirements feasibility plan
by Robert Gibbins 01 Nov '12

01 Nov '12

On Oct 8th Lee Passey wrote: >4. Book titles should be marked with the <h1> element, "part" titles >should be marked with the <h2> element, chapter titles should be marked >with the <h3> element, "section" titles should be marked with the <h4> >element, and "sub-section" titles should be marked with the <h5> >element. If a title is composed of both a main title and a subtitle, the >subtitle should be distinguished from the main title by adding >"class='subtitle'" as an attribute of the title element. Author's names >in book titles should be indicated by <h1 class="author">. My question is whether writing, for example: <h3>CHAPTER 12</h3> <h3 class="subtitle">"WOULD YOU?"</h3> as I think Lee is suggesting above, has any advantages (or disadvantages) over what I currently do which is: <h3>CHAPTER 12</h3> <div class="chapter-title">"WOULD YOU?"</div> (N.B. I had in any case been thinking of changing what I currently do to: <h3>CHAPTER 12</h3> <div class="h3-title">"WOULD YOU?"</div> largely on the grounds that it seemed more general not to bind by suggestive naming that <h3> be used only for chapters, (although Lee seems to want to do this anyway). As implementing this change entails quite a lot of work, I would appreciate hearing any thoughts anyone has on this possibly rather trivial question. Bob Gibbins

5 5

"New Kindle Fire Review"
by James Adcock 01 Nov '12

01 Nov '12

I have to admit I am disappointed and disturbed that PG is publishing an anti-Kindle rant on its website home page. Especially since the content is untrue. I have a Kindle Fire and am not subjected to ads all the time. I do not have to download PG books first to my desktop computer and email them to my Kindle Fire, etc. So the review is clueless. There is indeed much to dislike about the Kindle Fire, and Amazon, just as there is much to dislike about the other ebook readers and ebook reader vendors, including Apple and Google and BN, etc. But an intelligent review of these issues would be one based on factual knowledge of the products - plural - and would discuss factually, based on actual real expert user knowledge, what each product can actually do and not do - and then would leave the purchase decision up to the end customer - rather than plugging one product as being the "solution." Having PG shilling for one vendor does not increase its credibility nor its prestige. Jim Adcock

7 19