- gutvol-d - lists.pglaf.org

re: [gutvol-d] here's that alice pdf
by Bowerbird＠aol.com 30 Sep '05

30 Sep '05

aaron said: > violent tongue-lashing excuse me? "pay attention dear" is "a violent tongue-lashing"? sheesh! as for anne's confusion in that thread, let's recall what mark twain said about the "one-word" difference between lightning and the lightning bug... now, can we get back on-topic please? according to the subject of _this_ message, the topic is my "alice in wonderland" .pdf... -bowerbird

2 1

re: [gutvol-d] Posting for List
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

catherine said: > I'm afraid I've stumbled into the wrong spot here. > I thought that this was a spot for newbie questions > such as what format to use, if illustrations should be > scanned and included with the text, etc. you're in the right spot, catherine. you can ask all those questions here. you can also visit the "f.a.q." webpages -- found at http://www.gutenberg.org -- where you'll find extensive information, on questions you don't even have yet... it sounds like you're working alone, but as several people have already told you, there are a lot of people working together at distributed proofreaders, so you should visit their website -- http://www.dp.net -- and see if communal effort appeals to you. if there's a part of the digitization process that you are not particularly fond of doing, you'll find people there who _like_ doing it, and will be glad to help you with that task. on the other hand, if you like doing all of it, and you prefer working alone, that's fine too. the important thing is to have fun. that's why we're all fighting here -- it's how we have fun... ;+) -bowerbird

2 1

on the issue of hand-crafted versus computer-generated .html versions
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

i noticed that e-text #16663 was "reposted" the other day. in .tei form. with a .pdf, an .html file, and a flock of text versions. so i took a look at it, and did some comparisons with the "original" versions, which were released earlier this month, on september 5th. i found the two .html versions looked quite a bit different. i preferred the look of the original, but that's personal taste. the second one -- by virtue of being the result of a conversion -- has the benefit of being "standardized", at least to some degree. (well, if we can assume that the conversion won't get changed.) the first one looked more like the .html had been hand-crafted, perhaps after an initial run through one of the .html converters. (though of course i can't say that with any degree of certainty.) if it's gonna be a practice to "deprecate" idiosyncratic .html versions that are being created by individuals over at distributed proofreaders, replacing them with versions that have been converted by machine, someone should start informing people not to make the original effort. when i brought up this very point a little while back, on the d.p. forums, juliet made a sharp public rebuke telling me not to "discourage" people. (i know, it's just not like her to do that in public, is it? but she did...) personally, i think _all_ the time people have spent over there making hand-tooled .html versions has been a big waste of energy; it would've been far smarter to perfect a text-to-html conversion routine instead... i see other instances, too, where distributed proofreaders appears to prefer to waste the time of volunteers to "keep 'em busy and happy", rather than ensuring that the workflow is as efficient as it could be... it must be nice to have that much energy at your command... one more thing: are we assured that the conversion routine is solid? or are "repostings" going to start happening with greater frequency? if you have to repost every separate variation from every .tei e-text every time the converter is changed, you could be doing that all day. for instance, in this version, there's a glitch on the chapter 18 header. when that's fixed -- which will only take a few seconds -- and the files are regenerated, which will also only take a couple seconds, will there be a whole other "reposting" then? because that will end up taking much more than a few seconds of time for more than a few people, including the people who mirror the library. i don't know the solution, other than to wonder why each of these variant files needs to be put in the library at all, if users will truly be able to generate them at will. which _is_ still the plan, isn't it? that they can generate them at will? setting all of their own options, in a simple way with a friendly interface? when do we get to see that part of the puzzle? and will marcello be telling people they can't have the font of their choice because p.g. "doesn't have a license to distribute it"? that would be a real bummer. this particular glitch is trivial from the viewpoint of usability of this text, but might be a sign that your quality-control checks need improvement. i caught this one because it had a black-on-white visible manifestation, but there could be many that don't, and they could come to haunt you. -bowerbird

4 3

re: [gutvol-d] bb's alice uses copyrighted font
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

