🚀 go-pugleaf

In article <343@ur-tut.UUCP> tuba@ur-tut.UUCP writes:
>What's all this business about linkers that only support monofont
>symbols?  When I name a variable "counter" in 10 point Helvetica,
>the last thing I mean is "counter" in 14 point Courier.  Linkers
>that fold fonts into a single stripped typewriter-like system
>font should be abolished!  That's like not having font sensitivity
>in the first place.  If this is what our programming environments
>are going to be like, we might as well all go back to 8-bit ASCII!

But are you *WRONG* if you think that is a joke. Tuba is RIGHT
RIGHT RIGHT, except for missing out the other essential attributes that we
will need if we are going to get an environment fit for the 1960's, let
alone the late 70's or even 80's. What about colour? I want to be able to grep
for all the 10 point helvetica non-alphabetic strings in red, because that
is the way that my application displays error messages.

I'm concerned about orientation too - but the reasons for that are secret.

Is ``italicness' an attribute or a separate font?

What if I have a private set of attributes that I want characters to have
that don't fit into the codeset currently in use? What is happening about
a design of a regular way of redefining a ``character'' that allows
me simply to change the definition of what a character is, at the head
of my program, that will still allow all the other stuff (ctype, strcmp)
etc. to work, yet allow me to diddle with attributes as I see fit? Get
your thinking caps on, Netland, and see if you can come up with something.
If you don't think that this is important, go read net.dead-sea-scrolls
or something.
-- 
Mike Banahan, Technical Director, The Instruction Set Ltd.
mcvax!ukc!inset!mikeb

>Is ``italicness' an attribute or a separate font?
>
>What if I have a private set of attributes that I want characters to have
>that don't fit into the codeset currently in use? What is happening about
>a design of a regular way of redefining a ``character'' that allows
>me simply to change the definition of what a character is, at the head
>of my program, that will still allow all the other stuff (ctype, strcmp)
>etc. to work, yet allow me to diddle with attributes as I see fit? Get
>your thinking caps on, Netland, and see if you can come up with something.
>If you don't think that this is important, go read net.dead-sea-scrolls
>or something.


Big problems though  --  grep will have to be able to read and interpret
these redefinitions so that it knows what is what inside the program. At
one point I was thinking of suggesting that the database of printer
characteristics should include how to generate bit images if required. The
program could then have a preprocessor command (#CHAR_DEF ?) which gave
the information required for the pattern to be used (ie you could specify
the bit pattern of a certain character, such as the Swedish symbol of the
sun and say :-


#CHAR_DEF $ '100010101
	     ....
	     ....

		     '

etc.)


This however is not going to make greping for such characters particularly
easy. I still feel that the problem must be with the Terminals and
editors that we are using. If we can generate any particular combination
of colour and font while we are typing (and change in the middle of
a sentence) then pattern matching will be that much easier, but very few
of us can. We don't all have full colour graphics workstations available to
us all the time. 

If we want to be able to say :-

	grep -font=ROMAN -pica=12 -colour=RED "Syntax error on line....

then grep and programs like it are going to have to be given the ability to
know the context of all the text they are examining. This in turn means some
sort of standard, not just for programs but for Word and Text procressors,
editors, printers, linkers, compilers, pretty printers .....
hoo boy (to coin a phrase). Perhaps this really is a sign 
that our current operating systems are on the way out, we need
something better.

Even then different operating systems will have different 'standards' that
will have to be translated (if possible  --  pass the straight jacket please)
when documents are passed. I think I'm going to take up water colours.


Back in the realms of the living dead (have you ever met Stephen Muir
from Lancaster ?) it should be possible to define extensions to the 
preprocessor to allow character definitions at the head of programs
and to give programs such as grep some form of context sensitivity.

Craig ( I think).

-- 
UUCP:	 ...!seismo!mcvax!ukc!dcl-cs!craig| Post: University of Lancaster,
DARPA:	 craig%lancs.comp@ucl-cs 	  |	  Department of Computing,
JANET:	 craig@uk.ac.lancs.comp		  |	  Bailrigg, Lancaster, UK.
Phone:	 +44 524 65201 Ext. 4146   	  |	  LA1 4YR
Project: Cosmos Distributed Operating Systems Research

In article <832@inset.UUCP> mikeb@inset.UUCP (Mike Banahan) writes:
>In article <343@ur-tut.UUCP> tuba@ur-tut.UUCP writes:
>>What's all this business about linkers that only support monofont
>>symbols?  When I name a variable "counter" in 10 point Helvetica,
>>the last thing I mean is "counter" in 14 point Courier.  Linkers

I hope you don't ever do that, but I agree with the sentiment
which follows.

>>that fold fonts into a single stripped typewriter-like system
>>font should be abolished!  That's like not having font sensitivity

>I'm concerned about orientation too - but the reasons for that are secret.

are you showing off? :-) if so, what?
>
>Is ``italicness' an attribute or a separate font?

