What "Cleaning Up" Do Project Gutenberg Texts Need [closed] - Page 3

jbenny · 11-03-2007, 04:01 PM

Quote:

Originally Posted by bowerbird

you know, i _really_ dislike it when people try to put words in my mouth
-bowerbird

Talk about the pot calling the kettle black. The disdain I felt was your reaction to my suggestion, not to the tools mentioned. I'm sure you want to have the last word, so go ahead. I won't be replying.

Nate the great · 11-03-2007, 04:47 PM

@jbenny

Thanks for the assistance. I am currently making a list of all the tags I am planning to use; I removed the icky ones.

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.

jbenny · 11-03-2007, 05:06 PM

Quote:

Originally Posted by Nate the great

@jbenny

Thanks for the assistance. I am currently making a list of all the tags I am planning to use; I removed the icky ones.

Yep, we need to banish all those "icky" tags

BTW, the "quirks mode" problem with IE may or may not apply to IE7. I don't use IE7 so I can't test this. Does anyone else know for sure?

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

jbenny said:
> The disdain I felt was your reaction to my suggestion

well, you imagined that. i had no "disdain" for your suggestion.
it simply indicated you had no grasp of the scope of my intent,
which is much wider than the scope of the tools you mentioned.

and when you followed up the word "disdain" with the ridiculously
untrue charge of "vaporware", you brought about your own trouble.

my tools are in-progress and proof-of-concept, so there are _many_
criticisms that can be leveled against them. but "vaporware"? nope.

-bowerbird

DaleDe · 11-03-2007, 05:22 PM

Quote:

Originally Posted by jbenny

Yep, we need to banish all those "icky" tags

BTW, the "quirks mode" problem with IE may or may not apply to IE7. I don't use IE7 so I can't test this. Does anyone else know for sure?

IE7 handles this fine. By the way IE7 is my favorite RSS reader for a PC. It can handle XML RSS files fine as well. I am not an IE fan by the way. I use SeaMonkey for a browser.

Dale

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

kovidgoyal said:
> Since I have a little experience writing converters, I'd just like to say that
> if somebody does write a new improved gutenberg to html converter
> to use a well defined semantic scheme by CSS classes.

um, to repeat, there's a good reason why no one will write an "improved"
gutenberg-to-html converter. it's the same reason that made ron burkey
give up on gutenmark, namely, the inconsistencies riddling p.g. e-texts.

until those inconsistencies are cleaned up, a converter is a pipe-dream...

however, once those inconsistencies _are_ cleaned up, we no longer need
to _convert_ the e-texts to _any_ other format, because their consistency
will mean that viewer-programs can be made to handle their native format.

this presents the existential conundrum of heavy-markup.
until it can be applied _automatically_, its cost is too high.
but once it _can_ be applied automatically, it's unnecessary,
because the very same routines that convert text to xhtml so
that xhtml can be rendered by a display-program can instead
be put into a viewer-app that eliminates the xhtml middleman,
by working directly with the text as its input to create its output.

once you understand this, deeply, markup becomes a bad joke.

we take simple text and turn it into complicated markup, and then
we need a complicated program to handle the complicated markup
and turn it back into simple text that can be displayed. it's just silly.

once i show people markup is unnecessary, they'll laugh at you for doing it.
and i don't say that to _mock_ you; i say it so you can avoid looking stupid...

-bowerbird

JSWolf · 11-03-2007, 05:30 PM

But can ZML be read on any currently available portable reading device?

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

jswolf said:
> But can ZML be read on any currently available portable reading device?

no. you will need to click one button to turn it into .html,
or click another button to turn it into a .pdf, after which
you'll have an html-book or a pdf-book that's customized
to your preferences on a number of different dimensions,
including ones like page-size, margin-size, and font-size.

in the future, if those "portable reading devices" can be
_programmed_, then someone will create a zml-viewer
for them, because otherwise p.g. e-texts are too ugly...

it might even be the case that big companies like adobe
end up handling z.m.l., because they'll become the butt of
jokes if they "fail" to support such a simple, useful format
that has gained widespread use from the general populace.

-bowerbird

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

in other words, i'm betting on simplicity against complexity...

because i can give my simplicity _vastly_greater_functionality_
while other developers are busy tripping over their complexity...

and i think that's the winning argument here.

but that's not what's important, because "winning arguments"
in forum "discussions" don't carry any weight in the real world.

what matters in the real world is the functionality you give users.

the proof is in the pudding, my friends. the proof is in the pudding.

-bowerbird

JSWolf · 11-03-2007, 06:52 PM

Bowerbird can you show us some samples so we'll know exactly what you are on about? I think that would help your case most of all.

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

jswolf said:
> can you show us some samples

ok, for the _third_ time now, go here:
> http://z-m-l.com/go/vl3.pl

first click the blue underlined link to view the .zml file.
then go back and click the button to convert to .html.

notice that among these documents is one containing
"the 11 rules of z.m.l.". another one is a "test-suite"
that lists structures that are commonly found in books.

***

if you want to try some z.m.l. out yourself, go to this page:
> http://z-m-l.com/go/zmldingus093.pl
you can click any of the buttons to convert a document.
(these documents are the same ones on the page above.)

