September 2005 - gutvol-d - lists.pglaf.org

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

Re: [gutvol-d] on the issue of hand-crafted versus computer-generated .html vers
by Joshua Hutchinson 29 Sep '05

29 Sep '05

I know I said I don't read your stuff, but in this case someone brought it to my attention. You, sir, are a numbskull. The same gentleman that did the original "idiosyncratic" .html is the same person that redid his work as a TEI master and reposted it. It was both a learning experience for him *AND* provided a format that was not previously available (PDF). Furthermore, the WW'ers won't take blind format conversion reposts from anyone but the original poster. Too much work for too little return investment is the reasoning, I believe. But watch out, Mr Bird, there are more TEI postings coming. The idea is getting some decent attention over at DP. Josh PS He did get one thing right. There is a typo in chapter 18 heading. It took less time to fix it and send to David that to write this short e-mail. ----- Original Message ----- From: Bowerbird(a)aol.com To: gutvol-d(a)lists.pglaf.org, Bowerbird(a)aol.com Subject: [gutvol-d] on the issue of hand-crafted versus computer-generated .html versions Date: Thu, 29 Sep 2005 12:33:01 EDT > > 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 > > > _______________________________________________ > gutvol-d mailing list > gutvol-d(a)lists.pglaf.org > http://lists.pglaf.org/listinfo.cgi/gutvol-d

2 1

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

29 Sep '05

marcello said: > I liked it better when you simply put all your efforts into > being the village idiot instead of also trying to cruft together > with great pomp and circumstance small demos that > a five-year-old could do better in half an hour. see joey, i don't take things like this personally. what's the point? how much currency do such things have in a marketplace of truth? -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: > I see with pleasure that you have > implemented many of my suggestions > and made your page blackness more even. i haven't "implemented" even one of your suggestions; any changes i made are ones i always intended to make. you've commented on my first two alice versions. would you like me to comment on _your_ first two? the ones that go back to 2003? i can, if you want. and let me remind people that i never did go back and fully critique your _current_ .pdf, due to its "pimples". there are a number of other comments i could make... so if i were you, marcello, i wouldn't be throwing stones. indeed, as i said a while back, your best course of action would be to decide to refrain from commenting at all. because i _am_ going to run circles around your .tei... > You made such a horrible fuzz about widow *lines* > that I wonder why you dont care a bit about widow *words*? > A paragraph should never end with a line containing > one single word, (like 'sing' on page 100). well, most typographers aren't concerned about "widow words". but some are. and, if doing so doesn't cause a worse problem, my program will strive to eliminate even these "widow words"... so far, you haven't seen _any_ of my line-wrapping adjustments. but you will. > A truly knowledgeable typographer would > laugh into your face on seeing this. even the typographers who do care about "widow words" won't laugh in your face if you haven't controlled for them. the mandate simply is not that great. > Why do you use both, an empty line *and* an indent > to mark paragraphs? One kind of markup is enough. selection of which one to use -- or both -- is a user option. while i usually prefer the "blocked" style, with no indent at all, i've chosen to display the indents in these examples because -- as i said -- a while back there was a big (tempestinateapot) controversy about whether my format would _incorrectly_ indent some "pseudo-paragraphs", so i wanted to demonstrate that it actually does a very accurate job. do you see any errors? but it's simply not accurate that "one kind of markup is enough" in this particular regard. book typographers do indent paragraphs -- almost universally -- but many use a "space above" value too. (which is essentially what my blank line above each paragraph is.) and in my option to have blank lines displayed, the choice is _not_ a binary one (show blank lines or not), but rather a _percentage_. if the user chooses 100%, then they will get a "full-size" blank line. if they choose 50%, they'll get "half" a blank line. but the lowest setting that i allow is 20%. (or maybe it's 25%. can't remember.) so they are _always_ gonna get _some_ space above a paragraph, even if it's only as little as one-fifth the size of a "full" blank line... one reason for that is to reproduce that "space above" component. the user can add as much or as little as their own tastes dictate. but also, if there are two blank lines -- indicating a thought-break -- the user can readily discern that from the display. if i were to shrink the blank lines away entirely, thought-breaks wouldn't be noticeable. (i could solve this problem another way, by flagging thought-breaks, but the "space-above" strategy is one i wanted to include anyway.) > Also: the first paragraph in a chapter should not be indented. ah! you got something right! that is indeed the prevailing convention. it is also one that i have never agreed with, so i did my implementation the way i like it. i like programming, because i make the rules. maybe i'll give users the option. maybe not. > The margins are still too small. they're just right for an on-screen .pdf. which is just what this is an example of. but margins are definitely a user-option, so there's no use even discussing it here. > Your images don't align with the bottom line > of the text on the facing page. they will, when i finalize the positioning. right now, i think the image-caption is still a bit too close to the line above it. as soon as i've got that how i want it, then i'll worry about the picture bottom. > Some of your poetry is coming out > in a washed-out pink (147). those are lines that need to be "chopped". for the time being, i have indicated that by showing them in smaller type, and that color. thank you for your feedback, even though i said work is ongoing and feedback wasn't necessary. this post was within range of being constructive. (but just barely.) -bowerbird

2 1

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

29 Sep '05

marcello said: > Your poetry stinks ! wrong again. it sucks. -bowerbird