Italic is a separate font (some characters have different shapes,
eg 'a' and 'g').  Slant is an attribute.  One of the things Apple got
wrong with the Mac was to call slanted fonts Italic.  This breaks the
'WYSIWYG' correspondence between MacWrite and the LaserWriter.


>
>What if I have a private set of attributes that I want characters to have
>that don't fit into the codeset currently in use? What is happening about
>a design of a regular way of redefining a ``character'' that allows
>me simply to change the definition of what a character is, at the head
>of my program, that will still allow all the other stuff (ctype, strcmp)
>etc. to work, yet allow me to diddle with attributes as I see fit? Get
>your thinking caps on, Netland, and see if you can come up with something.
>If you don't think that this is important, go read net.dead-sea-scrolls
>or something.
>-- 
Take a look at the Tioga system at PARC, or the work done by
the Xerox Star people.  I think the basic message is that the Unix
approach to character strings is inadequate for *any* natural language.
	Tony



-- 
---------------------------------------------------------------------------
Tony Williams					|Informatics Division
UK JANET:	asw@uk.ac.rl.vd			|Rutherford Appleton Lab
Usenet:		{... | mcvax}!ukc!rlvd!asw	|Chilton, Didcot
ARPAnet:	asw%rl.vd@ucl-cs.arpa		|Oxon OX11 0QX, UK

In article <970@dcl-cs.UUCP> craig@comp.lancs.ac.uk (Craig Wylie) writes:
>... is not going to make greping for such characters particularly
>easy. I still feel that the problem must be with the Terminals and
>editors that we are using. If we can generate any particular combination
>of colour and font while we are typing (and change in the middle of
>a sentence) then pattern matching will be that much easier, but very few
>of us can. We don't all have full colour graphics workstations available to
>us all the time. 
>
>If we want to be able to say :-
>
>	grep -font=ROMAN -pica=12 -colour=RED "Syntax error on line....
>
>then grep and programs like it are going to have to be given the ability to
>know the context of all the text they are examining. This in turn means some
>sort of standard, not just for programs but for Word and Text procressors,
>editors, printers, linkers, compilers, pretty printers .....
>hoo boy (to coin a phrase). Perhaps this really is a sign 
>that our current operating systems are on the way out, we need
>something better.

Got it in one! Exactly. It is going to be necessary to support a variety
of attributed characters for different purposes, and to have translators
which can convert from one codeset into another, perhaps stripping out
information.