you can also click "skeleton" to bring in the _skeleton_ of
a document for you to edit. make some changes to convince
yourself it is a live demo, and then click "do it" to convert it.

again, this is all "proof of concept" and "in-progress" and
whatever other label you need to realize it's not done yet.

i'm working on a toolchain that stretches across the workflow,
and it's just starting to cohere as a whole, so i am not focused
on any one particular part now, so some things might not work.

and, again, i'm not trying to "convince" anyone of anything, so
there's no sense "resisting". it doesn't matter if you ain't buyin',
because i ain't sellin'... :+)

nonetheless, constructive criticism will be welcomed.

and as you can tell, i have thick skin, so don't worry about
being "polite". i can handle it.

-bowerbird

tompe · 11-03-2007, 07:27 PM

Number of emty lines and space as significant markup seems like a bad idea. Also I do not see how to markup quotes inside quotes, e.g: "Allan's word 'green' is blue".

But I think I get your idea. And I can sympatize with en easy editable format to get people to use it.

bowerbird · 11-03-2007, 08:07 PM

tompe said:
> Number of empty lines and space as significant markup seems like a bad idea.

as for the number of empty lines, the zml-authoring-tool does the counting for you,
displaying headers appropriately, so in practice, it actually works out pretty well...

the same with elements that depend upon spaces. plus, as one person pointed out,
python's dependence upon spaces hasn't seemed to have many deleterious effects...
i also have the benefit of the experience other light-markup systems have gained...
markdown depends even more on spaces than z.m.l., and nobody complains about it.

> Also I do not see how to markup quotes inside quotes,
> e.g: "Allan's word 'green' is blue".

i'm not sure i understand you. you'd do it just like you did it in your example...

-bowerbird

tompe · 11-03-2007, 08:26 PM

I didn't realize an authoring tool was required. I like to be able to write things in a text editor and I thought the goal was to make this possible. If you are going to use an authoring tool I do not see the reason for this kind of markup.

You said in the specification that quotes could be replaced to whatever the user wanted and for this you have to be able to distinguish between a quote and constructions like 'em. And it seems impossible to do this with your rules. And you have examples like: "The coordinate was 49° 12' 27" N"

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
The "Closed Circle" is open for business	pholy	Deals and Resources (No Self-Promotion or Affiliate Links)	0	12-20-2009 09:24 PM
"SuperBook" project - British School studies e-books usage	TadW	News	2	06-28-2007 10:46 PM
Introducing the book: Gutenberg offers "in-home" tech support (humor)	nekokami	Lounge	1	05-07-2007 08:40 PM
"Gutenberg 2.0: le futur du livre" / iRex demoes Mobipocket on iLiad	Hadrien	News	4	03-27-2007 11:45 AM

11-03-2007, 04:47 PM	#32
Nate the great Sir Penguin of Edinburgh Posts: 12,375 Karma: 23555235 Join Date: Apr 2007 Location: DC Metro area Device: Shake a stick plus 1	@jbenny Thanks for the assistance. I am currently making a list of all the tags I am planning to use; I removed the icky ones.

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.

11-03-2007, 05:13 PM	#35
bowerbird Banned Posts: 269 Karma: -273 Join Date: Sep 2006 Location: los angeles	jbenny said: > The disdain I felt was your reaction to my suggestion well, you imagined that. i had no "disdain" for your suggestion. it simply indicated you had no grasp of the scope of my intent, which is much wider than the scope of the tools you mentioned. and when you followed up the word "disdain" with the ridiculously untrue charge of "vaporware", you brought about your own trouble. my tools are in-progress and proof-of-concept, so there are _many_ criticisms that can be leveled against them. but "vaporware"? nope. -bowerbird

11-03-2007, 05:29 PM	#37
bowerbird Banned Posts: 269 Karma: -273 Join Date: Sep 2006 Location: los angeles	kovidgoyal said: > Since I have a little experience writing converters, I'd just like to say that > if somebody does write a new improved gutenberg to html converter > to use a well defined semantic scheme by CSS classes. um, to repeat, there's a good reason why no one will write an "improved" gutenberg-to-html converter. it's the same reason that made ron burkey give up on gutenmark, namely, the inconsistencies riddling p.g. e-texts. until those inconsistencies are cleaned up, a converter is a pipe-dream... however, once those inconsistencies _are_ cleaned up, we no longer need to _convert_ the e-texts to _any_ other format, because their consistency will mean that viewer-programs can be made to handle their native format. this presents the existential conundrum of heavy-markup. until it can be applied _automatically_, its cost is too high. but once it _can_ be applied automatically, it's unnecessary, because the very same routines that convert text to xhtml so that xhtml can be rendered by a display-program can instead be put into a viewer-app that eliminates the xhtml middleman, by working directly with the text as its input to create its output. once you understand this, deeply, markup becomes a bad joke. we take simple text and turn it into complicated markup, and then we need a complicated program to handle the complicated markup and turn it back into simple text that can be displayed. it's just silly. once i show people markup is unnecessary, they'll laugh at you for doing it. and i don't say that to _mock_ you; i say it so you can avoid looking stupid... -bowerbird

