What to do with an uncursed luckstone? (slightly spoilish)

[Rubinstein]

Usually I was able to bless my luckstone, once discovered. This time I
still have no holy water, the only altar for now is in Minetown temple
which I'm not going to convert very soon.

And here my questions:

1.a] Is it correct that an uncursed luckstone 'freeze' your current luck
state?

1.b] If the answer is yes, would you recommend to stash the stone away in
my bag until I know my current luck state?

2.] How can I determine my current luck w/o a coaligned altar?

[Erik Hesselink]

S

P

O

I

L

E

R

S



A

H

E

A

D

Post by Rubinstein
1.a] Is it correct that an uncursed luckstone 'freeze' your current luck
state?

No; it makes both good and bad luck not 'time out', i.e. return to 0
luck. A blessed stone only stops good luck from timing out, and a cursed
one only stops bad luck from timing out. In addition, a non-cursed
luckstone will give +3 luck, and a cursed one -3.

Post by Rubinstein
1.b] If the answer is yes, would you recommend to stash the stone away in
my bag until I know my current luck state?

No, keep it in your main inventory, at least if you know that your luck
is positive (and it is, most of the time). So, if you didn't just go
around Sokoban breaking every boulder, it should be ok.

Post by Rubinstein
2.] How can I determine my current luck w/o a coaligned altar?

A potion or a wand of enlightenment would do the trick.

Erik

[Jussi Pöyhönen]

Rubinstein wrote in message ...

Post by Rubinstein
1.a] Is it correct that an uncursed luckstone 'freeze' your current luck
state?

Probably so, since an uncursed lucktone gives you the following:
Good and bad luck won't time out for you.

Post by Rubinstein
1.b] If the answer is yes, would you recommend to stash the stone away in
my bag until I know my current luck state?

Yep.

Post by Rubinstein
2.] How can I determine my current luck w/o a coaligned altar?

Uncursed potion or a wand of enlightment... or a enlightment from a fountain.
Also, your luck isn't very low if you haven't done things which decrease it,
ie. bad things. If you think your luck is negative, you could always wait for
n amount of time before getting the stone out (or after ie. throwing many
valuable gems to a co-aligned unicorn, without the said altar).

- Jussi

[Jonathan Carter]

Post by Rubinstein
Usually I was able to bless my luckstone, once discovered. This time I
still have no holy water, the only altar for now is in Minetown temple
which I'm not going to convert very soon.
1.a] Is it correct that an uncursed luckstone 'freeze' your current luck
state?
1.b] If the answer is yes, would you recommend to stash the stone away in
my bag until I know my current luck state?

If I recall correctly, this is how luckstones work: [SPOILERS AHEAD]






SPACE









SPACE (How do you insert a form feed in vim?)










Ok. Zero is normal luck. Negative is bad, and positive is good.

An uncursed luckstone sets your default luck to 3, instead of 0.

A blessed luckstone does the same, and also makes it so that good luck
does not time out, which means that when you have >3 luck, it does NOT
tend to go back down -- it stays where it is.

A cursed luckstone sets your default luck to -3, and makes BAD luck
persistent -- BAD luck stays the same, while good luck gradually goes
down to -3.

[Robert R Schneck]

Rubinstein <***@t-online.de> wrote:
[a question about blessing luckstones in July 2003]

Jonathan Carter <***@eris.hcksrd01.tn.comcast.net> wrote:
[an incorrect answer]

Remarkable.

