MobileRead Forums - View Single Post - What "Cleaning Up" Do Project Gutenberg Texts Need [closed]

bowerbird · 11-03-2007, 05:03 PM

happymartin said:
> The only thing I'm not keen on is the "white space is free so use it liberally".
> I have some books with so much white space that I need to change pages
> very frequently. Drains the battery and slows everything down with the
> slower e ink refresh rates.

thank you so much. this is something that never would've occurred to me.

one reason, of course, is because my focus was on "beautiful typography".

but another reason is just because i don't consider issues like battery life,
so your post has helped push out the edges of my thinking, and i like that.

however, this is just a list of tactics i have seen used. some of 'em might
be totally inappropriate in some situations. that's the nature of the beast.

moreover, some of 'em are subjective, depending on personal preference.
or, as in this case, subject to other concerns, such as battery-life effects.

what it boils down to is that the e-book must be created by the individual;
it should be customized to the preferences active in the particular situation.

this is one of my _guiding_ principles. the z.m.l. format is _a_format_,
which is brought to life by a viewer (or converter) that lets an end-user
customize the book to their specs. so if you want big margins, order them.
if you want small margins, just say so. specify the pagesize, the fontsize,
the font, the colors, nearly everything in the e-book is under your control.

it's folly to think that you can create a .pdf that will make everyone happy.
there's just too much idiosyncrasy in our preferences. so we need to make
our e-books as _flexible_ as possible, so they can take whatever form is
desired by each specific individual in each specific situation. any system
that doesn't give such flexibility to readers is, in my eyes, simply doomed.

beauty is in the eye of the beholder.

so we don't need to even discuss justified/ragged or tight/loose leading
or any of the many issues. we need to make sure we give customization.

***

robert said:
> inadequate

interesting how some people want to make your decisions for you, isn't it?
the proof is in the pudding. the proof is in the pudding.

***

rwood said:
> So his questions were really a set-up for his ZML scheme.

and interesting how quickly some people jump to the wrong conclusion.

no, the question isn't a "set-up" for anything. it's a legitimate topic --
and it grew here directly out of the observation made by vivaldirules,
an observation back in the thread in which this was originally posted.

and, as indicated by the substantial head-start i provided with my list,
it's a topic i've done a lot of thought on, thought that i shared with you,
in a list people can now use as a guide in their own beautification efforts.

> Just what we need, another new format.

well gee, i suppose if i introduced it as "the format to end all formats",
maybe it would be ok with you? just like openreader, or oeb, or epub?

the fact of the matter is that it'll be the marketplace that decides on
which format prevails, and until that decision is made (which might
take several decades), there's no reason for any contender to defer...

contrary to what some people believe, a large number of formats does
_not_ hold back a technology when its time has come, as proven by
the huge growth of word-processing despite a plethora of formats...

> I'll stick to what I use now thank you.

what _you_ use, now or later, is immaterial to the rest of the world...

but let me be totally clear. i'm not making a big push for my format.
that kind of hype and spin won't work anyway, as openreader showed.

what i'm going to do is mount the entire p.g. library using my format,
and demonstrate how a simple-but-powerful format can prove itself
by delivering a tremendous cost-benefit ratio to authors and readers,
even without backing from deep pockets like those of amazon or adobe.

besides, plain-ascii as a format has _already_ proven its value clearly.
the only problem with the format is that it's _ugly_, and that is why
i'm concentrating on making it _beautiful_ and even _more_ powerful.

***

jswolf said:
> The problem (in my opinion) with ZML is that it's non-standard.

it will be a standard some day. well, maybe not z.m.l. per se, but
_some_ form of light markup. the current leader is "markdown",
which is being used all over cyberspace, including in wordpress...
it's getting play in all kinds of software. heck, the actual _manual_
for textmate -- a text-editor highly regarded by mac technoids --
is made in markdown. the light-markup revolution is unstoppable,
because ordinary people don't want the hassle of doing markup...