1 0

User Options for Bowerbirds Reader So Far
by Marcello Perathoner 29 Sep '05

29 Sep '05

Proposal for the option page of BBs reader program (work in progress): Current defaults are marked with: X Line justification [X] Keep hard linebreaks [ ] Dont justify [ ] Use ragged right Paper margins [X] Tiny margins [ ] No margins [ ] Print over the border Em-dashes [X] Print as -- [ ] Print as typographical em-dash Quotes [X] Use ugly ascii quotes [ ] Use typographical quotes Hyphenation [X] Don't hyphenate [ ] Avoid hyphenation [ ] Hyphenation: off Footnotes [ ] At page bottom [X] At book end Pictures [ ] Resize to poststamp size [ ] Resize to flyspeck size [X] Resize at random Pron filter [ ] Drop pron pictures, keep others [ ] Keep pron pictures, drop others [X] Drop random pictures Verse [X] Print verse in alternating washed-out pink and black [ ] Print all verse in washed-out pink [ ] Print haikus in `plum blossom' Fonts [X] Use only pirated fonts [ ] Use only legal fonts [ ] Don't use fonts. Show pictures only Missing fonts [ ] Download pirated fonts from eDonkey [ ] Download pirated fonts from Gnutella [ ] Look for pirated games while you are there -- Marcello Perathoner webmaster(a)gutenberg.org

1 0

a pdf intended for on-screen reading
by Bowerbird＠aol.com 29 Sep '05

29 Sep '05

the latest version of an "alice" .pdf is available at: > http://snowy.arsc.alaska.edu/bowerbird/alice01/alice01/alice01b.pdf work on this continues in an ongoing fashion, so there is no need for feedback on this one; i share it because its larger type demonstrates a .pdf created for the monitor, not for printing. -bowerbird

2 1

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

29 Sep '05

josh said: > But watch out, Mr Bird, there are more TEI postings coming. as i've said many times, i look forward to .tei versions... every .tei e-text means an ascii version that is _consistent_. compared to the quicksand of inconsistency currently, that's a blessing. i can do a lot with consistent e-texts. i would assume, though, that you will initially handle the thousands of e-texts that look just like #16663 -- that is, dirt-simple from the standpoint of markup. that's fine. it's only natural to do the easy work first. but you might want to take a look at my test-suite, to start thinking about how you'll handle other stuff. because once you're confident that you can handle everything that the library will throw at you, you can proceed with more vigor, because it will _all_ be easy. meanwhile, you should _definitely_ inform all volunteers at distributed proofreaders to stop doing .html by hand. -bowerbird

1 0

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

29 Sep '05

josh said: > I do know big companies like Microsoft, who > employ more lawyers than some small countries boast, > have paid a lot of money in the past for licenses for fonts, > which they wouldn't need if there were > no copyright attached to the typefaces. perhaps what their "need" is, in this situation, is to legitimize a form of highway robbery that they intend on using themselves to the fullest... i'm sure you heard bill gates recently escalated the number of patents for which microsoft applies. no, there was no sudden leap in their "innovation", but just a policy-shift that reflected their belief that (ab)use of the patent process was a new goldmine... all of the big corporations pay licensing fees gladly. they realize that -- among themselves -- they're just shuffling a lot of cash back and forth in the process -- which they don't mind, it keeps their accountants busy -- so none of them really _make_ a lot, or _lose_ a lot... but the real benefit accrues to them by virtue of the fact that this practice raises the cost of entry for new players... they realize they can't knock each other out, but they can work together to ensure that nobody else enters the ring... -bowerbird

2 1

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

29 Sep '05

david said: > It gives me a better printout than anything else I've seen can. the .pdf that my viewer-program creates is virtually a _screen-dump_ of its display in normal operation. (it's more work than a screen-dump, because a screen-dump doesn't allow the text to be _searchable_, but it's a re-creation of the screen.) so if/when i get the .pdf looking pretty, it will be because the on-screen display looked pretty to begin with. > And I don't think that "allow[ing] the end user to have the > maximum amount of input as to the which rendering decisions are made" > is a good idea. Options take time to code, most people don't care about > widows and orphans, and a page full of mysterious options > (and I suspect widows and orphans fall into that classification for many users) > is a way to drive away many users. i understand your point, and agree with it to some extent. but i probably disagree with it more than i agree with it... first, people _do_ care about widows and orphans. even if they don't know what they are. what they _do_ know is that "this page looks a little clunky". i mean, face it, even the typographically-challenged notice when a whole page has one single line of type. they won't call it "an orphan". but they will laugh... and while it is true that "options take time to code" (by which i take it you mean "selecting options takes time for the user to do", and not to "program" per se), the lesson of that observation is having the right defaults. and strict control of widows/orphans _is_ the right default. do a good job of setting up your defaults all the way around, and naive users won't ever have to go to the options screen. but it's still there for sophisticated users who _do_ want. it... perhaps more ideally, a great program will _teach_ its users about its options, in a manner that is gentle and informative. it is not a good program that wants to keep its users stupid... throwing a lot of options at a user who doesn't understand them is obviously not a good way to proceed. but taking away options is not the best alternative, especially not in the world of e-books, where the availability of those options is one of the chief appeals. -bowerbird

1 0