February 2011 - gutvol-d - lists.pglaf.org

Re: time after time
by Bowerbird＠aol.com 25 Feb '11

25 Feb '11

hey jana, you wanted the "search" facility to scroll to the search-term when finding a hit in a chapter and opening that file for display. how about if i gave you a link that would do that? it would be a target=_blank window that would open outside the web-app, so as not to interfere with the web-app, but it would give us what you are asking for, as far as i can tell. should i do it? -bowerbird

1 0

Re: time after time
by Bowerbird＠aol.com 25 Feb '11

25 Feb '11

jana said: > Not for me, it doesn't. maybe you didn't know what to look for... by default, it creates this file: > http://76.74.254.239/~bowerbird/abcde.pdf as i said, though, that's just an empty .pdf... (it has 2 blank pages, and a single bookmark.) if you want to prove it to yourself, you can type in a 5-lowercase-letter string in the box at the upper-left, and the program will save the .pdf under _that_ name. so, for instance, if you type "janas" in the name-field, and then hit the "pdf" button, it will create this file, which you can verify: > http://76.74.254.239/~bowerbird/janas.pdf again, that'll be an empty .pdf, so it's no big deal, except that it establishes that i can create a .pdf and save it, which serves as the foundation for me. (you can't put something _in_ a file until you can save a file; might not seem impressive, but it is.) *** anywhere, here's what we're shooting for: > http://76.74.254.239/~bowerbird/abc.pdf that was generated offline, so now i just need to work out the quirks of moving the code online... so if you have any suggestions about that .pdf, it would behoove you to submit them right now. *** the next step, after i had the foundation, was to demonstrate that i can fill it with arbitrary text. to witness that, go here: > http://76.74.254.239/~bowerbird/ab.fcgi click the "untitled" button at the top, and you'll generate a .pdf with the content from that field: > http://76.74.254.239/~bowerbird/textformattingUnicode.pdf there's a lot of text in that field -- over 800k -- so creating the .pdf takes a while, give it a chance. it doesn't create a very nice .pdf, but it does work. you can edit the content in that field if you like, just to prove to yourself that it is indeed live... again, i expect this .pdf converter will be finished within 2 or 3 days, so if you have any suggestions... -bowerbird

2 1

Re: time after time
by Bowerbird＠aol.com 25 Feb '11

25 Feb '11

"everybody talks about the weather..." thursday's file is up: > http://76.74.254.239/~bowerbird/a.fcgi hooray! finally getting around to doing a conversion! it's .pdf, and all we've done thus far is generate the file, create some pages, and plug in a sample bookmark, but at least we're starting to do what a converter should do... -bowerbird

2 1

Re: time after time
by Bowerbird＠aol.com 24 Feb '11

24 Feb '11

jana said: > (So, _are_ we going to create > "something valuable" now, > or aren't we?...) i am. you can help if you want. > How about you fix up the poetry next? were you reading the list when i talked to jim? because the same thing applies to this advice. in order to know how to "fix up the poetry", i will need to know how you think it should be, as i'm not too good at the mind-reading stuff... take the .html file that contains some poetry, and rework the coding so it does what you want. then i'll know, unequivocally, what you want, so we won't have to cycle through a sequence of guesses. > Those prepended underscores really suck. yeah, they do. but they cause correct indentation. so until we figure out some other way to do that, we'll be stuck with them. i could turn them white, but you know, there must be a better way to do it. > If I could choose how it were to look, yeah, well, no, you can't really "choose" that. those stanzas were _printed_ in a certain way, so we now have to assume that's how sinclair wanted them to appear (although, realistically, it was probably entirely the printer's decision, but we have to take the only evidence we have), so we're kind of stuck with reproducing that... > http://z-m-l.com/go/tjbus/tjbusp009.html > http://z-m-l.com/go/tjbus/tjbusp090.html > http://z-m-l.com/go/tjbus/tjbusp192.html i'm not a stickler for cloning the printed book, mind you, especially if there are good reasons for making a change, so if you can come up with some good reasons, i would be willing to listen. otherwise, though, let's try to reproduce the look. > I would want it centered on the "page" > (screen, whatever), but with left-aligned lines. ok, if you can find a way to work out that miracle, do please let me know. and the rest of the world. because that would require the viewer-program to have some knowledge that most of them don't seem to have, even though i believe they _should_. that is, the viewer-app doesn't know the page-size. it could be running on an iphone, on a kindle-dx, or on the 6-foot t.v. you have in your living-room. i think a viewer-app _should_ know that basic fact. but, you know, we have to work with what we have. > If you don't know how to do that, it's not that _i_ "don't know how to do that"... it's that _nobody_ knows "how to do that"... as there are good reasons it cannot be done. > then just indent it a bit from the left. > Using a margin or something, > not underscores or non-breaking spaces. what's wrong with non-breaking spaces? or white underscores? i mean, seriously. understand that i'm willing to do things however you suggest, providing i believe it to be a reasonable take on how to do it, and i'm eager to see what you come up with. but one thing you might want to consider is the case where a person copies text out of the browser-window. in most browsers, the indentation gets lost completely, which means that our nicely-and-correctly-indented poetry loses that nice and correct indentation. (so do block-quotes, just so you know that too.) so margins present their own sets of problems. (plus many viewer-programs mess with margins. i know, i know, they _shouldn't_. but they do.) anyway, you know, like i said, i will listen to you... > Because I don't wanna copy underscores > or spaces when I copy and paste the poem. except that they _do_ maintain the indentation... and people who care about poetry care about that. so, you know, i hope you can make them happy too. > What does a tilde in the original mean? see if you can figure it out! > And whatever they mean, > why are they kept in the converted version? because i forgot they were in there, so i forgot that i had to remove them. they're harmless. pretend they're gone. > I'd also really like to have the dedication > centered on the page, as it would be in a real book. i assume you mean centered top-to-bottom? i will make fine-tuning adjustments like that at a later time, but i think they are too petty now... we have much bigger fish which need to be fried first. we're building a converter-program. remember? -bowerbird

