Re: Square brackets
On Mon, 8 Oct 2001 18:32:05 -0700 (PDT), Kenneth Whistler wrote:
This would definitely not work. The problem is that while the CJK
left/right corner brackets are clearly bracketing punctuation, you
have to contend with their other properties as CJK punctuation. Most
systems will default them to wide behavior, giving them spacing
properties appropriate for CJK text, but inappropriate for the kind
of bracketing you would expect in typical alphabetic text.
I also have been looking for other brackets besides the
basic ()[]{}. C++ has demonstrated with its terrible syntax that
overloading operators such as to be used as punctuation and punctuation
such as , to be used as operators only leads to confusion and
difficulties parsing. More parenthetical symbols are needed!
CJK has many, but as you point out, they will not be very useful
as they will not space properly.
I think the arithmetic set of symbols should be extended with more parenthesis.
Re: [OT] Roman numeral arithmetic (was: Re: [lojban] (from lojban-beginners) pi'e)
On Sat, 22 Sep 2001 18:46:36 EDT, [EMAIL PROTECTED] wrote: I would be fascinated to see some sort of evidence that addition and subtraction is easier in Roman numerals than in Hindu-Arabic (European) numerals. I + I = II X + X = XX X + X + X = XXX C + X = CX CX - X = C For these carefully chosen examples, sure, but what about: III + IX = XII XXIV + XXVII = LI C - I = XCIX The subtractive form of roman numerals was used for stone carving. The normal form was to use only MCXI and arithmetic was done like an abacus. It took less learning to do arithmetic since it was counting beads in decimal notation.
Re: XML Blueberry Requirements
On Thu, 21 Jun 2001 09:40:22 -0400, Elliotte Rusty Harold wrote: At 9:35 PM +0100 6/20/01, [EMAIL PROTECTED] wrote: | In addition, XML 1.0 attempts to adapt to the line-end conventions of | various modern operating systems, but discriminates against the | convention used on IBM and IBM-compatible mainframes. XML 1.0 documents | generated on mainframes must either violate the local line-end | conventions, or employ otherwise unnecessary translation phases before | and after XML parsing and generation. | The concern with respect to IBM is that one of the world's largest corporations, with thousands of patents, legions of programmers, billions of dollars in revenue, and resources pouring out of every orifice is somehow unable to handle documents where lines end with carriage returns and line feeds, as documents do on every non-IBM system on the planet. Unix and Apple do not use cr-lf! Most pre-ASCII computers were unit-record and did not use CR-LF. The problem is real for any operating system not using CR-LF. Your antique attitude is showing! I have seem IBM do dumb things to avoid looking monopolistic since the decree. Most of the world is using that crappy Windows partly because of this attitude. The bigger danger is from Microsoft. They probably would not even ask for a a change. They would do what ever they want and try to make it the standard by fiat. [...]
Re: Word, Asian characters, and Arial Unicode
On Sun, 6 May 2001 19:22:38 -0400 (EDT), Thomas Chan wrote: #On Sun, 6 May 2001, David J. Perry wrote: # # Word 2000 (under Win98) insists on using Arial Unicode MS whenever you # insert a character in the CJK Punctuation range. There are some characters # here that might be useful in non-CJK situations, such as the double # brackets. I have made a font with these characters but Word will not let me # #By double brackets, do you mean U+300A and U+300B (LEFT/RIGHT DOUBLE #ANGLE BRACKET)? Those are used to delimit titles of books and articles. #What kind of usage do you have in mind that U+00AB and U+00BB #(LEFT/RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK) or U+226A and U+226B #(MUCH LESS/GREATER-THAN) couldn't be used? # #Not all of the symbols in that block have analogues elsewhere, though--I'm #not sure what you can do about that. # I too was hoping to use these punctuation marks in the future. Current programming languages (C++ and others) have violated what I consider good language design by overloading the same glyphs for totally different uses. The most obvious is for brackets and operators! There is definitely a need for more types of brackets and other punctuation. Some can be gotten from the arithmetic set but the only extra brackets I see are in the CJK range.
Re: Characters used in programming languages (was: Re: Word, Asian characters, ...)
On Mon, 7 May 2001 11:35:40 EDT, [EMAIL PROTECTED] wrote:
#In a message dated 2001-05-07 6:55:01 Pacific Daylight Time,
#[EMAIL PROTECTED] writes:
#
# Current programming languages (C++ and others) have violated
# what I consider good language design by overloading the same
# glyphs for totally different uses.
# The most obvious is for brackets and operators!
#
#C++ was developed in the early 1980s, and was based on C, which in turn was
#developed around 1970. At this time, it had only been a few years since
#7-bit ASCII had been invented, let alone standardized. C was one of the
#first languages to take full, or nearly full, advantage of 7-bit ASCII.
#
#In subsequent years, continued limitations in ASCII conformance forced C to
#add the trigraph hack, in which sequences beginning with ?? replaced some
#of the less frequently available ASCII characters. For example, ?? and
#?? stood for the curly brackets { and }, and ??' stood for ^. Trigraphs
#are still supported in the most modern C and C++ compilers, regardless of the
#platform's character set support, and you have to backslash-escape one of the
#question marks in a literal string that contains ?? if you don't want any
#surprises.
#
Yes, I know why it is the mess it is.
#Any programming language that wants to avail itself of the rich set of
#punctuation, brackets, and other symbols found in Unicode must have at least
#the following features:
#
#1. Commonly used symbols *must* be directly available on virtually all
#Latin-script keyboards, not just by typing convoluted dead-key or
#Alt-sequences.
#
We need more shift and shift lock keys so that more than ASCII
can be done from a keyboard. Typing /U is also not acceptable.
My program editor already uses Ctrl-Shift, Alt-Shift and Ctrl-Alt to get
more key combinations on all the other keys but using two shift keys is awkward for
anything used frequently.
We need Unicode keyboards.
#2. Symbols must be easy to distinguish from each other, not just in a
#professionally designed font but in ordinary handwriting, to prevent
#confusion.
Anything is better than looking at a and asking,
Is this a less than or is this an open template bracket.
#
#-Doug Ewell
# Fullerton, California
#