11-03-2007, 05:30 PM	#38
JSWolf Resident Curmudgeon Posts: 74,526 Karma: 129670952 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	But can ZML be read on any currently available portable reading device?

11-03-2007, 05:39 PM	#39
bowerbird Banned Posts: 269 Karma: -273 Join Date: Sep 2006 Location: los angeles	jswolf said: > But can ZML be read on any currently available portable reading device? no. you will need to click one button to turn it into .html, or click another button to turn it into a .pdf, after which you'll have an html-book or a pdf-book that's customized to your preferences on a number of different dimensions, including ones like page-size, margin-size, and font-size. in the future, if those "portable reading devices" can be _programmed_, then someone will create a zml-viewer for them, because otherwise p.g. e-texts are too ugly... it might even be the case that big companies like adobe end up handling z.m.l., because they'll become the butt of jokes if they "fail" to support such a simple, useful format that has gained widespread use from the general populace. -bowerbird

11-03-2007, 05:44 PM	#40
bowerbird Banned Posts: 269 Karma: -273 Join Date: Sep 2006 Location: los angeles	in other words, i'm betting on simplicity against complexity... because i can give my simplicity _vastly_greater_functionality_ while other developers are busy tripping over their complexity... and i think that's the winning argument here. but that's not what's important, because "winning arguments" in forum "discussions" don't carry any weight in the real world. what matters in the real world is the functionality you give users. the proof is in the pudding, my friends. the proof is in the pudding. -bowerbird

11-03-2007, 06:52 PM	#41
JSWolf Resident Curmudgeon Posts: 74,526 Karma: 129670952 Join Date: Nov 2006 Location: Roslindale, Massachusetts Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3	Bowerbird can you show us some samples so we'll know exactly what you are on about? I think that would help your case most of all.

11-03-2007, 07:07 PM	#42
bowerbird Banned Posts: 269 Karma: -273 Join Date: Sep 2006 Location: los angeles	jswolf said: > can you show us some samples ok, for the _third_ time now, go here: > http://z-m-l.com/go/vl3.pl first click the blue underlined link to view the .zml file. then go back and click the button to convert to .html. notice that among these documents is one containing "the 11 rules of z.m.l.". another one is a "test-suite" that lists structures that are commonly found in books. *** if you want to try some z.m.l. out yourself, go to this page: > http://z-m-l.com/go/zmldingus093.pl you can click any of the buttons to convert a document. (these documents are the same ones on the page above.) you can also click "skeleton" to bring in the _skeleton_ of a document for you to edit. make some changes to convince yourself it is a live demo, and then click "do it" to convert it. again, this is all "proof of concept" and "in-progress" and whatever other label you need to realize it's not done yet. i'm working on a toolchain that stretches across the workflow, and it's just starting to cohere as a whole, so i am not focused on any one particular part now, so some things might not work. and, again, i'm not trying to "convince" anyone of anything, so there's no sense "resisting". it doesn't matter if you ain't buyin', because i ain't sellin'... :+) nonetheless, constructive criticism will be welcomed. and as you can tell, i have thick skin, so don't worry about being "polite". i can handle it. -bowerbird

11-03-2007, 07:27 PM	#43
tompe Grand Sorcerer Posts: 7,452 Karma: 7185064 Join Date: Oct 2007 Location: Linköpng, Sweden Device: Kindle Voyage, Nexus 5, Kindle PW	Number of emty lines and space as significant markup seems like a bad idea. Also I do not see how to markup quotes inside quotes, e.g: "Allan's word 'green' is blue". But I think I get your idea. And I can sympatize with en easy editable format to get people to use it.

Advert

Advert

11-03-2007, 08:07 PM	#44
bowerbird Banned Posts: 269 Karma: -273 Join Date: Sep 2006 Location: los angeles	tompe said: > Number of empty lines and space as significant markup seems like a bad idea. as for the number of empty lines, the zml-authoring-tool does the counting for you, displaying headers appropriately, so in practice, it actually works out pretty well... the same with elements that depend upon spaces. plus, as one person pointed out, python's dependence upon spaces hasn't seemed to have many deleterious effects... i also have the benefit of the experience other light-markup systems have gained... markdown depends even more on spaces than z.m.l., and nobody complains about it. > Also I do not see how to markup quotes inside quotes, > e.g: "Allan's word 'green' is blue". i'm not sure i understand you. you'd do it just like you did it in your example... -bowerbird

11-03-2007, 08:26 PM	#45
tompe Grand Sorcerer Posts: 7,452 Karma: 7185064 Join Date: Oct 2007 Location: Linköpng, Sweden Device: Kindle Voyage, Nexus 5, Kindle PW	I didn't realize an authoring tool was required. I like to be able to write things in a text editor and I thought the goal was to make this possible. If you are going to use an authoring tool I do not see the reason for this kind of markup. You said in the specification that quotes could be replaced to whatever the user wanted and for this you have to be able to distinguish between a quote and constructions like 'em. And it seems impossible to do this with your rules. And you have examples like: "The coordinate was 49° 12' 27" N"