aaron said: > This would require additional laws to be written. > So, do you have any examples of this? > Or is it more playground theorizing? do you believe that microsoft doesn't employ lobbyists? because if you do, i believe that you are badly mistaken. but when it comes down to it, having laws written only one of the ways the big corporations operate... another way, which they find to be extremely effective, is to _threaten_ legal action. even in cases where they have very little chance of winning, their adversaries will often shirk from a court fight against such deep pockets. but you already know this. don't you? > So companies make money > by hiring a bunch of accountants to keep busy, > shuffling money to their competitors, > and paying licensing fees gladly? well, they already _have_ the accountants... and yes, they pay their licensing fees "gladly", because that gives the system its legitimacy. and since -- even among their corporate kin -- they pretty much break even by this exchange, so they could forget the exercise entirely, except what it does is keep the little guy out in the cold. and _that_ is the big payoff for them, basically. it eliminates new competitors when they're little, and keeps all the cash in their kozy kountry klub... for the same reason, all the media companies have jacked up the price demanded when another entity wants to use their content in some other product. it's not a simple selfishness, because they have to pay _other_ companies as often as they _get_ paid. but what it _does_ do is "keep all the riffraff out"... all of a sudden, you need to be a big player to play. raising the price of entry for any new competitors is a well-known tactic in the world of big business. it is. they teach it in the business schools. they really do... > Just because a company joins forces with > a competitor to defeat one issue, it doesn't mean > that they are not in competition on everything else. actually, aaron, it is much more accurate to say that just because they compete on the showroom floors doesn't mean they don't cooperate on everything else. the biggest myth of current-day american capitalism is that the corporations are "competing" against each other. the "invisible hand" of today's marketplace is that they all have come to an implicit agreement to soak the consumer, by charging the highest price they can, and not the lowest. in order to do that, you have to choke off new competitors, the ones who'd snare customers by not playing by that rule. so they find a way to kill them, by raising the cost of entry... -bowerbird

1 0

re: [gutvol-d] here's that alice pdf
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

joey said: > How long do you intend to try and > use this thread as way to insult me? a listserve is a marketplace of truth. it has nothing to do with your pride. please stop taking things personally... -bowerbird

3 2

re: [gutvol-d] bb's alice uses copyrighted font
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

aaron said: > Wow! > That is the dumbest economic theory > I have ever heard in my life! then do i get some kind of prize? :+) > A company is going to spend money on > a bunch of lawyers that they don't need, > and pay for a bunch of licences that have > no legal standing, and some how this will > magically legitimize the thing which they are > paying for in the first place? Yep. Sure. > Makes plenty of sense to me. well, they won't pay for "licenses that have no legal standing", and no, microsoft is _not_ spending money on "a bunch of lawyers that they don't need", because they _do_ need 'em. and once they've got them, they'll put 'em to use. but otherwise, you've pretty much got it all right. a company with "more lawyers than a small country" _wants_ everything -- _everything_ -- to become a matter falling in the purview of the legal system. (and their lawyers are all to happy to make it happen.) > No news there. Companies have been > doing this for years and years. actually, it _did_ make the news when bill gates recently announced this as a goal for his company. and sure enough, the number of patent applications that microsoft has made lately has escalated greatly. maybe bill wasn't the first to do it. he very rarely is. but you can bet he will be the richest. he usually is... > It makes sense. Business isn't about competition > and making money, it's about protecting your competitors. making money _is_ about protecting yourself from competitors. and maybe you can't eliminate the ones who are as big as you, but you can most certainly strangle all the little ones in the crib. and those the competitors who are as big as you are? you'll find they're on the other side of the crib, willing to strangle with you... you don't think the big auto companies, for example, work together? sure, they compete on the salesroom floors. but when it comes to things like lobbying -- you know, the _important_ stuff -- they are best buddies. but an upstart car company, one making, let's say, a more-efficient electric car? it'd be promptly squashed like a bug... > Couching 9th grade conspiracy theories > between statements of fact which is > apparent to everyone > doesn't make them any less ridiculous. marcello just pegged me as a 5-year-old. now you have promoted me to 9th grade. i must be the only 5-year-old in the 9th grade. the one thing all of you seem incapable of doing is to ignore me. well, maybe there are two things, since y'all have a hard time staying on-topic too... *** hey look! there's a shiny test-suite, available now! > http://snowy.arsc.alaska.edu/bowerbird/test-suite/test-suite.zml > http://snowy.arsc.alaska.edu/bowerbird/test-suite/test-suite.html it purports to contain the range of features in the p.g. library! do you see any shortcomings in it? what would you include? -bowerbird

