- gutvol-d - lists.pglaf.org

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

one of the points we've been discussing
by Bowerbird＠aol.com 31 Oct '12

31 Oct '12

walt said: > It might be considered broken, I suppose, > if someone were to take PG HTML > and run their own conversion on it, so we agree that it is broken if someone were to do that... > It might be considered broken, I suppose, > if someone were to take PG HTML > and run their own conversion on it, > in ignorance of PG's approach. dear, i guess "in ignorance of p.g.'s approach" means "if they don't know that p.g. does this thing incorrectly". > Or if they were to take PG HTML > and use it directly in an ebook reader. again, again, we agree that it's broken if someone were to go and do _that_... > But if they take our epub output they'll be just fine, > because our epub output won't say "@media handheld" > once epubmaker gets done with it. so because an error introduced early in the process eventually gets deleted later in the process, if it goes that way, and gets that far, the error is not wrong? > And if they are running their own > conversions of PG books they should do so > with some knowledge of what they look like. since p.g. books -- including d.p. books -- are not produced with any dependable consistency, it is simply impossible to accrue such knowledge. which is one of the points we've been discussing on this listserve for the last 9 years i've been here. *** first it was .html proper which boasted that it would make content "reflowable" to any device out there... then, when that proved not to be true, the technocrats gave us c.s.s., which would make good on the promise. now, when c.s.s. has also proven not to be the answer, _media_queries_ are now the new "new and improved". and it all just keeps getting more and more complex. -bowerbird

1 0

get rid of all that smaller/bigger presentation cruft
by Bowerbird＠aol.com 30 Oct '12

30 Oct '12

vis-a-vis the "html best practices" thread going on at d.p., i thought i'd show don (and y'all) how i'd do that title-page, mostly just because i want to encourage use of jsbin.com... > http://jsbin.com/apokiv/5/edit yes, yes, i'd agree that it doesn't look _quite_ as nice as the other microtagged version, but i love the simplicity. -bowerbird

1 0