For example, if the middle-level description of one of these super-chars
(which I chose to call a `codon' in my paper on this idea) is like this

struct codon{
	unsigned font: 4;
	unsigned point: 6;
	char encoding;
};

Then it can be `transformed' in a number of ways. A simple one would be for
the transforming program to throw away the font and point stuff altogether
and just spit out 8 bit chars.
Then grep would work just fine. Another approach would be to convert it into
troff-like input, so that given the above form of a Roman 12pt letter A,
the transformer would read it and output something like

	\f(RO\s12A
which even the current grep could be told to look for. Of course, if a new
grep were written which understood those codons directly, then the transformer
would be unnecessary.

>
>Even then different operating systems will have different 'standards' that
>will have to be translated (if possible  --  pass the straight jacket please)
>when documents are passed. I think I'm going to take up water colours.
>
>

It will be a fact of life that we have to be prepared to transform data
streams on input to and output from our systems. Anyone unlucky enough
to work  in a mixed UNIX and EBCDIC environment knows that already; we
have this problem all the time because our telex machine is hooked up to
UNIX. Surprise surprise, the telex character set and ASCII don't match.

The truth may be painful folks, but ingoring it has never made it go away
yet!
-- 
Mike Banahan, Technical Director, The Instruction Set Ltd.
mcvax!ukc!inset!mikeb

Referring to linkers and alike not being able to recognize symbols
written with different fonts, you do have a point there... If we
haven't done it already, I suggest that we differ between characters
used for representation of natural language text, and those used
within computer software to denote symbols, filenames and alike.
Software dealing with all the properties of national characters will
probably be huge, and I wouldn't like to include it in my operating
system just to get my file listings sorted "alphabetically". Now I
refer primarily to traditional, "low-level" operating systems. In a
window-oriented, database, user-friendly, <whatever> system things
might be different, though.

What I'm saying is that ASCII95 will probably have to stay in some
way or another, together with whatever Kanji Word Processor Standard
will be created. Sorry if this has been discussed and/or agreed upon
already.
-- 
Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden
Phone: +46 18 183170
UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)

   In article <343@ur-tut.UUCP> tuba@ur-tut.UUCP writes:
>What's all this business about linkers that only support monofont
>symbols?  When I name a variable "counter" in 10 point Helvetica,
>the last thing I mean is "counter" in 14 point Courier.  Linkers ...

   In article <832@inset.UUCP>, mikeb@inset.UUCP (Mike Banahan) adds,
> But are you *WRONG* if you think that is a joke. Tuba is RIGHT
> RIGHT RIGHT, except for missing out the other essential attributes that we
> will need if we are going to get an environment fit for the 1960's, let
> alone the late 70's or even 80's. What about colour? I want to be able to grep
> for all the 10 point helvetica non-alphabetic strings in red, because that
> is the way that my application displays error messages.

   NO!!!!  I must disagree.  As I will demonstrate below, you are confusing
two different aspects of a document (or pieces thereof): the `intrinsic'
content, and its formatting.  The boundary between the two may be a little
fuzzy, but things like the font, point size, and color are most definitely
formatting information, not intrinsic content.

   Before giving my criterion for distinguishing the two aspects, let's 
take the idea proposed in the quoted articles a little further, to truly
silly extremes.  Now, on dumb terminals, you can't adjust the spacing
between letters in a variable name to arbitrary accuracy; you can only
insert `hard' (i.e. required) spaces.  But in the brave new world of modern
laser printers, you could insert, say, a 1 pt space between the first and
the third letters.  Or even a 0.1 pt space, on a laser typesetter.  
Does that mean we need a new character to indicate the spacing?  Or that
each character should now be preceeded by a *floating point* number
indicating the amount of spacing preceeding it?  Do you truly believe
that `InformUser' with 0.1 pts of space between the `r' and the `m' means
something different from plain old `InformUser'?  Or how about the attributes
of the surrounding text, say the inter-line spacing?  Isn't that something
one ought to be able to grep in our utopian operating system?  It's clear
that such an approach quickly sucks you in to a specific WYSIWYG
representation of text, and is completely inadequate for anything else. 
Embedding this information in every character would also result in a
grossly inefficient encoding; space may be cheap on modern computers,
but it isn't THAT cheap. [For those souls don't know what a printer's
point is: there are ~72/inch, or ~28/mm, so that 0.1 pts of anything are
virtually invisible, and in any event unprintable on a printer with only
300 dots/inch resolution.]

   And consider for a minute the specific proposals made by the two
authors quoted above.  What *exactly* does `14-point' Courier mean,
anyway?  Does it mean `somewhere between 13.75 and 14.02-point Courier,
as suits my laser printer' or does it mean `14.00-point Courier'?
What does `Courier' mean?  Does it mean the IBM version?  Or the
Little Font Company's version?  Does a variable name no longer mean
the same thing if it isn't *exactly* the same font?  And if it still
*is* the same variable when the font changes, *how* much change can
occur before the variable name changes in meaning?  Color, likewise,
depends very much on the output device.  It's all very nice to grep
for things in red sitting in front of my shiny new Sun-3, but what
does that mean when I'm back in front of my neighbor's Sun-2, which
is black-and-white?  Does `red' still mean red (i.e. an invisible
attribute), or is it subverted into `black'?  And of course, we
could argue about shades of red until the sun comes up.

   What do all these attributes have in common?  They vary contiuously,
they depend on detailed properties of the output device, and (in spite
of the claim by tuba@ur-tut) they *modify* rather than *create* information.
Furthermore, that modification is often context-sensitive.  Conversely,
removing these additional attributes may *degrade* but should not *remove*
information entirely.  If you had to read a typeset document at your
terminal, you might lose some of the nuances, but the meaning (if any...)
will not disappear entirely.  If your laser-printer were missing `14-point
Helvetica', and were forced to substitute `12-point Helvetica' instead,
surely you do not claim you will lose as much information as you would
if, say, your line-printer were missing the letters a-m, and were forced
to substitute the letters n-z instead...

   In contrast to a possible disagreement over the meaning of `14-point
Courier', we will all agree on what an English `a' is.  It doesn't 
matter how it's represented (printed, hand-written, ASCII, EBCDIC, &c.),
it corresponds to the same abstract object.  Indeed (unlike the notion
of a specific font), `a' already *is* in some ways an abstract object.

   The basic criterion I propose for distinguishing `intrinsic' aspects of
a document from its formatting is thus as follows: those aspects of a
document which change discretely, have abstract properties independent
of an output device, and contain `inherent information', should be
considered the `intrinsic properties' of a document.  These, and only
these, should be embedded in the character codes.  Everything else is
formatting information, which may be (and will be, in reasonable systems)
supplied in a variety of manners (via WYSIWIG editors, sophisticated
formatters, &c.), but should *NOT* be embedded in the character codes.
These `intrinsic properties' include (of course) the abstract character
represented, and *perhaps* the language, but not much else.

   All of this may sound rather formal and dry.  Here are a few examples
to play with.  Ask yourself: is "counter" in 14-point Helvetica really
completely different from "counter" in 10-point Helvetica?  How about
"counter" in 14.00-point Helvetica vs "counter" in 13.75-point Helvetica?
13.99 point Helvetica?  How about "counter" in red vs. "counter" in
green, seen on a black-and-white display?

   Now consider examples that are `intrinsically' different: does "counter"