3 2

here's that alice pdf
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

here's that alice pdf i mentioned on friday. it's at: > http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01.pdf it doesn't represent a finished version, not quite yet, but i posted it because it demonstrates some issues. first of all, you should notice that it has no pimples, as i have exercised control over widows and orphans. in general, the pagebreaks are fairly good throughout. there are a couple i will improve -- can you find them? the biggest issue is that the typography is very dense. even with internet-style blocked paragraphs which have a full blank line between paragraphs, it's still too dense. one reason for the density is because i set the leading at 35 lines per page, and that's more than most books. (most p-books run anywhere from 27-31 lines per page.) the biggest reason for the dense typography -- and the rationale behind the small leading -- is because the lines are of very long length. the file has a line-length that is rather typical of the e-texts found in project gutenberg. (the longest line in the original alice30.txt is 77 characters; 33 lines are 66 characters long or longer. that's too long.) this long line-length is also why the margins are so small. with the font i used -- georgia, a font that was designed to look good on-screen _and_ in-print -- it was necessary to make the margins that small to get all the lines to fit. this was the case even with the type at a measly 9-point. (and 9-point is too small for printout, let alone the screen.) the point: project gutenberg line-lengths are far too long. furthermore, they're being calculated in the wrong manner. when you break lines according to simple character-count, the underlying assumption is the use of a monospaced font. and that's a bad assumption regarding people reading books, because nobody should read a book using a monospaced font; that's just inviting eye-strain and fatigue to ruin the experience. with as loudly as people complain about the unpleasantness of on-screen reading, we must do everything we can to nudge 'em into an experience that lessens the irritation as much as possible. instead of breaking lines according to character-count, we should break them according to _string-width_ in a _proportional_font_. although different fonts can vary greatly in terms of their width, the bulk of reading comprehension studies indicate that a length around 50 characters is optimal, so that's what we should aim at. (to equate the figures, 50 12-point characters is about 300 pixels.) as most of you know now, my viewer-program uses a 2-up display, the familiar facing-pages spread that most end-users associate with "a real book". what they usually say is, "it looks like a real book." (which brings up some questions about the nature of "reality". but let us just say that we know what they mean, and leave it at that...) i don't know if it's just a coincidence, or if there is a deep underlying reason that explains why, but it just so happens that a line-length of some 50 characters, with nice margins on both sides, makes a "page" that fits nicely in the 2-page-spread in the interface of my viewer-app. you can demonstrate this to yourself. open up your wordprocessor and load some text, choosing a fontsize that's comfortable for you; make the window-width convenient for reading for an extended time. unless i miss my bet, or you're lucky enough to have a cinema-screen, your window-width will be about one-half the width of your monitor... another indication of this general rule is the template for most blogs. look at a lot of them and you'll see that the left-quarter of the screen is typically used as a sidebar, and so is the right-quarter, which leaves the middle-half as the primary text-area containing the blog's content. (most templates don't resize this "main text" arena when the person makes the fontsize bigger than the standard-size, which is what they should do, for reading comprehension. that's true of non-blog sites too.) so -- in creating my z.m.l. versions of the project gutenberg e-texts -- i use a shorter line-length, and i have found that that works very well... i doubt the "powers that be" at project gutenberg will listen to me, but my suggestion is that you should use the shorter line-length too... of course, my viewer-app lets people remarginate the text at any time, so hard-wrapped lines at a longer length are not any type of _obstacle_, and it doesn't matter to me if project gutenberg's policy changes or not. i'm just suggesting it because it's an idea that has worked well for me... back to the alice .pdf, though, what you'll see is when lines are wrapped by their character-count, there are bad variations in their "true" length when they are converted into a proportional font. and that's unfortunate. in additional to the remargination that my viewer-program lets the user do, it will also adjust the "default" linebreaks that are computed in the new size, which will quite often create loose lines. in general, although i'm using a rather simple routine to do these adjustments -- because it has to be fast enough to work on-the-fly for real-time display -- i'm getting paragraphs that have very few loose lines. i'm quite happy with it. one reason i'm showing you this output with their original hard-wrapped lines is so that when i later show you output with the "default" soft-wrapped lines, you can compare them. and then when i show you output with my "adjusted" linebreaks, you'll be able to compare those results to the other two instances. (it's not that i expect anyone here to actually care that much, or even at all; but if there _does_ happen to be someone who does, i'll satisfy their curiosity. and i have typography friends elsewhere who find all of this _very_ interesting.) now for the other issues. for the most part, i think the design is straightforward. i'm sure some people will have opinions on things like the chapter-headings, and i would be happy to hear 'em, whether positive or negative. i'm especially open to constructive criticism, and would love to have graphic-design people chip in... the issue on which i would most like feedback is how to handle the illustrations. as you'll see (if you choose to look at the .pdf), what i did is that when a picture is called by the text, i have thrown a page-advance, and displayed that picture in whatever space happens to be remaining on that page, re-sizing the picture (down, since all of these images were the size of a full page). in many cases, that was perfectly fine, in that the picture was displayed at a large-enough size that its detail can be grasped sufficiently, even without using acrobat's zoom... in a few cases, though, the picture really isn't large enough to be appreciated. in one case -- ironically appropriate, the one about alice being "cramped" -- the remaining space was so small, the image is little more than a thumbnail. this "use-the-remaining-space" modus operandi is the one my viewer-app uses, and -- in the case of on-screen viewing -- it is entirely appropriate and reasonable. there, it doesn't matter if the picture is thumbnail-sized, because the reader can simply click on it and a larger version of it will be displayed for their examination. so, the question is, would this be an acceptable solution for a .pdf version too? i can turn each picture into a clickable link that will jump to a full-size graphic. is that what i should do? the down-side to that approach is that (i believe that) including each illustration twice -- once on the page where it is called, and then again on a page (at the end of the book) in a full-size version and all by itself -- will bloat the .pdf. in the case of "alice", for instance, there are 42 illustrations. including each of these on a page of their own at the end of the book would turn this 125-page .pdf into a 167-page .pdf. people wouldn't _have_ to print all 167 pages, if they didn't want to, they could just print up through page 125, so maybe that's not a big deal. but i'm wondering what y'all would recommend. another option would be to print each illustration at full-width where the text calls it, floating it to the next page if it won't fit in the space remaining on the current page. that might turn this into a 145-page .pdf (i'm just guessing, i haven't tried it out), which would have an impact when it came to a person printing out the entire book, but it wouldn't bloat the .pdf so badly because each graphic is only included once. i had a bunch of other ideas about how to deal with this little problem, but now i've forgotten what they were. which is ok, i guess, because this is long enough already. -bowerbird