4 3

Re: time after time
by Bowerbird＠aol.com 24 Feb '11

24 Feb '11

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. > http://z-m-l.com/go/tjbus/tjbusp192.html 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: > http://z-m-l.com/go/tjbus/tjbusp192.html 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: > http://76.74.254.239/~bowerbird/js-poetry-code.png 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: > http://76.74.254.239/~bowerbird/js-poetry-browser.png 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: > http://76.74.254.239/~bowerbird/js-poetry-epub.png 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: > http://76.74.254.239/~bowerbird/js-poetry-mobi.png 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: > http://76.74.254.239/~bowerbird/pg-page9-lostindent.png and here's that same poem, in my file: > http://76.74.254.239/~bowerbird/me-page9-indented.png you can see p.g. lost the indent, and i retained the indent... here's the multi-indentation poem, in the p.g. file: > http://76.74.254.239/~bowerbird/pg-page192-lostindent.png and here's that same poem in my file: > http://76.74.254.239/~bowerbird/me-page192-indented.png 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: > http://z-m-l.com/go/tjbus/tjbus.zml 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: > http://z-m-l.com/go/jjngl/jjngl.html 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!

2 1

Re: time after time
by Bowerbird＠aol.com 23 Feb '11

23 Feb '11

wow. like i said, the world at large is catching up... here's a site that just opened its doors to the public _today_: > http://www.pandamian.com/ it allows you to write a book, and then it creates a .pdf of it, a .mobi, and an .epub. sound familiar? here's a book i started: > http://bowerbird.pandamian.com/ the marcello process, and the whole d.p. workflow, is looking more and more _antiquated_ every day... and if you would have listened to me back in 2003, p.g. could have been years ahead of everyone else... as it is, you're bringing up the rear. sorry about that! -bowerbird

1 0

Re: Why Bowerbird Has Zero Credibility as of Right Now
by Bowerbird＠aol.com 23 Feb '11

23 Feb '11

michael said: > Not correct. > We were using most of these techniques before zml. . . . michael's right. i devised zen markup language -- (the "z" can stand for whatever you want it to be!) -- mainly using the existing rules for pg-etext... but some of the rules were taken from protocols that were spontaneously created by people using e-mail, and listserves, and forums, even -- heck, what were they called?, things like alt.comics.com? and wikipedia too. i think i got the idea of using brackets around a footnote number from there... also, as i looked at more and more o.c.r. from scans, i came to develop some additional rules from that... whatever makes sense, or is an existing convention that is recognized in the population, i will use that. lee has been so confused by z.m.l. -- and so willing to spread his confusion to others -- that i never even bother to read his posts any more. i have him kill-filed. and just so you know, an indented block is indicated by the ">" indicator which is very common in e-mails. i use it myself, and always follow it with three spaces. and many e-mail programs use it as their "default"... who knows?, maybe even lee's e-mail program uses it. > Spousal Markup Language: > there are rules, but you have to figure them out > for yourself, and they are subject to change. that's a funny one! :+) well, the rules _are_ still subject to change, guilty... the latest change is that a line which has a space in column 1 and _not_ column 2 is _centered_... and it's one of the best rules that i every made! but for the most part, they aren't hard to figure out. the notion is that, whatever people do _naturally_, that's what we adopt as "a rule". the big idea behind it all is that the _computer_ should just _figure_out_ what you want it to do. so, for instance, when people start a new chapter, they usually put in a bunch of blank lines first... so the computer should "just know" that if you have put in a bunch of blank lines, followed by something that looks like it is a chapter header -- because, as a for instance, it contains the word "chapter" in it, which could be a dead giveaway -- then it should know that it is indeed a new chapter, and it should thus format the header appropriately, and the table of contents should link to this place, and the chapter header should link back to the toc, and so on and so forth, yadda yadda, you get it... the heavy-markup people, on the other hand, want _you_ to have to _mark_ everything yourself. they want you to laboriously label each chapter header _as_ a chapter header, and they want you to have to specify each of the links yourself too. they expect the computer to be an idiot that can only figure out what to do if you tell it explicitly. heavy-markup people think computers are stupid. they would have _never_ built watson. -bowerbird

