[rfk-dev] Request For Comment: robotfindskitten standard

Sat Jun 13 18:32:58 PDT 2009

Quoting Tim Allen:
> On Thu, Jun 11, 2009 at 09:43:55AM -0700, Peter A. H. Peterson wrote:
> > This really only applies for the beginning of sentences, etc., since
> > ordinary common nouns aren't capitalized otherwise. Making the rule
> > for the beginning of the sentence just helps to highlight the
> > difference which may not otherwise be obvious to English readers. If
>                                                    ^^^^^^^
> I'm guessing you mean 'non-English speaking' here.

Actually, I meant English speaking, because English speakers (like
myself several places in this document) capitalize robot out of habit.
A sentence starting without a capital letter sticks out to English
readers. (And I assume most Western readers, but I don't know that for
a fact.) What I mean is that if we allowed capitalization at the
beginning of sentences, in most situations readers would not
understand that robot and kitten were special words

> > it were easy to do so, I could imagine printing "robot" in a different
> > typeface, in which case the capitalization at the beginning of the
> > sentence wouldn't really be an issue.
> 
> I think the RFC text should be updated to make this position more
> explicit. Perhaps something like:
> 
>     The entities 'robot' and 'kitten' are likewise not proper nouns
>     because they are not a particular robot or kitten, but rather
>     aspects of the Platonic forces of robot-ness and kitten-ness. This
>     distinction MUST be made in all introductory material, documentation
>     and metadata, although the technique for highlighting the
>     distinction may vary, including but not limited to the use of
>     a distinct typeface, colour, or capitalisation for these terms.
>     Implementations localised into English MUST use the distinctive
>     grammar rules exhibited in the Standard Introductory Text, while
>     other languages SHOULD use similarly distorted grammar.

Well, I made the "different typeface" comment sort of offhand; that's
a strange convention to add to the RFC. But for the record, I think of
it the way bibles use StudlyCaps to talk about THE LORD. My
inclination is to leave it without introducing the alt typeface, etc.
and leave this discussion to the robolmudic scholars.

> > > Does "[heart]" appear over robot, over kitten, or one heart glyph appear
> > > over both?
> > 
> > Good question. I don't think it matters.
> 
> ...or one heart glyph over each, I suppose.
> 
> It's probably worth mentioning that the canonical presentation is...
> whatever it happens to be (I don't happen to have the DOS version handy
> right now) but mentioning that alternate renderings are allowed for
> platform-specific limitations or capabilities (for example, you could
> have one heart glyph over both if you managed to find a vt100-compatible
> terminal that supported both Unicode and extra-wide glyphs, or the "<3"
> rendering I mentioned).

Yeah. I guess two hears (one over each) would be a new addition and I
don't want to suggest features through the RFC. I do think that <3 is
a valid substituion in the face of a dearth of fancy characters, and
that a wide heart would be OK as well. I will find out what the DOS or
POSIX version does for the specific standard though.

> Upon further reflection, it occurred to me that an even more
> impressively ostentatious reference would be the keyword values for the
> '<color>' type in SVG 1.1, since that's an actual published W3C
> recommendation rather than a working draft:
> ...
> As for character set, the official Unicode encoding for the IBM
> control-character graphics agrees that U+2665 is the correct glyph to
> render the heart:
> 
>     http://www.unicode.org/Public/MAPPINGS/VENDORS/MISC/IBMGRAPH.TXT

Yes. We can settle on the best references once the text is finalized.

> Finding kitten from amongst two items on a 1000x1000 field is a very
> different experience from finding kitten from amongst eight items on
> a 4x4 field.  If the standard is trying to define how to reproduce the
> simulated-Zen of the original RFK implementation, I think it should
> mention default field-size and density values, even if particular
> implementations use different values due to technical limitations, or
> because the implementation allows the user to configure them.

I agree, especially since I'm now intending to define a generic
robotfindskitten standard and the more traditional interface standard. 

> > I didn't specify a background color, since terminal background colors
> > are usually the choice of the window manager or terminal app. Forcing
> > the background to be a specific color doesn't seem important as long
> > as the items and robot are all visible against it.
> 
> That's a technical limitation of the POSIX implementation, but I would
> imagine the original DOS implementation always used a black background,
> and other implementations are likely to have to choose a specific
> background colour, so the spec might as well suggest one.

I think this is a platform-independent issue. On Palm, for example, a "black"
background would be harder to see than a "white" background. 

And for the record, I'm basing the standard on both DOS and POSIX,
since some of the features were added to POSIX (e.g. fastwalk,
external NKI, resizing, etc.) and it's far more accessible as a
reference. (And it's been feature-stable for a long time.)

Anyway, in the same way that leonardr said that he would have built
"kitten insurance" into the DOS port had he thought to/been able to,
my guess is the default "background color" in DOS was black because
that's kind of the default for console programs. Besides, the DOS
"window" is kind of the stepchild of a real terminal, where users can
generally choose whether they want white on black or black on white
(and resize them). I hate it when console programs override this for
no discernable reason... so I'm still inclined to not specify a
background color.

> > Hmm... that's interesting. On the one hand, the spec is trying to both
> > codify the "standard implementation" and also leave room for variants.
> > So if there should be a standard density, I'd say it should be
> > whatever the DOS or POSIX density is for an 80x25 screen and whatever
> > the default number of NKI was. 
> 
> I agree - what is that density?

I'll figure this out.

> I'd say the overarching, ultimate concern is that every item in the
> field be readily visible, and it's up to the author of each
> implementation to guarantee that is the case. Depending on the platform,
> available approaches might include choosing a specific font, choosing
> a 'safe' subset of glyphs, choosing a 'safe' subset of colours, or
> perhaps simply black-listing pathological glyph/colour pairs.
> 
> For example, in the J2ME port I chose to avoid "." and "`", but
> I suspect if I'd limited my colour palette to simply bright red, bright
> green and bright yellow, I could have kept them.

Absolutely right.

Peter

-- 
Peter A. H. Peterson, technician and musician.
 ---=[ http://tastytronic.net/~pedro/ ]=--- 