14 26

re: [gutvol-d] on the issue of hand-crafted versus computer-generated .html vers
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

jared said: > TEI has my attention, you can bet on it. glad to hear it jared. the more people doing .tei e-texts, the faster the library will get converted to consistency... > The ability to use one TEI file to spew out output > in PDF, HTML, PDB and other formats is very interesting it certainly is! having one "master" format is _superior_ to trying to maintain a wide variety of different formats. it's an exercise in overkill to jump through all the hoops of .tei in order to get the benefit that you can get by concentrating on obtaining consistency _directly_, and much more easily, by choosing to make the _text_version_ your "master format"... but hey, as long as _you_ -- the people doing the .tei work -- don't mind wasting your time and energy jumping the hoops, _i_ certainly don't mind you wasting your time and energy... you might want to think twice about using "multiple formats" as your major selling-point in convincing people to move to .tei, because once they see my work and realize they can get those "multiple formats" just as easily from a text-file "master" format, they might become very reluctant to jump through your .tei hoops. > and the ability to do so also will > cut down on the time a PP'er needs > to do his or her book. right... a .tei workflow will make post-processing _so_ much easier. backlog? what backlog? right... > Yes, I know the HTML output will be > sort of "cookie-cutter", to be blunt well, that's a good thing, not a bad thing. it means that those files will be leveraged into the future because they'll be consistent. the way that "value" gets "added" to the e-texts is having other programs be able to process them. consistency allows those programs to do that job. the reason all those hand-crafted .html versions were a waste of time is because their idiosyncrasy means other programs can't grok their structure... > but you can easily hand-edit the HTML later > to fix problems posed by the TEI output. > Ditto with the text. no no no no no no no. first, "hand-editing" takes _time_ and_energy_. worse, it has to be re-done when you regenerate. and worst of all, it messes up that _consistency_ which i just mentioned above, which is the jewel... do _not_ do hand-editing! if you find you need to, then go back and rework the converter _instead_... improving the converter-routine is a _good_ use of time. it saves you work down the line, and keeps consistency... > TEI's not that hard to learn > (it's basically specialized XML, for lack of a better term) > and if you know HTML, you can do a TEI project. of course, if you used a text-version as the "master format", you wouldn't even have to know .html to make the e-texts... -bowerbird

2 1

re: [gutvol-d] a pdf intended for on-screen reading
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

marcello said: > Typographers are an obliging species. > They only care for exactly what > *you* want them to care for. actually, i only learned what to care about by listening very carefully to what they said. you could also learn much by listening to them. > Yes, please do! By all means! ok, you asked for it. > Make people know I already had a working pdf > by the time you first announced your vapourware reader. and oh how much your .pdf improved in the last two years! (and i'm not using one bit of sarcasm when i say that, either.) if it improves as much in the next two years, it might be finally worthy of someone's attention in the year 2007... > The first paragraph after each picture should not be indented. i don't agree. you can do it that way if you want. not me. > Those naughty typographers! They did > decide on something without asking you! they decided everything without asking me. i wasn't even born yet when most of these decisions were being hammered out in type. and i learned a lot from their work, but that doesn't mean i won't question a convention when i don't find the reason for it compelling. i think there are a few other conventions that i disagree with, in fact, but i can't think of them off the top of my head. if i remember, i'll tell you. at any rate, you are now outside of the range of constructive criticism, so i'll resume ignoring you, and see if anyone chooses to reiterate your points. so far, you have one person who reiterated one point. you might want to see if you can improve on that... -bowerbird

1 0

Re: [gutvol-d] User Options for Bowerbirds Reader So Far
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

marcello said: > Line justification or not, user option. > Keep hard linebreaks or not, user option. > Paper margins calling them "paper" margins is a deficiency in thinking, but yes, margins will usually be bigger when you go to paper than if you're creating a .pdf intended for on-screen reading. > Em-dashes ascii double-dash, or typographic em-dash. > Quotes straight or curly. > Hyphenation sorry, no option here. hyphenation has bad side-effects, and it's unnecessary. > Footnotes hyperlink displayed in the "workspace" area. > Pictures displayed on-the-screen as large as possible using empty space on that "page"; this picture being a hyperlink that causes the picture to be presented in the "workspace". the "gallery" allows the user to browse all of the pictures in the currently-active folder. (this will usually be the set of pictures for the book, but can also include pictures you have decided to "inject" in the book. more on that capability later...) > Pron filter "pron" won't get through many "filters" anymore... > Verse indented text can be displayed in a color of the user's choice, as can headers, emphasized text, search-strings, and the body-text. background color is configurable too. > Fonts any font on the user's machine. > Missing fonts there is no such thing. > all-lowercase display if that's what the user wants, yep. *** you missed a whole bunch more options. people can learn about those options by checking out this post on my blah-blah blog: > http://journals.aol.com/bowerbird/bowerbirdseyeview or, of course, they can, you know, actually _download_ the program and run it, at least if they're on a windows machine or a mac... just sign up for the beta-test listserve: > zml_talk-subscribe(a)yahoogroups.com not all of the options are currently in the app, but they'll get a good feel for the philosophy... -bowerbird

1 0