1 0

Re: time after time
by Bowerbird＠aol.com 23 Feb '11

23 Feb '11

so let's do some real work, ok? in order to do a good job on a converter routine, you have to know what object you're shooting for. luckily for us in the present case, we just went through the process of deciding how we want our .epub and .mobi output files to look, thanks to jim's many "contributions". i did some slight updating, to reflect jana's suggestions, and have uploaded those two files to the website for you. first, here's a copy of the .html (in a combined file): > http://76.74.254.239/~bowerbird/jjngl-combined.html next, here's a copy of the .epub file: > http://76.74.254.239/~bowerbird/jjngl.epub and here's a copy of the .mobi file: > http://76.74.254.239/~bowerbird/jjngl.mobi these files represent the outcome that we want from our conversion process, so we will _know_ when we have attained success in that regard... the .mobi was generated by dropping the .epub on the kindle previewer. that's a very handy tool that saves us the hassle of generating a separate .mobi. in addition, if the .epub file is bad, it gives us some error messages that help trace down the problems, a nicety the .epub gang was slow to offer themselves. at any rate, if anyone has any feedback on those files, do please let me know. (although you _should_ have given that feedback when we did the process earlier.) if there are no suggestions, then we can proceed... -bowerbird p.s. don't delay. i will be totally unresponsive if you come in at some later time and want to change it all...

1 0

Re: time after time
by Bowerbird＠aol.com 23 Feb '11

23 Feb '11

wednesday's version is up: > http://76.74.254.239/~bowerbird/a.fcgi deleted "find" label as bloat. relabeled "edit" button on options screen to "return". created option-choice buttons at bottom of option-screen. created option-choice field at bottom of option-screen. installed "filename-field" at upper-left. (explanation below.) *** on the options screen, i created a mechanism for selecting choices for an option. to select a specific option, just click on it in the listbox. (you can also navigate through the options by clicking the "prev" and "next" buttons at bottom-right.) if the option calls for a specific choice, the choices are listed on the buttons, so a user can just click his/her choice. if an option calls for a string, a user can enter that string into the field at the bottom, and press [enter] to have that string placed into the selected option... (i will also include a font popup at a later time, so the user won't have to manually enter a font-name.) eventually i will turn this into a system which explains all of the options to a naive beginner, which is why i've used this particular method, in case you were wondering. it's a bit laborious for experts, but they can deal with that. *** the "filename-field" tells the app what filename you want to have all files saved under... a folder will be created on the site with that 5-lowercase-letter name, and all of your files that are created will be saved in it. in addition, all the files will be prefaced with that name. this folder-preparation isn't coded yet, so at present, an edited file is still saved at the website's root level, just as it as always been. that will change tomorrow. i might (or might not) install password protection on these folders, for people who are leery about letting their work float into the world without authorization. on the other hand, there will be cross-platform apps that run offline which are equivalent to this web-app (generated from exactly the same code), so i will likely tell those people to go offline and not use the web-app. *** this version, like the last two, has converter routines in it... so whenever we're satisfied with the interface -- not "finished", just satisfied -- we can move on to the meat-and-potatoes part of this creation process. just let me know... i await today's feedback and suggestions. -bowerbird

2 1

Re: time after time
by Bowerbird＠aol.com 23 Feb '11

23 Feb '11

keith said: > Then, you have a design flaw in the logical sense. > If it is purely a converter tool to produce an end product, > then there should be no last minute editing to do! that might be the case if this tool was only used at the very end. but i expect some authors will choose to use it every single day, so they can review their latest draft in their handheld machines. makes it feel more "like a book", instead of a work-in-progress. -bowerbird

2 1