jana said:
How about you read the complete mail that you're replying to _before_ replying to every single sentence separately?
i do. premature reply is a rookie mistake. do you really think this is my first rodeo?
I told you exactly how _I_ would want it to look.
how about you _comprehend_ the points that you're replying to before you actually _compose_ the reply? because what i said was that i don't really _care_ what you would want it to _look_ like, since we have the printed book to make _that_ decision... and more to the point, i want to see the _code_, and have it work generally, _not_ have you give me a verbal description... this is all about the _code_. i can give a jolly good verbal description myself...
If you actually look at those printed pages and compare them with what I asked for, you'll see that it was printed in the way I would want it to look.
did _you_ "actually look at those printed pages"? that's why i gave you the links, jana, so you could. because, if you _had_ actually looked at the pages, you should have seen that the third link, for page 192 of the book, has lines indented at two levels, which is most assuredly _not_ what you described.
but even _more_ to the point, show me the code...
Well, since I'm a nice person, I will point you to an example: http://www.gutenberg.org/ebooks/35312
well, since i'm a nice person, i'll go over there and slog through .html/.css source to try to figure out what you might want to do. but just this one time. so don't think this is a trick that will work in general. ok, what i see is a stylesheet that includes this:
.width14 {width:14em;} .width15 {width:15em;} .width18 {width:18em;} .width20 {width:20em;} .width21 {width:21em;}
that's fine if you know that you have lines that long, and that you're _always_ going to have lines that are only that long, but that's not the case, obviously, so this kind of tactic won't work as a general solution... it's also terribly cluttered. and it shows the problem with the "treat each book individually" philosophy that has made the project gutenberg library incapable of being treated _as_a_library_. we're in snowflake mode. moreover, it won't work on a kindle, because .mobi doesn't support .css, so it's worthless in this regard. and it's not obvious how it would support poems where the lines have different indentation, like on:
but the thing is, i don't think it works correctly or "as intended" even in a browser with a big screen. for instance, here is the .html code for one fragment:
there are much worse fragments i could've chosen, but this one will illustrate the point well enough... here is the display in a browser:
that pretty much gives the "center the block but left-align the lines" appearance that jana wanted. but notice that some of the lines are _broken_, because they overflowed the width she specified. considering that we have a _ton_ of room there, there's no reason to be breaking those lines, so i think we have a problem here, right off the bat. but it gets worse... here's how it shows in adobe digital editions:
the lines are not broken here, which is a good thing, even though that makes us suspect that the program probably isn't honoring the width that jana declared. however, the block is certainly not _centered_; nope, there is almost no margin or indentation. so it likely doesn't reflect the original page very well. and here's how it looks in a kindle:
again, not centered, and absolutely no indentation. so it doesn't work in .epub, nor does it work in .mobi. the purpose here is _conversion_, so it doesn't matter how nice the .html acts if the conversions are no good. note that i am not criticizing jana, or her work, here. she built this code for a browser, and that works ok. i am merely pointing out that this conversion job is rife with difficulties in its actual implementation, and the cause of most of the problems lies in the fact that the viewer-programs out there are really crappy apps. add into that the deficiencies of .html, and we have a truly sorry situation. i absolutely believe that there _should_ be a code that effectively says something like "treat this block as a whole, and center it on the screen, but left-align the lines, and preserve relative indentation". but there isn't. so you have to manually put together a kludge that kinda gives you something kinda similar, on some machines, depending on what version of their software they are using. again, it's a very sad situation.
It is not perfect because I'm not willing to use tables just to have poetry centered nicely
it's "not perfect" for several reasons, not just that one.
you _do_ know the approximate width of the poem, which is enough to approximately center it in HTML.
no, it's not "enough to approximately center it", because you don't know the width of the viewport. what does "approximate centering" on one viewport will probably fail miserably on a wildly different one. you can center text, or you can left-align the lines, but you cannot reliably do the mixture which jana has described. i fully agree that a person _should_ be able to do that, but as far as i know, it cannot be accomplished with the tools that we have to work with at the current time. and if i'm wrong on that, show me. _with_code._ code that will work _in_our_conversions_. jana's example works (for the most part) in the browser because she used .css and constrained the viewport to be a certain size. but we cannot do either of those across the full set of reader-machines out there today. this is one of the reasons why d.p. html files are not capable of being used in a programmatic conversion to other formats for the various ebookstores out there.
but it's still way, way better than your underscores.
except when it's not.
As for epub and mobi, I'm fine with just having the poem set off from the left margin there, as it is in the example above.
i see. you just bail when the going gets tough. :+)
Why does it then work pretty well in the example above?
because you constrained the size of the overall viewport and the column size of the poem, to assure the centering. and none of that will work when you go to convert it out. which might be of no concern to you, except for the small matter that _this_is_a_conversion_tool._ remember that?
But _not_ the margin on the left that is just there because the poem is printed centered on the page.
as i said in the post to which you are supposedly replying, many viewer-machines currently ignore margin settings... which is why, if you look at the p.g. .mobi or the p.g. .epub for this file, you will find the poetry is not indented at all... i'm not sure if the p.g. .mobi and the .epub were generated from the .txt version of this file, or the .html, so i also checked the p.g. .epub and the .mobi for "the jungle", since the .html file for that looks to have been generated. and yes, once again, the poetry is not indented at all... and it _should_ be, because it was marked up as "pre", so the leading spaces _should_ be maintained, but they are not. that is why _i_ switched them to underscores. which i am _not_ presenting as some sort of "solution", because they too bring along their own set of problems. but until i have a good solution, i'll keep experimenting. this test with underscores was just one such experiment. i did some screenshots, for the people to lazy to check. here's one of the poems, in the project gutenberg file:
and here's that same poem, in my file:
you can see p.g. lost the indent, and i retained the indent... here's the multi-indentation poem, in the p.g. file:
and here's that same poem in my file:
notice p.g. lost the main indent and the additional indent; my file retained both of them. neither of the files worked well when the lines were broken:
http://76.74.254.239/~bowerbird/pg-page9-broken.png http://76.74.254.239/~bowerbird/me-page9-broken.png
so we are still looking for a good solution to this problem.
but I'm pretty sure no-one would want to copy it as: ______"The vilest deeds, like poison weeds, ___________Bloom well in prison air;
you're way too hung up on the underscores. if i woulda turned them white, you probably wouldn't even have known they were there. but i'm not trying to hide what i am doing. i'm doing experiments. it's an honorable thing.
If you think that poetry with different indents should be copied with leading spaces (which I don't agree with, but that's okay, you don't have to share my opinions),
well, i'm glad you've said that we don't have to share opinions, but i'm curious as to what kind of reasoning you'd give in support of your opinion. why wouldn't someone who was copying out a poem want to retain the various indentations of the lines? it seems to me that to lose that info would be _bad_. poets often use indentation as a tool in our arsenal. it's meaningful. what makes you think you can toss it?
then you can do those indents as non-breaking spaces
before you said that non-breaking spaces were not ok. so i will note the change. they _could_ be a way for us to find some agreement... but i'm not sure the viewer-programs will honor them.
_margin_ and _indentation_ are two quite different concepts.
well, yes and no, but ok. still, you suggested using a margin-change to _provide_ indentation, did you not? so in that particular regard, you made them the same. but discussions that go round and round and round like this one and never come to a satisfactory end are _precisely_ why i now say "show me the code"... show me the code that does what needs to be done, and if it fits the needs of the conversion process too, i will be happy to include it and give you full credit... i don't care if you call it "margin" or "indentation" or "whatchamajamit", as long as it does the job...
I thought that they might be there to represent non-breaking spaces, but then "button~hole" doesn't make any sense to me, so I guess I can't figure out what they're there for after all.
well, you probably could have, given enough time. oh, hey, i just went, and found only a single tilda in the entire file. (the word "they" implies plural.) so it looks like i actually did do a pretty good job of removing all the tildas from that earlier version, since my text-editor informs me there were 1,089. that earlier version, which contained those tildas, retained the linebreaks from the original p-book. you can find that earlier version here:
a tilda indicates a _soft-hyphen_ on a word that at the end of a line that was split and hyphenated. in the case where one is viewing original linebreaks, for _display_, tildas get turned into regular dashes. and in the case where one is _rewrapping_ the text, the word will be rejoined _without_ the soft-hyphen. (since that's what it means to call it "a soft-hyphen".) a regular dash at the end of a line is a _hard-hyphen._ it displays as a dash, and is _retained_ on a rewrap... (there were 131 of these hard hyphens in that file.) note this was an experiment on an "existing" rule. (all of the "rules" of z.m.l. are still in the process of being evaluated as per their effectiveness across a large body of texts, which is why i have not pressed for any widespread adoption yet. that often means there's pressure to maintain "backward compatibility", and i do not wish to be put in that prison quite yet.) the "existing" rule is that every end-line-hyphenate continues to have a hyphen, but _hard-hyphens_ are to be followed by a tilda. so this rule requires that a tilda or hyphen at the end of a line gets removed, but the removal operation is only performed _once_. notice that these different variants of the rule actually _reverse_the_meaning_ of a tilda. in the existing rule, the present of a tilda usually represents a hard-hyphen. but in the variant i was testing in this particular file, the tilda represented a _soft-hyphen_ -- the opposite. either way, both of the variants of this rule do the job. the reason i'm experimenting is to see whether one or the other is better when it comes to _coding_routines_ or _making_it_easier_for_people_creating_e-books_... in the case of the "existing" rule, there was also an issue with the esthetics of the .zml file. the combination of the dash-and-tilda at the end of the hard-hyphen lines was a bit unsightly. it made people say "why is a tilda there?" in the variant i was testing here, those unsightly doubles are gone, and the tilda _kinda_ looks like a regular dash, so people are less likely to see them as being "clutter", especially since there's only one of them at the line-end. i'm still evaluating this, so if you have an opinion on it... at any rate, that's the joy of having the rules be in flux, and a standard nobody uses yet, that i can experiment, so when i want to ramp up demand, i know i'll be ready. but, in a nutshell, the tildas enabled correct rewrapping.
No, I mean centered left-to-right.
again, you seem to be confused by the quick-and-dirty .html conversion that is (still!) being done in this tool... if you want to see the _actual_ conversion that will be performed by this tool once it starts doing conversions, you should look at this file:
i think it looks like crap, what with no margins and that spacey table of contents, but i was designing the thing to the specs which jim gave me, so you can blame jim... (if you wanted to give .html specs, which is the thing you seem to want to do, you shoulda been here then. if you have input, i will listen, but i might or might not implement it. i am not gonna continually revisit that, not until i have real users who are writing real books.) but yes, the dedication (and the title page too) are indeed centered on the screen, just as we'd expect them to be... you can also verify that this is true of the .epub and .mobi.
http://76.74.254.239/~bowerbird/jjngl.epub http://76.74.254.239/~bowerbird/jjngl.mobi
and yes, those two files indicate what the conversions will look like, so if you have any feedback on _them_...
Yeah, so how about you offer us a way to download the converted HTML next
the one-file .html conversion will appear on a webpage, so "downloading" it will be a matter of viewing the page and exerting a "save source code" on it, as per the usual. the .html conversion that has each chapter in its own file -- which is required for the lame adobe viewer-tool -- will have all of those files placed in a folder, along with the other files that are needed to create the .epub file... i'll see if i can zip that folder to make it an easy download.
if you'd rather do that first instead of making the HTML actually look decent?
people can argue for years about what "looks decent". i have no need to get trapped on that merry-go-round.
I have quite a few more suggestions for making your HTML look better, but as you don't seem to be interested in them
i don't seem to be interested because it's a black hole. besides, as shown above, you can have .html which looks _wonderful_, but doesn't convert worth a crap. so until you look at the conversion, it is _impossible_ to gauge the value of the .html which you've created. so a focus on that right now is premature optimization. meanwhile, i have conversion routines to implement... -bowerbird p.s. spellchecker flags "tilda" and the internet tells me that it is "a common misspelling of tilde". damn you all! i'm gonna spell it that way, whether you like it or not! ha!
BB still wants, as stated below, for the printed book to be The Word Of God, Carved In Stone, so to speak, so I must once again remind him that authors-- pretty much worldwide--have bemoaned the way their works appeared in print-- from typeface, to margination, to pagination, to cover art, to editing.... For those who don't believe editors and publishers take great leeway making such decisions, all you need to to is look at books that have editions from the desks of several different editors and publishers. Egad!!! Just from our own collection come our early eBook editions of Paradise Lost, and the various editions of Shakespeare, but there are plent of examples. What makes the run of the paper-mill decisions of one editorial staff from a single publishers so God-like??? I say that one of the greatest advantages of eBooks is hat YOU don't have to go along with such decisions, and why BB insists on being such a follower at the same time he insists that he is really a leader. . .is beyond the pale. The old and Conservative types always think the new should look like the old in every respect possible, from steel supported buildings that are copies of concrete supported buildings that are copies of stone supported buildings... that were, indeed, copies of wooden supported buildings.... Just ask any architect.... We try to make plastic look like metal, even when plastic is obviously best, for that particular design.... Why should we go so far out of our way so some ivory towered caps and gowns, at best, can have it look like something from hundreds of years ago. Modern should be modern. . .period. Don't let bowerbird herd you into those same classical mistakes as those who put The Parthenon on top of the sewage works, as The Medium Is The Massage. "Don't mistake the map for the territory." After all, if BB really meant it, he would work more in Greek, Latin, French and All That Jazzz. . . . Not that _I_ haven't been promoting more Greek, Latin and French eBooks, but no reason the Greek has to be without punctuations, eh? Michael S. Hart Founder Project Gutenberg, Inventor of eBooks Co-Founder The World eBook Fair On Thu, 24 Feb 2011, Bowerbird@aol.com wrote:
jana said:
How about you read the complete mail that you're replying to _before_ replying to every single sentence separately?
i do. premature reply is a rookie mistake. do you really think this is my first rodeo?
I told you exactly how _I_ would want it to look.
how about you _comprehend_ the points that you're replying to before you actually _compose_ the reply?
because what i said was that i don't really _care_ what you would want it to _look_ like, since we have the printed book to make _that_ decision...
and more to the point, i want to see the _code_, and have it work generally, _not_ have you give me a verbal description... this is all about the _code_. i can give a jolly good verbal description myself...
If you actually look at those printed pages and compare them with what I asked for, you'll see that it was printed in the way I would want it to look.
did _you_ "actually look at those printed pages"? that's why i gave you the links, jana, so you could.
because, if you _had_ actually looked at the pages, you should have seen that the third link, for page 192 of the book, has lines indented at two levels, which is most assuredly _not_ what you described.
but even _more_ to the point, show me the code...
Well, since I'm a nice person, I will point you to an example: http://www.gutenberg.org/ebooks/35312
well, since i'm a nice person, i'll go over there and slog through .html/.css source to try to figure out what you might want to do. but just this one time. so don't think this is a trick that will work in general.
ok, what i see is a stylesheet that includes this:
.width14 {width:14em;} .width15 {width:15em;} .width18 {width:18em;} .width20 {width:20em;} .width21 {width:21em;}
that's fine if you know that you have lines that long, and that you're _always_ going to have lines that are only that long, but that's not the case, obviously, so this kind of tactic won't work as a general solution... it's also terribly cluttered. and it shows the problem with the "treat each book individually" philosophy that has made the project gutenberg library incapable of being treated _as_a_library_. we're in snowflake mode.
moreover, it won't work on a kindle, because .mobi doesn't support .css, so it's worthless in this regard.
and it's not obvious how it would support poems where the lines have different indentation, like on:
but the thing is, i don't think it works correctly or "as intended" even in a browser with a big screen.
for instance, here is the .html code for one fragment:
there are much worse fragments i could've chosen, but this one will illustrate the point well enough...
here is the display in a browser:
that pretty much gives the "center the block but left-align the lines" appearance that jana wanted.
but notice that some of the lines are _broken_, because they overflowed the width she specified.
considering that we have a _ton_ of room there, there's no reason to be breaking those lines, so i think we have a problem here, right off the bat.
but it gets worse...
here's how it shows in adobe digital editions:
the lines are not broken here, which is a good thing, even though that makes us suspect that the program probably isn't honoring the width that jana declared.
however, the block is certainly not _centered_; nope, there is almost no margin or indentation.
so it likely doesn't reflect the original page very well.
and here's how it looks in a kindle:
again, not centered, and absolutely no indentation.
so it doesn't work in .epub, nor does it work in .mobi.
the purpose here is _conversion_, so it doesn't matter how nice the .html acts if the conversions are no good.
note that i am not criticizing jana, or her work, here. she built this code for a browser, and that works ok.
i am merely pointing out that this conversion job is rife with difficulties in its actual implementation, and the cause of most of the problems lies in the fact that the viewer-programs out there are really crappy apps.
add into that the deficiencies of .html, and we have a truly sorry situation. i absolutely believe that there _should_ be a code that effectively says something like "treat this block as a whole, and center it on the screen, but left-align the lines, and preserve relative indentation".
but there isn't. so you have to manually put together a kludge that kinda gives you something kinda similar, on some machines, depending on what version of their software they are using. again, it's a very sad situation.
It is not perfect because I'm not willing to use tables just to have poetry centered nicely
it's "not perfect" for several reasons, not just that one.
you _do_ know the approximate width of the poem, which is enough to approximately center it in HTML.
no, it's not "enough to approximately center it", because you don't know the width of the viewport. what does "approximate centering" on one viewport will probably fail miserably on a wildly different one.
you can center text, or you can left-align the lines, but you cannot reliably do the mixture which jana has described. i fully agree that a person _should_ be able to do that, but as far as i know, it cannot be accomplished with the tools that we have to work with at the current time. and if i'm wrong on that, show me. _with_code._ code that will work _in_our_conversions_.
jana's example works (for the most part) in the browser because she used .css and constrained the viewport to be a certain size. but we cannot do either of those across the full set of reader-machines out there today.
this is one of the reasons why d.p. html files are not capable of being used in a programmatic conversion to other formats for the various ebookstores out there.
but it's still way, way better than your underscores.
except when it's not.
As for epub and mobi, I'm fine with just having the poem set off from the left margin there, as it is in the example above.
i see. you just bail when the going gets tough. :+)
Why does it then work pretty well in the example above?
because you constrained the size of the overall viewport and the column size of the poem, to assure the centering.
and none of that will work when you go to convert it out. which might be of no concern to you, except for the small matter that _this_is_a_conversion_tool._ remember that?
But _not_ the margin on the left that is just there because the poem is printed centered on the page.
as i said in the post to which you are supposedly replying, many viewer-machines currently ignore margin settings...
which is why, if you look at the p.g. .mobi or the p.g. .epub for this file, you will find the poetry is not indented at all...
i'm not sure if the p.g. .mobi and the .epub were generated from the .txt version of this file, or the .html, so i also checked the p.g. .epub and the .mobi for "the jungle", since the .html file for that looks to have been generated.
and yes, once again, the poetry is not indented at all...
and it _should_ be, because it was marked up as "pre", so the leading spaces _should_ be maintained, but they are not. that is why _i_ switched them to underscores. which i am _not_ presenting as some sort of "solution", because they too bring along their own set of problems. but until i have a good solution, i'll keep experimenting. this test with underscores was just one such experiment.
i did some screenshots, for the people to lazy to check.
here's one of the poems, in the project gutenberg file:
and here's that same poem, in my file:
you can see p.g. lost the indent, and i retained the indent...
here's the multi-indentation poem, in the p.g. file:
and here's that same poem in my file:
notice p.g. lost the main indent and the additional indent; my file retained both of them.
neither of the files worked well when the lines were broken:
http://76.74.254.239/~bowerbird/pg-page9-broken.png http://76.74.254.239/~bowerbird/me-page9-broken.png
so we are still looking for a good solution to this problem.
but I'm pretty sure no-one would want to copy it as: ______"The vilest deeds, like poison weeds, ___________Bloom well in prison air;
you're way too hung up on the underscores. if i woulda turned them white, you probably wouldn't even have known they were there. but i'm not trying to hide what i am doing. i'm doing experiments. it's an honorable thing.
If you think that poetry with different indents should be copied with leading spaces (which I don't agree with, but that's okay, you don't have to share my opinions),
well, i'm glad you've said that we don't have to share opinions, but i'm curious as to what kind of reasoning you'd give in support of your opinion.
why wouldn't someone who was copying out a poem want to retain the various indentations of the lines? it seems to me that to lose that info would be _bad_.
poets often use indentation as a tool in our arsenal. it's meaningful. what makes you think you can toss it?
then you can do those indents as non-breaking spaces
before you said that non-breaking spaces were not ok. so i will note the change.
they _could_ be a way for us to find some agreement...
but i'm not sure the viewer-programs will honor them.
_margin_ and _indentation_ are two quite different concepts.
well, yes and no, but ok.
still, you suggested using a margin-change to _provide_ indentation, did you not? so in that particular regard, you made them the same.
but discussions that go round and round and round like this one and never come to a satisfactory end are _precisely_ why i now say "show me the code"...
show me the code that does what needs to be done, and if it fits the needs of the conversion process too, i will be happy to include it and give you full credit...
i don't care if you call it "margin" or "indentation" or "whatchamajamit", as long as it does the job...
I thought that they might be there to represent non-breaking spaces, but then "button~hole" doesn't make any sense to me, so I guess I can't figure out what they're there for after all.
well, you probably could have, given enough time.
oh, hey, i just went, and found only a single tilda in the entire file. (the word "they" implies plural.)
so it looks like i actually did do a pretty good job of removing all the tildas from that earlier version, since my text-editor informs me there were 1,089.
that earlier version, which contained those tildas, retained the linebreaks from the original p-book.
you can find that earlier version here:
a tilda indicates a _soft-hyphen_ on a word that at the end of a line that was split and hyphenated.
in the case where one is viewing original linebreaks, for _display_, tildas get turned into regular dashes.
and in the case where one is _rewrapping_ the text, the word will be rejoined _without_ the soft-hyphen. (since that's what it means to call it "a soft-hyphen".)
a regular dash at the end of a line is a _hard-hyphen._ it displays as a dash, and is _retained_ on a rewrap... (there were 131 of these hard hyphens in that file.)
note this was an experiment on an "existing" rule. (all of the "rules" of z.m.l. are still in the process of being evaluated as per their effectiveness across a large body of texts, which is why i have not pressed for any widespread adoption yet. that often means there's pressure to maintain "backward compatibility", and i do not wish to be put in that prison quite yet.)
the "existing" rule is that every end-line-hyphenate continues to have a hyphen, but _hard-hyphens_ are to be followed by a tilda. so this rule requires that a tilda or hyphen at the end of a line gets removed, but the removal operation is only performed _once_.
notice that these different variants of the rule actually _reverse_the_meaning_ of a tilda. in the existing rule, the present of a tilda usually represents a hard-hyphen. but in the variant i was testing in this particular file, the tilda represented a _soft-hyphen_ -- the opposite.
either way, both of the variants of this rule do the job. the reason i'm experimenting is to see whether one or the other is better when it comes to _coding_routines_ or _making_it_easier_for_people_creating_e-books_...
in the case of the "existing" rule, there was also an issue with the esthetics of the .zml file. the combination of the dash-and-tilda at the end of the hard-hyphen lines was a bit unsightly. it made people say "why is a tilda there?"
in the variant i was testing here, those unsightly doubles are gone, and the tilda _kinda_ looks like a regular dash, so people are less likely to see them as being "clutter", especially since there's only one of them at the line-end.
i'm still evaluating this, so if you have an opinion on it...
at any rate, that's the joy of having the rules be in flux, and a standard nobody uses yet, that i can experiment, so when i want to ramp up demand, i know i'll be ready.
but, in a nutshell, the tildas enabled correct rewrapping.
No, I mean centered left-to-right.
again, you seem to be confused by the quick-and-dirty .html conversion that is (still!) being done in this tool...
if you want to see the _actual_ conversion that will be performed by this tool once it starts doing conversions, you should look at this file:
i think it looks like crap, what with no margins and that spacey table of contents, but i was designing the thing to the specs which jim gave me, so you can blame jim...
(if you wanted to give .html specs, which is the thing you seem to want to do, you shoulda been here then. if you have input, i will listen, but i might or might not implement it. i am not gonna continually revisit that, not until i have real users who are writing real books.)
but yes, the dedication (and the title page too) are indeed centered on the screen, just as we'd expect them to be...
you can also verify that this is true of the .epub and .mobi.
http://76.74.254.239/~bowerbird/jjngl.epub http://76.74.254.239/~bowerbird/jjngl.mobi
and yes, those two files indicate what the conversions will look like, so if you have any feedback on _them_...
Yeah, so how about you offer us a way to download the converted HTML next
the one-file .html conversion will appear on a webpage, so "downloading" it will be a matter of viewing the page and exerting a "save source code" on it, as per the usual.
the .html conversion that has each chapter in its own file -- which is required for the lame adobe viewer-tool -- will have all of those files placed in a folder, along with the other files that are needed to create the .epub file... i'll see if i can zip that folder to make it an easy download.
if you'd rather do that first instead of making the HTML actually look decent?
people can argue for years about what "looks decent". i have no need to get trapped on that merry-go-round.
I have quite a few more suggestions for making your HTML look better, but as you don't seem to be interested in them
i don't seem to be interested because it's a black hole.
besides, as shown above, you can have .html which looks _wonderful_, but doesn't convert worth a crap.
so until you look at the conversion, it is _impossible_ to gauge the value of the .html which you've created.
so a focus on that right now is premature optimization.
meanwhile, i have conversion routines to implement...
-bowerbird
p.s. spellchecker flags "tilda" and the internet tells me that it is "a common misspelling of tilde". damn you all! i'm gonna spell it that way, whether you like it or not! ha!
participants (2)
-
Bowerbird＠aol.com -
Michael S. Hart