(Really, it's not very important to bless a luckstone. It will help if
you manage to get massively bad luck without noticing, but how likely is
that? It also helps in the late game when your inventory tends to get
cursed, but I usually don't bother even then.)

Robert

[Eric Wright]

Post by Robert R Schneck
[a question about blessing luckstones in July 2003]
[an incorrect answer]
Remarkable.
(Really, it's not very important to bless a luckstone. It will help if
you manage to get massively bad luck without noticing, but how likely is
that? It also helps in the late game when your inventory tends to get
cursed, but I usually don't bother even then.)
Robert

It wasn't all that wrong, based on your definition of persistent. If,
by persistant, you mean cannot change, then yes... Jonathan was wrong.
However, I read persistant as immune to timing out. In that case, he
was (mostly) correct.

Try the following in wizard mode:
wish up a bunch of uncursed potions of enlightenment.
quaff one, your luck should be at zero
wish for an uncursed luckstone
quaff another potion, your luck should be at three
drop/stow this luckstone and wish for a cursed luckstone
quaff another potion, your luck should be at negative three
toss out the cursed luckstone and retrieve the uncursed stone
quaff another potion, your luck is back at three
wish up a mirror and smash it
quaff another potion, your luck is down to one
Wait several hundred turns
quaff another potion, your luck is still one, due to the non-timeout
of good and bad luck
wish up a potion of holy water and bless your luckstone (or wish for a
blessed luckstone and toss the uncursed one).
Wait a few hundred turns, your luck should be back to three
(Note that the luck shown here is Luck, which is defined in you.h as
the sum of u.uluck and u.moreluck, which are described below).

Now, normally, base luck is 0, except during full moons when it is 1
or Friday the 13th, when it is -1. (Full moon Friday the 13ths get
both, so the baseluck is 0). Base luck is always between -1 and 1,
and will tend toward that value unless the timeout is blocked.

When you pickup an object granting luck, the following code in
attrib.c is called:

int
stone_luck(parameter)
boolean parameter; /* So I can't think up of a good name. So sue me.
--KAA */
{
register struct obj *otmp;
register long bonchance = 0;

for (otmp = invent; otmp; otmp = otmp->nobj)
if (confers_luck(otmp)) {
if (otmp->cursed) bonchance -= otmp->quan;
else if (otmp->blessed) bonchance += otmp->quan;
else if (parameter) bonchance += otmp->quan;
}

return sgn((int)bonchance);
}
/* there has just been an inventory change affecting a luck-granting
item */
void
set_moreluck()
{
int luckbon = stone_luck(TRUE);

if (!luckbon && !carrying(LUCKSTONE)) u.moreluck = 0;
else if (luckbon >= 0) u.moreluck = LUCKADD;
else u.moreluck = -LUCKADD;
}

The net effect of this is that, if you have more bad luck inducing
items than good luck inducing items, stone_luck will return -1, else,
it will return 0 or 1. When it returns -1, u.moreluck is decremented
by LUCKADD, which is defined in you.h as 3. Otherwise, u.moreluck is
incremented by LUCKADD.

On the other hand, doing something that "affects your luck", like
breaking mirrors, tossing gems at unicorns, sacrificing, etc has an
effect on u.uluck. Also, it is u.uluck that is affected by
nh_timeout() in timeout.c

The only thing u.moreluck does is that it is added to u.uluck in
determining if you are lucky, very lucky, etc. in the enlightenment
function (triggered by a potion, the eyes of the overworld or the end
of the game) and if you have extra luck or reduced luck. It does NOT
affect baseluck as defined in nh_timeout().

All in all, I'm feeling rather unlucky right now... I need some rest.

--
E...They say that in the dungeon you don't usually have any luck at
all.

PS Isn't that an ironic random sig for you!

[Robert R Schneck]

Post by Eric Wright

Post by Robert R Schneck
[a question about blessing luckstones in July 2003]
[an incorrect answer]
Remarkable.

It wasn't all that wrong, based on your definition of persistent. If,
by persistant, you mean cannot change, then yes... Jonathan was wrong.
However, I read persistant as immune to timing out. In that case, he
was (mostly) correct.

Jonathan's error was to imply that only blessed luckstones stop good
luck from timing out. In fact, uncursed luckstones do too. They also
stop bad luck from timing out, but that usually isn't a problem.

Robert

[Gabkin]

Post by Jonathan Carter
If I recall correctly, this is how luckstones work: [SPOILERS AHEAD]
SPACE
SPACE (How do you insert a form feed in vim?)
Ok. Zero is normal luck. Negative is bad, and positive is good.
An uncursed luckstone sets your default luck to 3, instead of 0.
A blessed luckstone does the same, and also makes it so that good luck
does not time out, which means that when you have >3 luck, it does NOT
tend to go back down -- it stays where it is.
A cursed luckstone sets your default luck to -3, and makes BAD luck
persistent -- BAD luck stays the same, while good luck gradually goes
down to -3.

more spoily.....





An uncursed luckstone stops both your good _and_ your bad luck from
timing out...

[Jakob Creutzig]

Post by Jonathan Carter
If I recall correctly, this is how luckstones work: [SPOILERS AHEAD]
SPACE
SPACE (How do you insert a form feed in vim?)
Ok. Zero is normal luck. Negative is bad, and positive is good.
An uncursed luckstone sets your default luck to 3, instead of 0.

You're confusing bonus luck and default luck. It does not
really matter, though; things seem to work out the same in
the end.

But more importantly, if you have an equal number of
cursed and blessed luckitems (luckstones and some quest
artifacts), both Bad and Good Luck Timeouts are canceled.
In english, if you carry an uncursed luckstone, neither
good nor bad luck will cancel out.

Best,
Jakob

[Cyde Weys]

What does luck do anyway?

[Dylan O'Donnell]

Post by Cyde Weys
What does luck do anyway?

It modifies many (very many) die-rolls in the game. Furthermore, many
good outcomes of various events require you to have luck greater than
a certain threshold.

[Eric Wright]

Post by Cyde Weys
What does luck do anyway?

IMO, one of the biggest factors is in wishing. If you make a wish
when you have bad luck, there is a not-so-insignificant chance of
getting nothing. If luck + a random number from 0 to 4 is negative,
Unfortunately, nothing happens.

Luck also boosts chances of many things happening: untrapping traps,
prayer being successful/the number of good things happening, hitting a
monster in combat, and even one of the random number generation
functions in rnd.c takes luck into account (rnl).

--
E...Concise conquest: Control, confuse, conjure, condemn.

[Jakob Creutzig]

Post by Eric Wright
Luck also boosts chances of many things happening: untrapping traps,
prayer being successful/the number of good things happening,

More importantly, also the kind of good things happening.
If you're too lucky, you easily get crowned; hence one should
be a bit careful about too much luck.

Best,
Jakob

[jerk-o]

Hail and sacrafice to Jakob Creutzig <***@mathematik.tu-darmstadt.de>,
Lord of Terror, and destroyer of souls.

Post by Jakob Creutzig

Post by Eric Wright
Luck also boosts chances of many things happening: untrapping traps,
prayer being successful/the number of good things happening,

More importantly, also the kind of good things happening.
If you're too lucky, you easily get crowned; hence one should
be a bit careful about too much luck.

What's wrong with being crowned?

[Boudewijn Waijers]

Post by jerk-o
What's wrong with being crowned?

Well, there all kinds of positive sides to being crowned: you get a nice
weapon or spellbook, you get several resistances, and you get a bonus
title as well.

The negative side is that your prayer timeout increases greatly, meaning
you have to wait much longer after a prayer before you can safely pray
again.

As has been said before often here: if your god crowns you, it's his or
her way of saying to you: "Okay, I heard you... once again. Here are some
nice things. Now stop bothering me unless you're in deep shit, please?".

[Jakob Creutzig]

Post by jerk-o
What's wrong with being crowned?

Spellbook/protection praying is delayed immensely.

Best,
Jakob

[Kent Paul Dolan]

Post by Jonathan Carter
SPACE (How do you insert a form feed in vim?)

Typing, in insert mode, ctrl-v ctrl-l is the usual trick.

It doesn't work very well, though, since many browser based
news accesses ignore form feeds when rendering articles for
display -- stick to the spaces.

xanthian.

[Jukka Lahtinen]

Post by Kent Paul Dolan

Post by Jonathan Carter
SPACE (How do you insert a form feed in vim?)

It doesn't work very well, though, since many browser based
news accesses ignore form feeds when rendering articles for

Then those systems are broken. Formfeed is a standard supposed to work in
news, and any broken browser-based system should be fixed.

[Boudewijn Waijers]

Post by Jukka Lahtinen

[...] many browser based
news accesses ignore form feeds when rendering articles for

Then those systems are broken. Formfeed is a standard supposed to
work in news, and any broken browser-based system should be fixed.

I must agree, even while I'm using such a browser myself.

[Kent Paul Dolan]

Another X-No-Archive posting from Jukka that I never
see unless someone quotes it, along with roughly 12.5%
of other Usenet news addicts. Sigh.

Post by Boudewijn Waijers

Post by Jukka Lahtinen

[...] many browser based news accesses ignore
form feeds when rendering articles for

Then those systems are broken. Formfeed is a
standard supposed to work in news, and any broken
browser-based system should be fixed.

Well, no. Just what on earth do you think a "form
feed" is supposed to do on a document that _has no_
page-to-page boundaries, like a (potentially
indefinitely long) web page? If you cannot easily
define an exactly correct behavior, doing nothing is
a very reliable action-of-choice. The controlling
standard in effect for the behavior in response to a
form feed character isn't one for news, but one for
web pages, usually W3C's HTML 4.01 just now.

Should the form feed go to the next European
standard page boundary (which one, they have so
many), or the next American standard page boundary
(only _almost_ as bad; Lyndon Johnson effectively
abolished "letter size" in favor of "legal size"),
or page down some standard amount of whitespace,
or??? Do you just count lines of text and break at
multiple of 60, or 66, or does current default text
size count, so that you form feed in points or picas
or millimeters or ... and then truncate fractions of
lines of text; do you truncate at the baseline or at
the lowest descender or after the leading or is it
line contents dependent on whether there _are_ any
descenders...???

Post by Boudewijn Waijers
I must agree, even while I'm using such a browser
myself.

I'd be a bit surprised if any news-via-browser
implementor did anything useful and "standards
conforming" with form feeds, except perhaps when
rendering the web page to hardcopy.

xanthian, all problems are simple until you think
about them a bit; from then on, the more you think,
the more complicated they become.

I'm a _really_ bad person to argue with about this
subject; I've spent a substantial fraction of my
professional career worrying about the rendering
of text in hardcopy and softcopy and turning those
worries into code. I can thus promise to bore you
to stupefaction on the subject without even getting
winded or consulting a reference.

[Jukka Lahtinen]

Post by Kent Paul Dolan

Post by Jukka Lahtinen

[...] many browser based news accesses ignore
form feeds when rendering articles for

Then those systems are broken. Formfeed is a
standard supposed to work in news, and any broken

Well, no. Just what on earth do you think a "form
feed" is supposed to do on a document that _has no_
page-to-page boundaries, like a (potentially

The same that it does on any decent newsreader: Whenever the formfeed
character is within the visible part of the window, leave the rest of the
window blank. When it is scrolled out from the top of the window, start
showing the rest of the text.

Post by Kent Paul Dolan
Should the form feed go to the next European
standard page boundary (which one, they have so
many), or the next American standard page boundary

No reason to mix any paper page boundaries here, they are not relevant.
The text is not on paper, it is on the screen. Or do you think people are
thinking about paper sizes and where the page breaks would be if the
article would be printed, when they write here?
The correct behavior is based on the screen size (or window size), not on
any paper size.

[Kent Paul Dolan]

Whenever the formfeed character is within the
visible part of the window, leave the rest of the
window blank. When it is scrolled out from the top
of the window, start showing the rest of the text.

When the window is resized? When it is scrolled
upward? When the window aspect ratio is changed?
When the user font size preference is changed? When
the user font fixed/proportional choice is changed?
When the font weight is changed? When the font type
is changed? When the font style is changed? When the
window is simultaneously rendered on a Braille
tablet with a different width and height in pixels?
When the Cascading Style Sheet, version Two, is
quite possibly different for each user of the news
engine? When what the user wants is _exactly_ a
break to the next page boundary of the currently set
print preferences? What do you do for verbal
interfaces for the blind; read through the form
feed, or announce it aloud and wait for instructions
from the user?

Trust me, you do _not_ want to implement that. You
don't even want to standardize that.

Post by Kent Paul Dolan
Should the form feed go to the next European
standard page boundary (which one, they have so
many), or the next American standard page
boundary

No reason to mix any paper page boundaries here,
they are not relevant.

Sometimes they are. Some people, somewhere, I'm
sure, are still stuck in the days of paper
terminals. Old computer hardware never dies, it
just gets donated to schools.

The text is not on paper, it is on the screen.

And so a form feed isn't meaningful; there is no
form.

Or do you think people are thinking about paper
sizes and where the page breaks would be if the
article would be printed, when they write here?

You have far too narrow a concept of "here".

We are not talking about a standard for
rec.games.roguelike.nethack, we are talking about
something that has to cover all of Usenet, BITnet,
DECnet (if it still exists), Clarinet, BIOnet, and
all the other News-formatted nets. There are so
many newsgroups for so many purposes, and those
purposes all in flux, no single human being can even
ever become acquainted with what is normal practice
in all the places where news formatted text is
rendered, so clever assumptions about what _you_
think the user wants are unworkable. You have to
stick to what all users everywhere would expect
based on the long history of use of the form feed.

Did I mention I wasted 4.5 years of my life on an
ANSI Technical Committee writing what became three
international standards? Standards preparers are
incredibly conservative, they have to be.

The correct behavior is based on the screen size
(or window size), not on any paper size.

Nope. A form feed is by its very nature inherent to
a _form_, an indefinitely pixel by pixel scrollable
window is not an instance of a form. You'd
completely break hardcopy compatibility that way,
and for many uses, that form feed would be there
specifically to be used in hardcopy renditions of
the text. It might very well be intended to _be_ a
printed form. [I, personally, have conveyed printed
forms via Usenet news articles in a long and
checkered history on Usenet, though I cannot
remember why any more two decades later.]

You are trying to redefine "form feed" to mean "hide
information", because that's how _you_ want to use
it in this one little newsgroup, and for 99% of its
uses _on Usenet_, that probably isn't an appropriate
redefinition at all, just because the output medium
changes from hardcopy to softcopy.

xanthian (I did give fair warning about being able
to post snoozegas on this subject forever).

[Boudewijn Waijers]

Post by Kent Paul Dolan

Post by Jukka Lahtinen
The text is not on paper, it is on the screen.

And so a form feed isn't meaningful; there is no
form.

Hence, don't use the name "form feed". That's the term for ASCII-12 when
used *on paper*. When used on screen, a better name would be "separator".

ASCII-12 (and ASCII in general) wasn't devised for paper only. There, it
means form feed. With other uses, it may implicate something else.

[Kent Paul Dolan]

Post by Boudewijn Waijers
ASCII-12 (and ASCII in general) wasn't devised for
paper only.

Yes, it was. ASCII long predates softcopy terminals;
it is a development of the early punch card days, in
competition with IBM's EBCDIC.

Post by Boudewijn Waijers
There, it means form feed.

And because other uses must be forever backward
compatible, so must it other places as well. If you
want "ASCII-12" [<CTRL-L>] to mean something other
than "form feed", you must create an entirely new
standard in which it will have that meaning. What
you have will not be "ASCII" any more, and ASCII is
so widely embedded in the world's software, it
simply cannot be modified and still called by that
name.

xanthian.

[David Damerell]

Post by Kent Paul Dolan
And because other uses must be forever backward
compatible, so must it other places as well. If you
want "ASCII-12" [<CTRL-L>] to mean something other
than "form feed", you must create an entirely new
standard in which it will have that meaning.

Of course we see from this;

"ASCII itself (ASA X3.4-1963) didn't attribute any meaning to the
control characters at all, as far as I can see; they're entirely
implementation-defined."

That you were wrong, wrong, wrong...

[Jukka Lahtinen]

Post by Kent Paul Dolan

Whenever the formfeed character is within the
visible part of the window, leave the rest of the
window blank. When it is scrolled out from the top
of the window, start showing the rest of the text.

When the window is resized? When it is scrolled
upward? When the window aspect ratio is changed?

I think I mentioned scrolling. For the other actions..
let them just be handled in some sensible way.
I don't think it's that important for this purpose to define what is best.

Post by Kent Paul Dolan
interfaces for the blind; read through the form
feed, or announce it aloud and wait for instructions
from the user?

I'm not familiar with those devices, I think some kind of pause would be
appropriate..

Post by Kent Paul Dolan
Trust me, you do _not_ want to implement that. You
don't even want to standardize that.

Agreed.

Post by Kent Paul Dolan

The text is not on paper, it is on the screen.

And so a form feed isn't meaningful; there is no
form.

The form is the screen or window.

Post by Kent Paul Dolan

Or do you think people are thinking about paper
sizes and where the page breaks would be if the
article would be printed, when they write here?

You have far too narrow a concept of "here".
We are not talking about a standard for
rec.games.roguelike.nethack, we are talking about
something that has to cover all of Usenet, BITnet,

We are in Usenet, so of course what I say is about Usenet.
And what is normal behavior for newsreaders.

Post by Kent Paul Dolan
DECnet (if it still exists), Clarinet, BIOnet, and
all the other News-formatted nets. There are so

I haven't used them, I thought they have the same standards as Usenet.

Post by Kent Paul Dolan

The correct behavior is based on the screen size
(or window size), not on any paper size.

Nope. A form feed is by its very nature inherent to
a _form_, an indefinitely pixel by pixel scrollable
window is not an instance of a form. You'd
completely break hardcopy compatibility that way,

Maybe that could be user-definable..

Post by Kent Paul Dolan
xanthian (I did give fair warning about being able
to post snoozegas on this subject forever).

And I will shut up about this subject. I think I already said what I was
thinking and I don't care about going on.
It's not my concern if people want to use www tools for Usenet, I prefer
using software that is *meant* for Usenet.

[Dylan O'Donnell]

[formfeeds]

Post by Kent Paul Dolan

Post by Jukka Lahtinen
The text is not on paper, it is on the screen.

And so a form feed isn't meaningful; there is no
form.

The definition of the formfeed character is "A format effector which
advances the active position to the same character position on a
pre-determined line of the next form or page." In a web context, this
would probably mean ending the text of the article there, with a link
to a new page containing either just the text after the formfeed or
additionally repeating the text before it, depending on how you cared
to implement it (I'd prefer the latter, for ease of copying). There's
a perfectly good concept of "page" on the Web, why not make use of it?

Post by Kent Paul Dolan
You are trying to redefine "form feed" to mean "hide
information", because that's how _you_ want to use
it in this one little newsgroup, and for 99% of its
uses _on Usenet_, that probably isn't an appropriate
redefinition at all, just because the output medium
changes from hardcopy to softcopy.

Use of the formfeed character as a spoiler-hider is hardly restricted
to rgrn; it was included in son-of-RFC1036 ("Formfeed signifies a
point at which a reading agent SHOULD pause and await reader
interaction before displaying further text.") and is in the current
draft Usenet Best Practice document (similar wording).

[Kent Paul Dolan]

Post by Dylan O'Donnell
The definition of the formfeed character is "A
format effector which advances the active position
to the same character position on a pre-determined
line of the next form or page."

Umm, no.

It has, to the best of my knowledge over 43 years of
using it, _always_ gone to the first character
position on the top line of the next page, and
_never_ gone to the identical character position on
the next page as the most recent (or next potential)
printed character on the current page, my
translation of what you quoted.

Where _on earth_ did you find that definition?

Since that standard implementation might very well
skip forward a mere one line, from the bottom line
of the previous page to the top line of the next
page, it is _not_ suitable for "information hiding"
purposes, and so some other tool should be chosen
as the standard mechanism for that purpose. Since
what is desired is usually that a blank screen occur
between the end of normal text, and the beginning of
the hidden text, putting out whatever is a usual
"screenful" of blank lines is a very good choice,
though for most uses. 80 lines would be a better
choice than 25 lines for the number of blank lines,
these days. Very few softcopy terminals are still
restricted to 25 line high screens.

I'm not familiar to any changes to the RFCs, but my
comments to Jukka still hold: if you change the
meaning of "CTRL-L", you can't call what you have
"ASCII" any more, you break too much stuff.

xanthian.

[Dylan O'Donnell]

Post by Kent Paul Dolan

Post by Dylan O'Donnell
The definition of the formfeed character is "A
format effector which advances the active position
to the same character position on a pre-determined
line of the next form or page."

Umm, no.
Where _on earth_ did you find that definition?

Umm, yes. At least, so ISO 646 reads:
http://www.itscj.ipsj.or.jp/ISO-IR/001.pdf

Post by Kent Paul Dolan
I'm not familiar to any changes to the RFCs, but my
comments to Jukka still hold: if you change the
meaning of "CTRL-L", you can't call what you have
"ASCII" any more, you break too much stuff.

ASCII itself (ASA X3.4-1963) didn't attribute any meaning to the
control characters at all, as far as I can see; they're entirely
implementation-defined.

[Kent Paul Dolan]

Post by Dylan O'Donnell
http://www.itscj.ipsj.or.jp/ISO-IR/001.pdf

Perhaps so, but in my several decades long experience,
form feed has always been implemented as described
here:

http://en.wikipedia.org/wiki/Control_character

Post by Dylan O'Donnell
As Commonly Used
12 (Form feed, to cause a printer to eject a page),
Printing control
Form feed starts a new sheet of paper.

and never as described in the document you cite (the
description there would be useless functionality, in
any case, since many hardcopy printers cannot back up,
need a "top of next page" command, and would have zero
use for a "same spot on next page" command if no "top
of next page" command were available; they wouldn't
be able to write on the top of page 2 once gone past
the top of page 1 with that functionality!)

xanthian.

[Jeremy Turner]

Post by Kent Paul Dolan

Post by Dylan O'Donnell
http://www.itscj.ipsj.or.jp/ISO-IR/001.pdf

Perhaps so, but in my several decades long experience,
form feed has always been implemented as described
http://en.wikipedia.org/wiki/Control_character

Post by Dylan O'Donnell
As Commonly Used
12 (Form feed, to cause a printer to eject a page),
Printing control
Form feed starts a new sheet of paper.

and never as described in the document you cite (the
description there would be useless functionality, in
any case, since many hardcopy printers cannot back up,
need a "top of next page" command, and would have zero
use for a "same spot on next page" command if no "top
of next page" command were available; they wouldn't
be able to write on the top of page 2 once gone past
the top of page 1 with that functionality!)
xanthian.

"same column, next row" is how formfeed works on most typewriters...

if anyone remembers what THOSE are... :)

jeremy turner

[Owen Jacobson]

Post by Jeremy Turner
"same column, next row" is how formfeed works on most typewriters...
if anyone remembers what THOSE are... :)

You're thinking of linefeed, not formfeed.

[Jeremy Turner]

Post by Owen Jacobson

Post by Jeremy Turner
"same column, next row" is how formfeed works on most typewriters...
if anyone remembers what THOSE are... :)

You're thinking of linefeed, not formfeed.

yeah... i stand corrected.

[Kent Paul Dolan]

"Jeremy Turner"

Post by Jeremy Turner
"same column, next row" is how formfeed works on
most typewriters...

Nope, you are confusing "line feed" with "form
feed". A "line feed", back in the days when
"carriage-return, line-feed" were two physical
operations with separate behaviors, acted exactly as
you describe.

Very few manual typewriters had anything equivalent
to "form feed" at all; you just did lots and lots of
line feeds instead, until the paper fell out the
top. Later, electrical typewriters sometimes did
include a page eject button, though, IIRC.

Where "form feed" arose was as a replacement for the
old IBM chain-type line printers' "top of form"
command.

Those printers accepted 133 character codes per
line, but the first character was always a control
character, and the next 132 were the printing
characters; there were separate control characters
used in that first position for "don't advance" (so
that multistriking/overprinting to emulate boldface
could be done), "advance one line" (single space)
"advance two lines" (double space), and "advance to
next page" or "top of form", the one we are
considering.

I think that there _were_ no horizontal control
characters back then, because the printer took the
same time to print one character on a line as to
print 132 characters on a line, one spin of the
chain carrying the type font in either case. Thus,
something like a horizontal tab served no purpose,
though it already had been in use for years in
typewriter technology, because in chain printer
technology it didn't make anything go faster.

The card punches also had tabulation keys, but on
the resulting output punch card, what you got was a
lot of spaces, not a "tab character", and that is
what the computer printer saw.

Later printers, for speed, replaced the chain that
spun horizontally with a set of vertical bars, one
per print column, 132 in all, each containing the
whole font, which were pushed up different
appropriate heights to put the desired letter under
the print hammer, by stepper motors, and then all
struck against the ribbon/paper together, but you
still had no need for horizontal control characters
under that model of printing, because, again, they
provided no time savings to a "line at a time" model
of printing.

Besides being faster, this kind of printer made for
less smeary type, because the type carrier wasn't
moving when it was hit, which it was in the case of
the chain printer.

HTH

xanthian.

[Janis Papanagnou]

Post by Kent Paul Dolan

Post by Dylan O'Donnell
http://www.itscj.ipsj.or.jp/ISO-IR/001.pdf

[...]
and never as described in the document you cite (the
description there would be useless functionality, in
any case, since many hardcopy printers cannot back up,
need a "top of next page" command, and would have zero
use for a "same spot on next page" command if no "top
of next page" command were available; they wouldn't
be able to write on the top of page 2 once gone past
the top of page 1 with that functionality!)

The note on page 4.3 of the above document says that the "format
effector" control codes are intended for devices where horizontal
and vertical movement are effected separately. And that the vertical
movement control code alone may be used to achieve the combined
movement. IMO, there is no need to require some hard printing device
to interprete and execute the two combined control codes CR+FF (or
the "abbreviation" FF) independently; a printing device may position
at column 1 on page+1 when given either CR+FF of FF alone; no need
to "backup" from some arbitrary position in the line.

Janis

(Out of curiosity I checked how the Linux standard pagers, more and
less, behave when confronted with a FF (a ^L). More will just stop
dumping the text (no spaces inserted, and page contents from previous
page still visible above). Less seems to completely ignore the FF.)

[Boudewijn Waijers]

Post by Kent Paul Dolan

Post by Dylan O'Donnell
http://www.itscj.ipsj.or.jp/ISO-IR/001.pdf

Perhaps so, but in my several decades long experience,
form feed has always been implemented as described
http://en.wikipedia.org/wiki/Control_character

Hey,

You asked for a reference, you got a *ggod* reference (an RFC), and now
you're dismissing it because you don't like its contents?

Take your losses and admit defeat, despite your decades long
experience...

:-)

Boudewijn.

[Dylan O'Donnell]

Post by Boudewijn Waijers

Post by Kent Paul Dolan

Post by Dylan O'Donnell
http://www.itscj.ipsj.or.jp/ISO-IR/001.pdf

Perhaps so, but in my several decades long experience,
form feed has always been implemented as described
http://en.wikipedia.org/wiki/Control_character

Hey,
You asked for a reference, you got a *ggod* reference (an RFC), and now
you're dismissing it because you don't like its contents?

ISO 646 isn't an RFC; it's an international standard. In fact, the RFC
that defined ASCII (RFC 20) had a slightly different (and less precise)
definition:

FF (Form Feed): A format effector which controls the movement of
the printing position to the first pre-determined printing line on
the next form or page. (Applicable also to display devices.)

Note that this doesn't specify the position _on_ that line.

[Kent Paul Dolan]

Post by Dylan O'Donnell
ISO 646 isn't an RFC; it's an international
standard. In fact, the RFC that defined ASCII (RFC
20) had a slightly different (and less precise)
FF (Form Feed): A format effector which controls
the movement of the printing position to the
first pre-determined printing line on the next
form or page. (Applicable also to display
devices.)

Which in the case is what got implemented, not the
ISO version, which says something completely
different (and as far as I can tell, erroneous).
Notice that ISO-646 is missing the all important
"top line" requirement, the thing that an
implementor and a user of form-feed both expect to
be the rule.

Post by Dylan O'Donnell
Note that this doesn't specify the position _on_
that line.

It didn't have to, as per my previous note. Back in
the day, there was _no such thing_ as positioning a
line printer at a particular character location, it
treated the line as a single printable object.

Thus, your calling that definition "less precise" is
a mistake. It is of the exactly correct precision,
that being the precesion which was achievable in the
then-current text output hardware.

xanthian.

And Boudewijn, I've _written_ (as a member of a
large team, not singlehandedly) _several_ [three,
originally, but one forked/cloned itself, so now
there are perhaps seven of them altogether]
international standards.

Fawning worship for standards is entirely an
inappropriate attitude, and dangerous as well. They
are just as capable of containing errors as are any
other documents produced by human effort, so no sane
person accepts them uncritically.

RFCs, too, are typically rife with typos.

In this case, the contrast between the two form-feed
definitions Dylan provided just highlights the error
I saw in ISO-646, making me feel a lot better about
my memory of events.

Since the definition of form-feed in ISO-646 was
unimplementable (or more precisely, unusable if
implemented as the standard claimed it should be),
it got ignored. That "won't work, doesn't get used"
happens to _lots_ of " standards and scraps of
standards", which is why more recent standards tend
to be required to come with a reference
implementation before they get blessed as standards
by the parent standards body.

[Richard Bos]

Post by Jukka Lahtinen

Post by Kent Paul Dolan

Post by Jonathan Carter
SPACE (How do you insert a form feed in vim?)

It doesn't work very well, though, since many browser based
news accesses ignore form feeds when rendering articles for

Then those systems are broken. Formfeed is a standard supposed to work in
news, and any broken browser-based system should be fixed.

Yeah,

but

formfeeds

are

broken

themselves,

too.

Richard

[Dylan O'Donnell]

Post by Dylan O'Donnell

Post by Jukka Lahtinen
Then those systems are broken. Formfeed is a standard supposed to work in
news, and any broken browser-based system should be fixed.

Yeah,
but
formfeeds
are
broken
themselves,
too.

What is the difference between this and someone deciding to use a
couple of hundred lines of spoiler space? Anything can be broken if
someone decides to play silly buggers with it.

[Richard Bos]

Post by Dylan O'Donnell

Post by Dylan O'Donnell

Post by Jukka Lahtinen
Then those systems are broken. Formfeed is a standard supposed to work in
news, and any broken browser-based system should be fixed.

Yeah,
but
formfeeds
are
broken
themselves,
too.

What is the difference between this and someone deciding to use a
couple of hundred lines of spoiler space? Anything can be broken if
someone decides to play silly buggers with it.

One of the ways in which some newsreaders process formfeeds is by
putting up a dialog box. You can't scroll past dialog boxes.

Richard

[Ohle Claussen]

Hi!

Post by Richard Bos

Post by Dylan O'Donnell

Post by Dylan O'Donnell

Post by Jukka Lahtinen
Then those systems are broken. Formfeed is a standard supposed to work in
news, and any broken browser-based system should be fixed.

Yeah,
but
formfeeds

^^^^^^^^^

Post by Richard Bos

Post by Dylan O'Donnell

Post by Dylan O'Donnell
are
broken
themselves,

^^^^^^^^^^

Post by Richard Bos

Post by Dylan O'Donnell

Post by Dylan O'Donnell
too.

What is the difference between this and someone deciding to use a
couple of hundred lines of spoiler space? Anything can be broken if
someone decides to play silly buggers with it.

One of the ways in which some newsreaders process formfeeds is by
putting up a dialog box. You can't scroll past dialog boxes.

I've marked relevant parts of your own post for you. Opening a dialog
box means that the newsreader is broken, not the formfeed. Such a
behaviour is not compatible with *any* definition or proposed treatment
of the formfeed mentioned so far.

Greetings,
Ohle

[David Damerell]

[Multiple ^L can be awkward]

Post by Richard Bos

Post by Dylan O'Donnell
What is the difference between this and someone deciding to use a
couple of hundred lines of spoiler space? Anything can be broken if
someone decides to play silly buggers with it.

One of the ways in which some newsreaders process formfeeds is by
putting up a dialog box. You can't scroll past dialog boxes.

Yes, some broken newsreaders do not handle certain properties of article
bodies gracefully. What's your point?

[Richard Bos]

Post by David Damerell
[Multiple ^L can be awkward]

Post by Richard Bos

Post by Dylan O'Donnell
What is the difference between this and someone deciding to use a
couple of hundred lines of spoiler space? Anything can be broken if
someone decides to play silly buggers with it.

One of the ways in which some newsreaders process formfeeds is by
putting up a dialog box. You can't scroll past dialog boxes.

Yes, some broken newsreaders do not handle certain properties of article
bodies gracefully. What's your point?

That non-text "features" in a text-only medium like Usenet are
inherently broken because, being out-of-band, they have several
seemingly natural interpretations.

Richard

[David Damerell]

Post by Richard Bos

Post by David Damerell

Post by Richard Bos
One of the ways in which some newsreaders process formfeeds is by
putting up a dialog box. You can't scroll past dialog boxes.

Yes, some broken newsreaders do not handle certain properties of article
bodies gracefully. What's your point?

That non-text "features" in a text-only medium like Usenet are
inherently broken because, being out-of-band, they have several
seemingly natural interpretations.

I don't see that as a problem. Good newsreaders will pick whichever
representation is most appropriate. Bad newsreaders will pick something
clumsy and awkward, but bad newsreaders will be clumsy and awkward whether
or not they have any help from ^L.