Re: Exegesis 7: Fill Justification
Il giorno 02/mar/04, alle 04:12, Larry Wall ha scritto: [...] : Problem solved!!! ;-) I think you prove my point. :-) Very nice certamen. You would be probably thrilled by an italian Usenet poster I'm honoured to know, who manually justifies every single post he writes. No extra spaces, and no hyphenation. He is Leonardo Serni. Random examples: Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Someone uses the verb to sernify (sernificare) to indicate this style. Someone thinks Leonardo Serni is like Nicolad Bourbaki. On his part, Leonardo says this technique does not take him too much time. cheers, Stefano
Re: Exegesis 7: Fill Justification
Il giorno 02/mar/04, alle 04:12, Larry Wall ha scritto: [...] : Problem solved!!! ;-) I think you prove my point. :-) Very nice certamen. You would be probably thrilled by an italian Usenet poster I'm honoured to know, who manually justifies every single post he writes. No extra spaces, and no hyphenation. He is Leonardo Serni. Random examples: Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Someone uses the verb to sernify (sernificare) to indicate this style. Someone thinks Leonardo Serni is like Nicolad Bourbaki. On his part, Leonardo says this technique does not take him too much time. cheers, Stefano
Re: Exegesis 7: Fill Justification
Il giorno 02/mar/04, alle 10:08, Stefano Rodighiero ha scritto: [...] Someone thinks Leonardo Serni is like Nicolad Bourbaki. ^^^ Oops. That was 'Nicolas'. Sorry. Stefano
Re: Exegesis 7: Fill Justification
Tom Christiansen [EMAIL PROTECTED] writes: On Tue, Mar 02, 2004 at 10:01:11AM +1100, Damian Conway wrote: : That's a *very* interesting idea. What do people think? I think anyone who does full justification without proportional spacing and hyphenation is severely lacking in empathy for the reader. Ragged right is much easier on the eyes--speaking as someone who had their seventh eye operation today. At least aesthetically, yes, it sure does look better ragged. I do wonder why that is, though. Could it be that the unevenness of the inserted fixed-width spacing looks rough? Or is maybe because with long lines, one's eye might get lost, being slower to tell one line from the next? That's certainly a reason for have shorter columns. In a message of mine to p5p of 4-Nov-2003 [EMAIL PROTECTED], I showed (but did not mention) how this sort of can be done without inserting any spurious spaces whatsoever, even in a long paragraph: Well, no. Mark answered so quickly after I did, and covered so much of it so succinctly, that I backed off again. It seems to me that he and I have both for a long time yearned for a perliotut; I don't believe either of us has ever fleshed out more than an outline, though. IO is a subject that's not always easy to figure out how to get the best handle on (ENOPUN). For one thing, it's steeped in Unix lore and tradition, and it requires either knowing or else teaching quite a bit of C programming that would otherwise be completely irrelevant to Perl. For example, when you see someone lseek zero bytes from the current position in Perl, you know they're remembering the ANSI C requirement of a seek falling between switching from reading to writing or vice versa. As always, you're subject to all the silly bugs in your libc runtime system and in your kernel; for example, we tried to have all buffers flushed before a fork() to avoid duplicate output in the child by calling fflush(0) from C, the intent being to flush data still there in stdio buffers. Unfortunately, on some platforms, you'll accidentally toss not just pending output, but also pending input. Thus the case where read on STDIN was called with 2 against asdf\n, you'd still have the df\n yet to read get completely trounced. This is incorrect behaviour, at least as far as the goal of flushing pending output buffers before forking. Sadly, there really are a zillion little things like this, and these are just the exceptions, not the core functionality that you'd like to teach people for learning IO. Blocking and buffering are tricky; did you remember that the output commands can also block? Think about sending something down a pipe where the reader on the other end is slow or busy. That's why with select you also have a slot for output handles you want to know whether are ready for IO. It just goes on and on. It would be easier to hand out copies of Stevens than to write perliotut, but that's too embarrassing and annoying. However, I fear this isn't really readily automated; sorry to interrupt. :-) It's more fun if you do an acrostic on the left hand column. And rather harder if you perpetrate a simultaneous acrostic on the right. But I've given up on such pursuits. Not that I ever managed an ambidexterous one myself anyway. For particular values of fun, of course. -- Beware the Perl 6 early morning joggers -- Allison Randal
Re: Exegesis 7: Fill Justification
Damian Conway wrote: Gregor N. Purdy wrote: In the section He doth fill fields... we see an example of Fill Justification where two spaces fit between every word. This doesn't give us an idea of how spaces are distributed if the number of spaces needed does not divide evenly into the number of interstices. Currently extra spaces are fitted into the rightmost gaps (as this seems -- to me at leats- to produce the least weird results). I've tried all sorts of other schemes but none seem as satisfactory to me. An alternative is to have fill rightmost gaps and fill leftmost gaps on alternate lines. This produces more balanced looking columns, so they don't all look heavier on the left. -- Richard Nuttall
Re: Exegesis 7: Fill Justification
Richard Nuttall suggested: An alternative is to have fill rightmost gaps and fill leftmost gaps on alternate lines. This produces more balanced looking columns, so they don't all look heavier on the left. That's a *very* interesting idea. What do people think? For example: Now is the winter of our discontent / Made glorious summer by this sun of York; / And all the clouds that lour'd upon our house / In the deep bosom of the ocean buried. / Now are our brows bound with victorious wreaths; / Our bruised arms hung up for monuments; / Our stern alarums changed to merry meetings, / Our dreadful marches to delightful measures. Grim-visaged war hath smooth'd his wrinkled front; / And now, instead of mounting barded steeds / To fright the souls of fearful adversaries, / He capers nimbly in a lady's chamber. vs: Now is the winter of our discontent / Made glorious summer by this sun of York; / And all the clouds that lour'd upon our house / In the deep bosom of the ocean buried. / Now are our brows bound with victorious wreaths; / Our bruised arms hung up for monuments; / Our stern alarums changed to merry meetings, / Our dreadful marches to delightful measures. Grim-visaged war hath smooth'd his wrinkled front; / And now, instead of mounting barded steeds / To fright the souls of fearful adversaries, / He capers nimbly in a lady's chamber. Or: I think one of the outstanding features of OO Perl is that is allows you to approach OO with the same mindset as you're used to in another language. By that I mean that you can write OO Perl that's similar in structure and operation to a C++ program, or OO Perl that's very like Smalltalk, or OO Perl that mimics Self, or CLOS, or Eiffel. I once even implemented a Perl module that added Python- esque scoping-by-indentation. In other words, whatever brand of OO you're used to using, you can stick with it when you move to Perl. Eventually you discover that your notions about what OO actually is have been stretched and challenged so often that you've developed an entirely new understanding of what OO truly is -- your own OO mindset. But there's another important aspect to all that flexibility. Because it can accommodate such a wide range of approaches, as you become a more accomplished OO programmer Perl also lets you select the most appropriate mindset -- or mindsets! -- for a particular problem. If you need OO closures in one application, and interfaces in another, and prototype cloning in a third, you can implement each in Perl. And if you need closures and interfaces and cloning and inheritance polymorphism and objects that can change their class and classes that can modify their inheritance hierarchies, all in the same application, in Perl you can do that too. So, although you don't need to approach OO Perl with a different mindset, after a while you're almost certain to discover one. I don't know of any other programming language that can give you that. vs: I think one of the outstanding features of OO Perl is that is allows you to approach OO with the same mindset as you're used to in another language. By that I mean that you can write OO Perl that's similar in structure and operation to a C++ program, or OO Perl that's very like Smalltalk, or OO Perl that mimics Self, or CLOS, or Eiffel. I once even implemented a Perl module that added Python- esque scoping-by-indentation. In other words, whatever brand of OO you're used to using, you can stick with it when you move to Perl. Eventually you discover that your notions about what OO actually is have been stretched and challenged so often that you've developed an entirely new understanding of what OO truly is -- your own OO mindset. But there's another important aspect to all that flexibility. Because it can accommodate such a wide range of approaches, as you become a more accomplished OO programmer Perl also lets you select the most appropriate mindset -- or mindsets! -- for a particular problem. If you need OO closures in one application, and interfaces in another, and prototype cloning in a third, you can implement each in Perl. And if you need closures and interfaces and cloning and inheritance polymorphism and objects that can change their class and classes that can modify their inheritance hierarchies, all in the same application, in Perl you can do that too. So, although you don't need to approach OO Perl
Re: Exegesis 7: Fill Justification
Damian Conway wrote: Richard Nuttall suggested: An alternative is to have fill rightmost gaps and fill leftmost gaps on alternate lines. This produces more balanced looking columns, so they don't all look heavier on the left. That's a *very* interesting idea. What do people think? The Version 1 samples had various whitespace worms appear over on the right, which get broken up to some extent with v2. However, v2 has some minor even/odd patterns that get some mild notice. But overall, I like #2 better. Since I don't think whitespace management is something that needs to be deterministic, why not choose the gaps randomly? If we do need deterministic results, then a pseudo-random pattern where you expand the C(($LineNumber * $GapToExpandCounter * $SomePrimeNumber) % $GapsOnLine)th gap? There's also a gremlin in the back of my head telling me the typesetting industry probably solved this riddle years ago. But I have no time to research it this week. -- Rod
Re: Exegesis 7: Fill Justification
On Tue, Mar 02, 2004 at 10:01:11AM +1100, Damian Conway wrote: : That's a *very* interesting idea. What do people think? I think anyone who does full justification without proportional spacing and hyphenation is severely lacking in empathy for the reader. Ragged right is much easier on the eyes--speaking as someone who had their seventh eye operation today. (More laser surgery to blast away more of my lens capsule, because the hole they made last time wasn't quite big enough, and I got smears at night...) Larry
Re: Exegesis 7: Fill Justification
On Tue, Mar 02, 2004 at 10:01:11AM +1100, Damian Conway wrote: : That's a *very* interesting idea. What do people think? I think anyone who does full justification without proportional spacing and hyphenation is severely lacking in empathy for the reader. Ragged right is much easier on the eyes--speaking as someone who had their seventh eye operation today. At least aesthetically, yes, it sure does look better ragged. I do wonder why that is, though. Could it be that the unevenness of the inserted fixed-width spacing looks rough? Or is maybe because with long lines, one's eye might get lost, being slower to tell one line from the next? That's certainly a reason for have shorter columns. In a message of mine to p5p of 4-Nov-2003 [EMAIL PROTECTED], I showed (but did not mention) how this sort of can be done without inserting any spurious spaces whatsoever, even in a long paragraph: Well, no. Mark answered so quickly after I did, and covered so much of it so succinctly, that I backed off again. It seems to me that he and I have both for a long time yearned for a perliotut; I don't believe either of us has ever fleshed out more than an outline, though. IO is a subject that's not always easy to figure out how to get the best handle on (ENOPUN). For one thing, it's steeped in Unix lore and tradition, and it requires either knowing or else teaching quite a bit of C programming that would otherwise be completely irrelevant to Perl. For example, when you see someone lseek zero bytes from the current position in Perl, you know they're remembering the ANSI C requirement of a seek falling between switching from reading to writing or vice versa. As always, you're subject to all the silly bugs in your libc runtime system and in your kernel; for example, we tried to have all buffers flushed before a fork() to avoid duplicate output in the child by calling fflush(0) from C, the intent being to flush data still there in stdio buffers. Unfortunately, on some platforms, you'll accidentally toss not just pending output, but also pending input. Thus the case where read on STDIN was called with 2 against asdf\n, you'd still have the df\n yet to read get completely trounced. This is incorrect behaviour, at least as far as the goal of flushing pending output buffers before forking. Sadly, there really are a zillion little things like this, and these are just the exceptions, not the core functionality that you'd like to teach people for learning IO. Blocking and buffering are tricky; did you remember that the output commands can also block? Think about sending something down a pipe where the reader on the other end is slow or busy. That's why with select you also have a slot for output handles you want to know whether are ready for IO. It just goes on and on. It would be easier to hand out copies of Stevens than to write perliotut, but that's too embarrassing and annoying. However, I fear this isn't really readily automated; sorry to interrupt. :-) --tom PS: Ok, maybe one *could* do it, but that would still require a whole lot of PhD-ish NLP work, and surely Damian's too engaged now for the diversion.
Re: Exegesis 7: Fill Justification
Larry observed: I think anyone who does full justification without proportional spacing and hyphenation is severely lacking in empathy for the reader. Well, it really depends on how neatly one is able to write. It really isn't that hard to create a fully justified text that doesn't inflict pain on the reader. English is especially good in that regard, offering such a plethora of synonyms for most common words, so that it's easy to squeeze or expand a piece of writing by enough letters to fit it cleanly into specific margins. Hmmm. Maybe what Cform really needs to do when requested to fully justify is to *re-write* the input so that it just naturally lines up on the actual margins, without any extra whitespace needed in any line. Whenever it finds a line that needs to be longer, maybe it could query WordNet for every word in the line, and find a collection of synonyms that would, on replacing the existing words, fill in the unsightly gaps in the line. And, if no such set of replacements could be found, maybe it could resort to modifying the line in other ways -- such as changing the punctuation in some inconspicuous way or as a last resort adding emoticons. Problem solved!!! ;-) Damian (Seriously though, full justification is mainly there for completeness, and in readiness for the day when Cform is able to handle variable-width text and/or HTML output. In the interim we just aim to produce the most readable results given the constraints imposed by the lack of proportional spacing.)
Re: Exegesis 7: Fill Justification
On Tue, Mar 02, 2004 at 12:42:28PM +1100, Damian Conway wrote: : Well, it really depends on how neatly : one is able to write. It really isn't : that hard to create a fully justified : text that doesn't inflict pain on the : reader. English is especially good in : that regard, offering such a plethora : of synonyms for most common words, so : that it's easy to squeeze or expand a : piece of writing by enough letters to : fit it cleanly into specific margins. Well, as both a linguist and a writer, I have to say that I don't really believe in exact synonyms, and while you can get away with trading diction for prettiness to some extent, nearly all efforts along those lines end up sounding a little bit wooden to my ears. : Hmmm. Maybe what Cform really needs : to do when requested to fully justify : is to *re-write* the input so that it : just naturally lines up on the actual : margins, without any extra whitespace : needed in any line. Whenever it finds : a line that needs to be longer, maybe : it could query WordNet for every word : in the line, and find a collection of : synonyms that would, on replacing the : existing words, fill in the unsightly : gaps in the line. And, if no such set : of replacements could be found, maybe : it could resort to modifying the line : in other ways -- such as changing the : punctuation in some inconspicuous way : or as a last resort adding emoticons. : Problem solved!!! ;-) I think you prove my point. :-) Larry
Exegesis 7: Fill Justification
In the section He doth fill fields... we see an example of Fill Justification where two spaces fit between every word. This doesn't give us an idea of how spaces are distributed if the number of spaces needed does not divide evenly into the number of interstices. In the section More particulars must justify my knowledge..., indicates the approach is to ...distribute any padding as evenly as possible into the existing whitespace gaps..., but still doesn't tell us what the rule really is. In the example, there are two spaces to be distributed and three interstices. The last two each get one space. That could be the add one pad to each insterstice from right to left, repeat until exhausted rule, which isn't really about even distribution. One other note about this example: The text says Cform will ...extract a maximal substring..., but in the example that string would be A fellow of infinite j. The example output shows that the extracted string isn't quite maximal. It tries to keep words together (this rule is detailed elsewhere, but this example doesn't refer to that extraction rule). -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
Re: Exegesis 7: Fill Justification
Gregor N. Purdy wrote: In the section He doth fill fields... we see an example of Fill Justification where two spaces fit between every word. This doesn't give us an idea of how spaces are distributed if the number of spaces needed does not divide evenly into the number of interstices. Currently extra spaces are fitted into the rightmost gaps (as this seems -- to me at leats- to produce the least weird results). I've tried all sorts of other schemes but none seem as satisfactory to me. Damian
Re: Exegesis 7: Fill Justification
Damian -- Good. I don't remember where I first heard about doing it that way vs. from the left, but the results going from the right to left are typically better looking than from left to right, and I use that way exclusively now. Regards, -- Gregor On Sat, 2004-02-28 at 15:54, Damian Conway wrote: Gregor N. Purdy wrote: In the section He doth fill fields... we see an example of Fill Justification where two spaces fit between every word. This doesn't give us an idea of how spaces are distributed if the number of spaces needed does not divide evenly into the number of interstices. Currently extra spaces are fitted into the rightmost gaps (as this seems -- to me at leats- to produce the least weird results). I've tried all sorts of other schemes but none seem as satisfactory to me. Damian -- Gregor Purdy[EMAIL PROTECTED] Focus Research, Inc. http://www.focusresearch.com/