mean something different from "aardvark"?  Is a "counter" different from
a "count"?  And here's a more subtle example to mull over: capitalization
is NOT a formatting attribute.  It conveys inherent meaning: an "Afghan"
is a person from Afghanistan, while an "afghan" is a sweater.  They are
different words.  My favorite examples along these lines (flames to 
/dev/null, please) are those where capitalizing a word turns it into
its antonym (or nearly so): e.g. "catholic" vs. "Catholic".

   To summarize: many of the visual aspects of documents produced
via modern printing devices are determined by formatting.  Formatting
information does not belong in the character set encoding.  Period.

                                       David A. Kosower
                                       kosower@harvard.Harvard.Edu.Arpa

In article <882@kuling.UUCP> andersa@kuling.UUCP (Anders Andersson)
> Anders Andersson, Dept. of Computer Systems, Uppsala University, Sweden
> Phone: +46 18 183170
> UUCP: andersa@kuling.UUCP (...!{seismo,mcvax}!enea!kuling!andersa)
> writes:
>Software dealing with all the properties of national characters will
>probably be huge, and I wouldn't like to include it in my operating
>system just to get my file listings sorted "alphabetically".

This is exactly my point.  And was the point of my first, :-) qualified,
posting.  It's silly to support the constructs for twenty major world
languages within utilities and environments that don't need them.  Unix's
human interfaces are text-oriented.  Programmers and users create and
manipulate text.  Word processing applications and such need multiple fonts
and native character sets.  Programming languages don't.

The question is how to integrate the two environments with maximal ease of
use and minimal overhead.  Up to now, most of what has been proposed in this
newsgroup could be achieved by a a document processing package and a few
conversion utilities.  This just doesn't justify major mods to Unix and
horrible space and time overhead at runtime.  I'd like to see integrations
proposed which are so worthwhile they do justify it.  I suspect a good way
to generate such proposals is to ask not what Unix can do for
internationalism, but what internationalism can do for Unix.

It may already be to late for clear-cut distinctions. My file names on my
Macintosh already have accents in them, and my Pascal programs at Universite
de Montreal have variable names with accents (which are simply folded on the
corresponding unaccented letter, which would not work for all languages).
Given ISO Latin 1, doing this folding, or even defining a proper collating
sequence is essentially trivial (a simple indexation in a language dependant
table - none needed for English).

The advent of cheap typography and high-resolution bit-mapped displays means
that it is becomming customary to see programs where keywords appear in
bold on the screen (e.g.  MacPascal); typographic conventions for displaying
program and emphasize their structure may involve displaying comments in
italic, or strings in a "typewriter" font.  In such a case delimiters become
superfluous.  But I can see a lot of resistance to their removal, e.g. we
still use begin-end pairs even though indentation alone provides sufficient
clues to establish the block structure.

Similarily, if I remember properly, the Occam language manual distinguishes
terminals from non-terminals in syntax specifications by using colour.

I guess the point I'm trying to make is that there is indeed information in
the font, style variation and colour/grey scale used. But then even 16bits are
not enough, so keeping it in every char. is not a sensible idea.
-- 

Jean-Francois Lamy              
Department of Computer Science, University of Toronto,         
Departement d'informatique et de recherche operationnelle,  U. de Montreal.

CSNet: lamy@toronto.csnet  UUCP: {utzoo,ihnp4,decwrl,uw-beaver}!utcsri!utai!lamy
EAN: lamy@iro.udem.cdn     ARPA: lamy%toronto.csnet@CSNET-RELAY.arpa

[You choke over your food --More--]

> >Is ``italicness' an attribute or a separate font?
> 
> Italic is a separate font (some characters have different shapes,
> eg 'a' and 'g').  Slant is an attribute.  One of the things Apple got
> wrong with the Mac was to call slanted fonts Italic.  This breaks the
> 'WYSIWYG' correspondence between MacWrite and the LaserWriter.

This oversimplifies.  Italic fonts are designed to harmonize with the
corresponding Roman fonts.  Many of the letterforms differ, but you can
usually find some salient similarities.  On the other hand, while
slanted fonts can be made by just shearing unslanted fonts, they
usually look better with a few alterations afterwards.
-- 
Col. G. L. Sicherman
UU: ...{rocksvax|decvax}!sunybcs!colonel
CS: colonel@buffalo-cs
BI: csdsicher@sunyabva