- gutvol-d - lists.pglaf.org

Archiving of Raw Materials was Re: Re: DP output is technically obsolete
by Kevin Pulliam 20 Apr '10

20 Apr '10

On Tue, Apr 20, 2010 at 2:35 PM, don kretz <dakretz(a)gmail.com> wrote: > Summary of the situation (as it seems to me). > SNIP > > What can DP do in the reasonable short-term future that would be low risk > and low > effort? > > The first most obvious to me is to start getting serious about passing along > the > raw materials. Upload in as complete form as possible the matching image and > text files so future modification and adaptation is possible. There's no > loss to > DP by doing so; and the risk is that over time they are quite capable of > losing > track of them. SNIP Yes please. Please provide a complete archive of the project files (Scans, text, clearance docs, etc) in an obvious location for all projects and submissions (DP or otherwise). This can be at PG, at DP, at archive.org or elsewhere... I don't care where, so long as it has the same permanence of a PG text, and has the same 'lack' of barriers to access as PG texts. Just as open source projects literally require distribution of the un-compiled code so that future folks can see the foundation of the work as well as the finished product, so can ebooks benefit if future users can (if they choose) see the basis of the work as well as the finished product if they feel like offering an improved or altered version. Thanks! Kevin

1 0

the blind men and the .epub file-format
by Bowerbird＠aol.com 20 Apr '10

20 Apr '10

it's sad y'all know so much, yet so little, all at the same time. lee is correct. but he doesn't know what he's talking about. jim is correct. but he doesn't know what he's talking about. as lee says, an .epub file is just some (x)html files zipped up. as jim says, the .epub files at p.g. often differ from the .html. what neither one seems to know is that marcello's converter doesn't always use the .html; sometimes it uses the .txt file. i don't know the particulars, but it probably has something to do with the nature of the specifics within the .html file... -bowerbird

5 5

Re: Typesetting
by Bowerbird＠aol.com 20 Apr '10

20 Apr '10

jim said: > I want to read ePub or Mobi on a decent ebook reader > which will allow me to set things like font sizes and margins. try ibisreader. > http://ibisreader.com you can try it on your desktop machine to see if you like it. and it's on the ipad. plus it is under _active_ development. i don't know if "eucalyptus" is ipad-native yet, but when it is, i would definitely recommend that as a worthwhile viewer-app. (it has shortcomings, but from a reading perspective, it's fine.) -bowerbird

2 1

Re: the blind men and the .epub file-format
by Bowerbird＠aol.com 19 Apr '10

19 Apr '10

jim said: > Not sure what part of the elephant you've grabbed hold of, > but if you looked at the example in question it would be > obvious that your answer isn't. do you really think i'm going to let myself get wrestled into having a discussion with the blind men about the elephant? if so, think again. i said as much as i can in support of you -- you're half-right. so is lee... if you want to figure out the specifics from there, you're welcome to do so. but you'll be doing that without me. -bowerbird

1 0

Re: DP output is technically obsolete
by Bowerbird＠aol.com 19 Apr '10

19 Apr '10

tunelera said: > Perhaps some of the time that is spent ranting > about DP's work flow and DP's output could be > better put to use creating more informative FAQs > or even guidelines that DPers can use to create > output that fits into the current thinking about > acceptable HTML and/or other formats. my word, it must be "convenient" to simply _ignore_ all the work that i've done here in the last six years. to reiterate, i solved this problem a long time ago... *** michael said: > Worthy of a second look: > Marcello Perathoner said: hey, go ahead and look a second time if you like, but marcello is rarely worth the effort... to some extent, he's on the right track. then again, to that exact same extent, i've said the same thing, over and over, again and again, for years and years. i'm also smart enough to know that postprocessors at d.p. will not go for this approach. they _want_ to make it look pretty. that's why they do what they do. so you will never get them to strip down their .html. but that doesn't matter... if you jigger the workflow so it will create a text-file which has semantic rigor -- e.g., one in z.m.l. format -- you can use _that_ as "the master file" and still let the postprocessors play for as long as they like in fancy-markup disneyland. plus you will make the d.p. workflow more efficient. -bowerbird p.s. i'm also smart enough to know it is impossible to "target" .epub at this time, because of the huge inconsistencies in the way that it gets rendered by the various apps out there. if you focus on adobe's, you're gonna break your file for other viewer-apps, and vice-versa. it will take _years_ to gain stability. the .epub scene was mired in hype since its start... p.p.s. and if _you_ were smart enough, you'd know rfrank already tried to target .epub, but he gave up. d.p. is down right now, so i can't quote you the u.r.l., but use the forum search and you can find it easily...

1 0

Re: DP output is technically obsolete
by Bowerbird＠aol.com 19 Apr '10

19 Apr '10

carlo said: > Another issue is to automate the creation of txt from HTML. why do it backwards? when it's done correctly, the .txt file can create the .html... and an xhtml file, if that's what you want. and your .epub. plus it can generate whatever kind of .pdf you might want... don't you realize how stupid you sound when you say this? -bowerbird

2 2

Reporting errors in PG files (was Dim view of P3ers)
by Al Haines (shaw) 19 Apr '10

19 Apr '10