heck, you can see traces of it in the comment-box in this forum,
where a u.r.l. is automatically turned into the appropriate hyperlink.
that's the exact type of thing that light-markup does for a person,
and there's no earthly reason why we wouldn't want such assistance.

furthermore, you will find that markdown has a _lot_ of support.
(if you want to do a google search, use "markdown and textile" to
avoid false alarms from merchants offering a "markdown" in price.
"textile" is another form of light markup.) one of my _favorite_
markdown-related sites is a live authoring site called "showdown":
> http://www.attacklab.net/showdown-gui.html
i encourage you to try it. see how easy and powerful markdown is.

oh yeah, most of the light-markup systems output (x)html, so
the argument that light-markup is "nonstandard" is kinda silly.
heck, markdown was made, and is maintained by, standardistas.

z.m.l. and other light-markup systems know the _structure_ of
the document -- they know exactly what each element _is_ --
so they can generate any kind of "standard" output you want...

> There are NO converters that will read it and convert it into
> something that can then be used to generate a book that will be
> readable on a portable book reader.

well, _i_ am making converters for z.m.l.

i have already done some, and i will do more...
so it's totally inaccurate to say there are none.

more importantly, the rules are so simple that any programmer can
make a converter, really. it doesn't take much coding chops to do it.

even a z.m.l. _viewer-program_ is a fairly easy programming task, and
converters are an order of magnitude easier than making a viewer-app.
(you mean i don't have to _handle_ the footnote, just _mark_it_? cool!)

.html from my converter works fine on the web, my current objective.
soon i will do whatever tweaks are necessary to make sure it converts
well to mobipocket, since amazon will keep that format alive for years.
and i'll probably target the rocketbook, for romantic historical reasons.

as for other formats, the numbers on plucker indicate i can ignore that.

and with the iliad and sony supporting .pdf (which i can convert well),
i can see no good reason to make a converter into their other formats.

and again, z.m.l. viewer-apps are easy enough to program and port
that there'll be one for every important platform before you know it,
so i don't see conversions being all that important in the long run...

i'm of the opinion that the iphone will become the common denominator
we have to consider, and through its web-browser, i already support it...

> What is is about ZML that make it that much better then HTML?

it's easier for developers to add value around the simple format of z.m.l.
than to try and engineer around all of the markup cruft in an .html file...

surely you know the gamut of rationale in support of plain-text files,
and the usefulness of the tool-chain that can take advantage of them...

plus, the z.m.l. viewer-program is built specifically for the task of books
(and long documents composed of many "chapters"/sections in general),
so they give a superior reading experience over the clunky web-browser.

but again, i'm not trying to "sell" you on z.m.l. if you like your .html, fine.
go ahead and use it. i'm aiming at authors who don't want to do markup,
but still want to offer to their readers a high-powered e-book experience.

> And then you go wanting to use ZML which is not a standard at all
> that nobody can use to convert to something they can actually read.

well, you're simply wrong that "nobody" can use z.m.l. to do conversions.

did you visit the web-pages i pointed to up above?
> http://z-m-l.com/go/vl3.pl
> http://z-m-l.com/go/zmldingus093.pl

you can see conversions in action.

and here's a .pdf conversion i did as a demo that you can look at:
> http://z-m-l.com/oyayr/oya-sunday.pdf
40+ sections and 120+ footnotes in that baby, most with weblinks.

i wanted to retain the same linebreaks (mostly) as the .pdf i was
duplicating, which meant that i had to make the type too small
for you to read it on a sonyreader, but i think you will agree that
i've demonstrated that z.m.l. can convert well to the .pdf format.
(although i'm wide open to any constructive criticism you have.)

i understand and actively support your desire for a range of tools
that support a format. i've been working for a long time to create
a z.m.l. toolchain that arcs the entire workflow of electronic-books,
from the beginning stages of authoring, to web-based publishing,
continuing through conversion, and extending through remixing...

-bowerbird

p.s. sorry for the long message. i guess igorsk is gonna have
a whole lotta whitespace in his browser when he encounters this.

11-03-2007, 05:03 PM	#33
bowerbird Banned Posts: 269 Karma: -273 Join Date: Sep 2006 Location: los angeles	happymartin said: > The only thing I'm not keen on is the "white space is free so use it liberally". > I have some books with so much white space that I need to change pages > very frequently. Drains the battery and slows everything down with the > slower e ink refresh rates. thank you so much. this is something that never would've occurred to me. one reason, of course, is because my focus was on "beautiful typography". but another reason is just because i don't consider issues like battery life, so your post has helped push out the edges of my thinking, and i like that. however, this is just a list of tactics i have seen used. some of 'em might be totally inappropriate in some situations. that's the nature of the beast. moreover, some of 'em are subjective, depending on personal preference. or, as in this case, subject to other concerns, such as battery-life effects. what it boils down to is that the e-book must be created by the individual; it should be customized to the preferences active in the particular situation. this is one of my _guiding_ principles. the z.m.l. format is _a_format_, which is brought to life by a viewer (or converter) that lets an end-user customize the book to their specs. so if you want big margins, order them. if you want small margins, just say so. specify the pagesize, the fontsize, the font, the colors, nearly everything in the e-book is under your control. it's folly to think that you can create a .pdf that will make everyone happy. there's just too much idiosyncrasy in our preferences. so we need to make our e-books as _flexible_ as possible, so they can take whatever form is desired by each specific individual in each specific situation. any system that doesn't give such flexibility to readers is, in my eyes, simply doomed. beauty is in the eye of the beholder. so we don't need to even discuss justified/ragged or tight/loose leading or any of the many issues. we need to make sure we give customization. * robert said: > inadequate interesting how some people want to make your decisions for you, isn't it? the proof is in the pudding. the proof is in the pudding. * rwood said: > So his questions were really a set-up for his ZML scheme. and interesting how quickly some people jump to the wrong conclusion. no, the question isn't a "set-up" for anything. it's a legitimate topic -- and it grew here directly out of the observation made by vivaldirules, an observation back in the thread in which this was originally posted. and, as indicated by the substantial head-start i provided with my list, it's a topic i've done a lot of thought on, thought that i shared with you, in a list people can now use as a guide in their own beautification efforts. > Just what we need, another new format. well gee, i suppose if i introduced it as "the format to end all formats", maybe it would be ok with you? just like openreader, or oeb, or epub? the fact of the matter is that it'll be the marketplace that decides on which format prevails, and until that decision is made (which might take several decades), there's no reason for any contender to defer... contrary to what some people believe, a large number of formats does _not_ hold back a technology when its time has come, as proven by the huge growth of word-processing despite a plethora of formats... > I'll stick to what I use now thank you. what _you_ use, now or later, is immaterial to the rest of the world... but let me be totally clear. i'm not making a big push for my format. that kind of hype and spin won't work anyway, as openreader showed. what i'm going to do is mount the entire p.g. library using my format, and demonstrate how a simple-but-powerful format can prove itself by delivering a tremendous cost-benefit ratio to authors and readers, even without backing from deep pockets like those of amazon or adobe. besides, plain-ascii as a format has _already_ proven its value clearly. the only problem with the format is that it's _ugly_, and that is why i'm concentrating on making it _beautiful_ and even _more_ powerful. *** jswolf said: > The problem (in my opinion) with ZML is that it's non-standard. it will be a standard some day. well, maybe not z.m.l. per se, but _some_ form of light markup. the current leader is "markdown", which is being used all over cyberspace, including in wordpress... it's getting play in all kinds of software. heck, the actual _manual_ for textmate -- a text-editor highly regarded by mac technoids -- is made in markdown. the light-markup revolution is unstoppable, because ordinary people don't want the hassle of doing markup... heck, you can see traces of it in the comment-box in this forum, where a u.r.l. is automatically turned into the appropriate hyperlink. that's the exact type of thing that light-markup does for a person, and there's no earthly reason why we wouldn't want such assistance. furthermore, you will find that markdown has a _lot_ of support. (if you want to do a google search, use "markdown and textile" to avoid false alarms from merchants offering a "markdown" in price. "textile" is another form of light markup.) one of my _favorite_ markdown-related sites is a live authoring site called "showdown": > http://www.attacklab.net/showdown-gui.html i encourage you to try it. see how easy and powerful markdown is. oh yeah, most of the light-markup systems output (x)html, so the argument that light-markup is "nonstandard" is kinda silly. heck, markdown was made, and is maintained by, standardistas. z.m.l. and other light-markup systems know the _structure_ of the document -- they know exactly what each element _is_ -- so they can generate any kind of "standard" output you want... > There are NO converters that will read it and convert it into > something that can then be used to generate a book that will be > readable on a portable book reader. well, _i_ am making converters for z.m.l. i have already done some, and i will do more... so it's totally inaccurate to say there are none. more importantly, the rules are so simple that any programmer can make a converter, really. it doesn't take much coding chops to do it. even a z.m.l. _viewer-program_ is a fairly easy programming task, and converters are an order of magnitude easier than making a viewer-app. (you mean i don't have to _handle_ the footnote, just _mark_it_? cool!) .html from my converter works fine on the web, my current objective. soon i will do whatever tweaks are necessary to make sure it converts well to mobipocket, since amazon will keep that format alive for years. and i'll probably target the rocketbook, for romantic historical reasons. as for other formats, the numbers on plucker indicate i can ignore that. and with the iliad and sony supporting .pdf (which i can convert well), i can see no good reason to make a converter into their other formats. and again, z.m.l. viewer-apps are easy enough to program and port that there'll be one for every important platform before you know it, so i don't see conversions being all that important in the long run... i'm of the opinion that the iphone will become the common denominator we have to consider, and through its web-browser, i already support it... > What is is about ZML that make it that much better then HTML? it's easier for developers to add value around the simple format of z.m.l. than to try and engineer around all of the markup cruft in an .html file... surely you know the gamut of rationale in support of plain-text files, and the usefulness of the tool-chain that can take advantage of them... plus, the z.m.l. viewer-program is built specifically for the task of books (and long documents composed of many "chapters"/sections in general), so they give a superior reading experience over the clunky web-browser. but again, i'm not trying to "sell" you on z.m.l. if you like your .html, fine. go ahead and use it. i'm aiming at authors who don't want to do markup, but still want to offer to their readers a high-powered e-book experience. > And then you go wanting to use ZML which is not a standard at all > that nobody can use to convert to something they can actually read. well, you're simply wrong that "nobody" can use z.m.l. to do conversions. did you visit the web-pages i pointed to up above? > http://z-m-l.com/go/vl3.pl > http://z-m-l.com/go/zmldingus093.pl you can see conversions in action. and here's a .pdf conversion i did as a demo that you can look at: > http://z-m-l.com/oyayr/oya-sunday.pdf 40+ sections and 120+ footnotes in that baby, most with weblinks. i wanted to retain the same linebreaks (mostly) as the .pdf i was duplicating, which meant that i had to make the type too small for you to read it on a sonyreader, but i think you will agree that i've demonstrated that z.m.l. can convert well to the .pdf format. (although i'm wide open to any constructive criticism you have.) i understand and actively support your desire for a range of tools that support a format. i've been working for a long time to create a z.m.l. toolchain that arcs the entire workflow of electronic-books, from the beginning stages of authoring, to web-based publishing, continuing through conversion, and extending through remixing... -bowerbird p.s. sorry for the long message. i guess igorsk is gonna have a whole lotta whitespace in his browser when he encounters this.