gt; > > > > the rest get displayed using the proper characters (where
> > > available
> > > >> > in
> > > >> > > > the
> > > >> > > > > font).
> > > >> &g
> utility.
> > >> > > > >
> > >> > > > >
> > >> > > > > On Sun, Feb 5, 2012 at 1:14 PM, bill lam >
> > >> > wrote:
> > >> > > > >
> > >> > > > > > behavi
results.
> >> > > > > >
> >> > > > > > compare the outputs of _16{.a. with u: _16{.a.
> >> > > > > >
> >> > > > > > the first contains illegal utf8 characters which can be
> checked
> >>
> >
>> > > > > > Вск, 05 Фев 2012, Fraser Jackson писал(а):
>> > > > > > > Why should I have to use u: to box elements of a. ? Seems an
>> > > > > > unnecessary
>> > > > > &g
contains illegal utf8 characters which can be checked
>> by
>> > > > > > isutf8 _16{.a.
>> > > > > >
>> > > > > > What would you expect from gtkide to display those illegal
>> > characters?
>> > > > > >
>
has all the problems.
> That
> > > > > > suggests
> > > > > > > some problems are associated with the unicode treatment of
> > control
> > > > > > > characters.
> > > > > > >
> > > > > > > Even
"The utility that formats data for display is octal_j_."
http://jsoftware.com/pipermail/programming/2012-February/027016.html
--
Raul
2012/2/6 Brian Schott :
> Chris,
>
> I don't see how your verb octal_j_ relates to Fraser's issue. Could
> you explain that please? Or did Fraser's post just pr
Chris,
I don't see how your verb octal_j_ relates to Fraser's issue. Could
you explain that please? Or did Fraser's post just prompt your
thoughts on a related issue?
Thanks,
On Mon, Feb 6, 2012 at 3:47 AM, chris burke wrote:
> Right, thanks. This is a better definition:
>
> octal_j_=: 3 : 0
>
t and second line are also
> irregular.When
> > > the
> > > > > > configure specifies a mono spaced font in gtkide we should surely
> > > expect
> > > > > > characters within the ascii set will be treated as atoms and
> > > assigned
; > > > characters within the ascii set will be treated as atoms and
> > assigned a
> > > > > single space.
> > > > >
> > > > > I am really seeking that members of the alphabet ( and hence any
> > literal
> > > > &
at treatment is clearly separated from their role in controlling
> the
> > > > nature of the display. That seems to have been achieved in J602.
> > > >
> > > > The treatment of type 131072 - unicode obviously involves a host of
> other
> > > > issues
In
https://groups.google.com/forum/?hl=is&fromgroups#!topic/j-programming/lf5n9bwjxpM
ng staistics
You can see an example of the difficulty of aligning columns in display
when you have chars that are not strictly ascii
It also shows the difference of how the aligning copies between the ng and
GT
er
> > > issues with respect to display and treatment of aoms. However there are
> > a
> > > large number of problems within the narrower framework of atoms within
> > a. or
> > > represented by those characters. Precise, simple and consistent
t; issues with respect to display and treatment of aoms. However there are
> a
> > large number of problems within the narrower framework of atoms within
> a. or
> > represented by those characters. Precise, simple and consistent display
> of
> > those atoms is extremely valu
age -----
> From: "bill lam"
> To:
> Sent: Sunday, February 05, 2012 3:04 PM
> Subject: Re: [Jprogramming] Problems displaying the alphabet in J701gtk and
> J701jhs
>
>
> > It seemes that the characters in the first two rows caused the trouble,
> > the
ved with the gtkide.
Fraser
- Original Message -
From: "bill lam"
To:
Sent: Sunday, February 05, 2012 3:04 PM
Subject: Re: [Jprogramming] Problems displaying the alphabet in J701gtk and
J701jhs
> It seemes that the characters in the first two rows caused the trouble,
&g
It seemes that the characters in the first two rows caused the trouble,
the following display ok in gtkide,
<"0 [ u: 2}. i.16 16
jconsole have no problem in displaying them.
<"0[u: i.16 16
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| | | | | | | | | | | |
It looks better like this
u:&.>0,&.>3 u: 16 16 $a.
2012/2/4 Björn Helgason
>32 16 $;u:&.>0,&.>3 u: 16 16 $a.
>
>
>
>
> ┌┬┐├┼┤└┴
> ┘│─
> !"#$%&'
> ()*+,-./
> 01234567
> 89:;<=>?
> @ABCDEFG
> HIJKLMNO
> PQRSTUVW
> XYZ[\]^_
> `abcdefg
> hijklmno
> pqrstuvw
> xyz{|}~
> € ‚ƒ„…†‡
> ˆ‰Š‹Œ Ž
> ‘
32 16 $;u:&.>0,&.>3 u: 16 16 $a.
┌┬┐├┼┤└┴
┘│─
!"#$%&'
()*+,-./
01234567
89:;<=>?
@ABCDEFG
HIJKLMNO
PQRSTUVW
XYZ[\]^_
`abcdefg
hijklmno
pqrstuvw
xyz{|}~
¡¢£¤¥¦§
¨©ª«¬®¯
°±²³´µ¶·
¸¹º»¼½¾¿
ÀÁÂÃÄÅÆÇ
ÈÉÊËÌÍÎÏ
ÐÑÒÓÔÕÖ×
ØÙÚÛÜÝÞß
àáâãäåæç
èéêëì
In JHS
16 16$;u:&.>0,&.>3 u: 16 16 $a.
┌┬┐├┼┤└┴
┘│─
!"#$%&'
()*+,-./
01234567
89:;<=>?
@ABCDEFG
HIJKLMNO
PQRSTUVW
XYZ[\]^_
`abcdefg
hijklmno
pqrstuvw
xyz{|}~
2012/2/4 Fraser Jackson
> In J701jhs the display character choice destroys the elegance of the
> boxing
> and LF
In J602 the boxed characters in the alphabet display well with each
character in the current font appropriately boxed. Effects of the LF, TAB
and CR characters are constrained by the boxing and they display as blanks
as they would in a session though their location effects are not displayed.
Ma
21 matches
Mail list logo