Jim Adcock wrote: >just as in PG-land the lack of standards are causing >texts to be distributed to users frequently missing or duplicating letters >and words and in some cases whole paragraphs. Errors in PG's files should be reported to the Errata system: errata2010_AT_pglaf.org Error reports should be as specific as possible. Mention the etext number, the line number(s), the line(s) of text in question, and the proposed correction(s) to each. If there are many errors, feel free to download and correct the existing files, and send them to the above address. (Don't re-wrap; don't touch the PG header or footer.) If you feel that a text can be fixed only by a complete re-do (maybe it's missing the illustrations, the index, or whatever), feel free to download a scanset, get a copyright clearance, and have at it. When the new fileset is submitted through the normal process, mention the text number that it's an update/correction/replacement for. The original producer's credit will be added to yours, the original etext will be archived, and the new version posted (under the original etext number). Simply complaining about errors isn't useful, nor are general complaints, especially concerning older texts, such as "italics aren't shown" or "all-caps are used for italics, not underscores". Al

4 5

Re: the idiots in charge
by Bowerbird＠aol.com 18 Apr '10

18 Apr '10

greg said: > -- Greg (a.k.a. one of the idiots in charge) well, good, at least you have a sense of humor about it. :+) look, i apologize if i have criticized anyone unduly, as my intentions are not to hurt anyone's feelings... we've discussed some of these topics over and over, and even though some solutions are rather _obvious_ and we seem to have people willing to implement 'em, nonetheless _nothing_ ever seems to get done. _ever._ and when the topics come up again, and again and again, the people in charge act as if dialog has never been held. so the only conclusion that seems plausible out here in volunteer-land is that nobody at the top is _listening_... -bowerbird

1 0

Seeking current/past bookshelf maintainers
by Greg Newby 18 Apr '10

18 Apr '10

We used to have a bookshelf@ alias, but I've lost track of who this is supposed to go to. If it's you, or you know who is (was?) maintaining the bookshelf area of the gutenberg.org wikispace, please drop me a note. This page is all we have for contact info, but it's currently a dead end: http://www.gutenberg.org/wiki/Gutenberg:Bookshelf_Contributions Thanks in advance. -- Greg (a.k.a. one of the idiots in charge)

2 1

Re: Typesetting
by Morasch＠aol.com 18 Apr '10

18 Apr '10

michael mcd said: > the PDF looks quite good. Offhand, though, > the page numbers look like they drop low enough > that they _could_ be out of the printable area. you're right. so i fixed that. download it again... > http://z-m-l.com/misc/14465-take5.pdf > shorter works are poor representatives of the problem still, you don't need 350 pages to cover the waterfront, especially when 315 of them have nothing happening... *** jim said: > First time I tried downloading this is didn’t work. Tried > it again later from a different computer and it worked. don't know what to tell you, jim. > Tried printing out the first 10 pages. > My printer reported that the document requested C5 page size > – but the C series is an envelope size? > I would have expected A4 or US “Letter” size. the pagesize is 5.5*8.5; that's what michael wanted. eventually, how you will print it out will depend on what you intend to do with it in terms of _binding_. for this preview, you have 2 convenient options... you can print it out 2-up, on letter-size, using the "layout" method you should find in the print dialog. for enhanced realism, slice pages down the middle. or you can print it out on 5.5*8.5, which is available at most any office-supplies stores, in my experience. we'll discuss printing and binding more, at a later time. > First Page title appears to print off center to the left. looks pretty dead-on centered to me, at least in the .pdf. did you print to 5.5*8.5 paper? if so, it should be right... > Contents in an unusually small font correct... my preference is for the contents section to be shown on 1 page, 2 pages max, so i had to cramp the font. i woulda reworked it manually if i wanted to take the time. reworking entails moving the chapters to the first page of each _book_ section, so the contents section up front just contains the entries relating to the _parts_ and the _books._ it's issues like these that get into the nitty-gritty questions on how automated you want the whole process to become. the easiest solution would be to run the table of contents over to 3 pages, or 4, or whatever it happens to be... but that approach doesn't produce a lot of satisfaction for me. so the question for me is, "how hard is it to automate what i would _really_ like to do in various situations like these?" since i was doing this by hand, to get on the same page with michael, i was willing to do a little manual massage. > Page numbers in an unusually large font the text-editor i used to create this .pdf does it that way, and as far as i can see, there's no way that i can control it. but that's not the way my program does it. so it's not something we really need to worry about... > Ragged Right is an unusual convention for a PDF document michael expressed no preference; ragged-right was easier. > Body font seems to be unusually small. i think so too. it's 10-point times new roman, i believe. (yep, that's it, checked.) but michael has the young eyes. what i was doing, in case it wasn't totally clear to people, was retaining the existing linebreaks from the p.g. e-text. in order to get (reasonable) half-inch margins on each side, i had to reduce point-size down to what _i_ feel is too small. ...but i wasn't doing this for me; i was doing it for michael... > Line length of approx 70 chars seems unusually long for a > book-like format. Most books use about 50 chars per line > of text because doing so makes the book more readable. so you didn't notice that i was using the existing p.g. linebreaks. there were several tip-offs. first and foremost, the first line of each paragraph is too long, because of the indent i introduced. second, the lines are more ragged than they should be, because line-length decisions are made on a monospace character count, not on a metric based on the line's proportionally-spaced width. (_any_ proportionally-spaced metric is better than monospacing, since the proportions are highly correlated across various fonts.) and thirdly, like i said, and you said, the line-lengths are too long. -bowerbird

1 0