Complete font for J 
Author Message
 Complete font for J

Continuing the search for a complete (with accents and boxes) font for J we
have developed, a friend of mine and myself, a font COURIER_NEW_NORMAL
which keeps the Windows font layout and draw the boxes only using 7 boxing
characters. But the characters look shifted to the right, close to the box
vertical line; this is not always satisfactory.

Another solution is to replace two of the existing characters of the
Windows layout by boxing characters. We do not want to touch to the
characters defined in the ISO 8859-1 standard (160 to 255) so we want to
use a pair of characters between 128 and 159.

We would like to know which pair to use: 130-132, 134-135, 136-152 or
139-155.

Could the people using J Windows and needing accented characters let me
know what is the pair(s) which could be droped; remember that it is for
applicatons under J and not for full typography.

Thanks

Alain
Avenue du Marathon, 6                     Ecology, Environment
B1348 Louvain-la-Neuve                    Bio & Agro-climatology
BELGIUM                                   Data processing
tel: (belgium)-10-45 11 92



Fri, 16 Oct 1998 03:00:00 GMT  
 Complete font for J


Alain Delmotte writes on Monday, April 29:

Quote:
> Continuing the search for a complete (with accents and boxes) font for J we
> have developed, a friend of mine and myself, a font COURIER_NEW_NORMAL
> which keeps the Windows font layout and draw the boxes only using 7 boxing
> characters. But the characters look shifted to the right, close to the box
> vertical line; this is not always satisfactory. ...

I am missing the point here.  On my versions of Windows (NT 3.51
and 3.1), both the fixed pitch "Terminal" font and the TrueType
"MS Line Draw" fonts have the accented characters and the box
drawing characters, and as far as I know these fonts are freely
available.  I have found either font to give good results both in
J windows, in MS Word windows, in printing, etc.  Do you find
these fonts unsatisfactory for some reason?

Having slain the APL character set monster we should be cautious
about resurrecting the beast by using non-standard characters,
non-standard fonts, etc.



Sat, 17 Oct 1998 03:00:00 GMT  
 Complete font for J




Quote:
>> Continuing the search for a complete (with accents and boxes) font for J we
>> have developed, a friend of mine and myself, a font COURIER_NEW_NORMAL
>> which keeps the Windows font layout and draw the boxes only using 7 boxing
>> characters. But the characters look shifted to the right, close to the box
>> vertical line; this is not always satisfactory. ...

>I am missing the point here.  On my versions of Windows (NT 3.51
>and 3.1), both the fixed pitch "Terminal" font and the TrueType
>"MS Line Draw" fonts have the accented characters and the box
>drawing characters, and as far as I know these fonts are freely
>available.  I have found either font to give good results both in
>J windows, in MS Word windows, in printing, etc.  Do you find
>these fonts unsatisfactory for some reason?

Yes

Why did ISI create the ISIJ and JFONT fonts?

In MS Line Draw the boxes are not completely closed and Terminal is ugly and
not TrueType and both do not give the accented characters in relation to
keyboard
when you use another keyboard then US (or perhaps UK). Could you accept that
other languages have accents and that people would like to have them straigh
without ALT+0xxx.

They are both satisfactory if you only consider
       *programs development* in *English* (or without accents)
but if you want a satisfactory product (for sale) and/or if you want to
have accented characters they are not satisfactory.

Quote:
>Having slain the APL character set monster we should be cautious
>about resurrecting the beast by using non-standard characters,
>non-standard fonts, etc.

This is an important point, but you sometimes need boxes and accents. If
there is another way of having normal Windows fonts *and* the boxes in
display and printing (the interpreter could take care of that! including
using proportional boxes and still have nice aligned boxes :-) !) there
would be no need to create extra fonts. After all this is part of the
success of the spreadsheets.

APL was considered as respecting other nations by not imposing English
keywords to non English programmers :-) (it was even part of the logo of
the APL92 Conference in Saint Petersbourg).

So my question still holds.

Alain
Avenue du Marathon, 6                     Ecology, Environment
B1348 Louvain-la-Neuve                    Bio & Agro-climatology
BELGIUM                                   Data processing
tel: (belgium)-10-45 11 92



Sun, 18 Oct 1998 03:00:00 GMT  
 Complete font for J


Alain Delmotte writes on Wednesday, May 1:

Quote:
> In MS Line Draw the boxes are not completely closed and Terminal is ugly and
> not TrueType and both do not give the accented characters in relation to
> keyboard
> when you use another keyboard then US (or perhaps UK). Could you accept that
> other languages have accents and that people would like to have them straigh
> without ALT+0xxx.
> They are both satisfactory if you only consider
>        *programs development* in *English* (or without accents)
> but if you want a satisfactory product (for sale) and/or if you want to
> have accented characters they are not satisfactory.

The MS Line Draw font that I have displays box drawing characters
perfectly on the screen and on the printed page, even under a
magnifying glass.  The Terminal font is rather pretty on the screen,
using heavy strokes to form characters that are legible from several
feet away, and again boxes are rendered perfectly.  As far as I
know these fonts came "straight from the box".

Since fonts are part of the Windows product/environment, complaints
about defective and deficient fonts should be directed at a certain
other software company.  It remains the case that if (may be a
big if) you can do all you want (accents, boxes, whatever) with
a standard font that is always better than doing it with a
non-standard one.  Consider this:  why does C, Cobol, fortran, K,
Lisp, Pascal, ... (almost) any programming language one cares to name,
not concern itself with fonts?  And would our concerning ourselves
with fonts give us a significant advantage?



Mon, 19 Oct 1998 03:00:00 GMT  
 Complete font for J

Quote:
Alain Delmotte writes:
> Why did ISI create the ISIJ and JFONT fonts?

We distribute these fonts so that we can be certain that users will
have a fixed pitch truetype font with line drawing characters. The help
files use this font for J expressions and results.

If a font such as MSLineDraw were distributed with Windows,
we would use that instead.

Quote:
> In MSLine Draw, the boxes are not completely closed.

The J manuals use MSLineDraw, and you can see that the boxes
are completely closed.

Chris



Mon, 19 Oct 1998 03:00:00 GMT  
 Complete font for J


Roger Hui writes on Thursday, May 2:

Quote:
>Since fonts are part of the Windows product/environment, complaints
>about defective and deficient fonts should be directed at a certain
>other software company.  It remains the case that if (may be a
>big if) you can do all you want (accents, boxes, whatever) with
>a standard font that is always better than doing it with a
>non-standard one.  Consider this:  why does C, Cobol, Fortran, K,
>Lisp, Pascal, ... (almost) any programming language one cares to name,
>not concern itself with fonts?  And would our concerning ourselves
>with fonts give us a significant advantage?

What do you call a *standard* font? One which is distributed with Windows, or
one which follows the Windows layout or one which follows the ISO standard or
what else ... ?

Apparently you do not want to understand the full problem, so I suggest the
next time you develop in J for any string to be displayed you do not use your
normal keyboard but you enter all the characters with Alt+0xxx. Let me know if
you like that way of work. In C, Cobol, ... I have the full letters set for
*my* language from the normal keyboard and I do not look for boxes.


Quote:
Chris Burke writes:
>If a font such as MSLineDraw were distributed with Windows,
>we would use that instead.

I think MS Line Draw *is* part of the Windows package.
Further MS Line Draw doesn't have the normal layout of Windows, but the layout
of the 437 page under DOS (which explains why we - non-English writers - do not
get the accented characters of our keyboard.

BUT if there is no need for another font with accents and boxes will just
ourself what we have prepared and forget about the others.

Alain
Avenue du Marathon, 6                     Ecology, Environment
B1348 Louvain-la-Neuve                    Bio & Agro-climatology
BELGIUM                                   Data processing
tel: (belgium)-10-45 11 92



Tue, 20 Oct 1998 03:00:00 GMT  
 Complete font for J

Quote:

>Continuing the search for a complete (with accents and boxes) font for J

If  I am butting in here inappropriately, I apologise. However the
responses to the original question seem to be unhelpful so far.

This person is not talking about computer languages but about his
language, the one he speaks, the one he communicates in, the one he
uses to name verbs, nouns,etc.in his programs, the one that will
appear on the GUI or in reports in any application he develops so that
the users, who may not speak English, understand and can use it. I
assume from the mention of accents that he is talking about French,
where accented letters are essential to correctly define a word.

In Windows there are keyboard settings for different languages which
affect which characters appear in the default font. Presumably, other
programming languages use that default font. The problem with J is
that it uses special box drawing characters which appear to conflict
with accented letters.

I am no expert on any of this and have no solution to the original
question, but felt that there should be some acknowledgement that
English, including the North American dialect, is not yet the
universal language  ;)

Regards, Ros Fovargue



Tue, 20 Oct 1998 03:00:00 GMT  
 Complete font for J

Quote:

> Apparently you do not want to understand the full problem, so I suggest the
> next time you develop in J for any string to be displayed you do not use your
> normal keyboard but you enter all the characters with Alt+0xxx. Let me know if
> you like that way of work. In C, Cobol, ... I have the full letters set for
> *my* language from the normal keyboard and I do not look for boxes.

Quite a few comments, without stating my personal opinion on this
matter at all:

- Internationalization/Localization-related debates very often get soon
  troubled by personal attacks.  (A refuses to acknowledge B's problems,
  or B charges A with (for?) ignorance, or chauvinistic attitudes are
  attributed in both directions.  Users clash against vendors clash against
  implementors clash against users.)

  At the risk of stating the obvious: Everybody, PLEASE: Avoid the urge
  to get personal.
  We are dealing with tough problem here, and somebody probably *will* end up
  being severely unhappy no matter what the outcomes are, even if there's none
  at all.

- Character entry or display is not the hard problem here. It's a very comparatively
  simple technical one that can be solved.

  The problem is to select one code set (or several) for J which

    * has the box characters                    (debatable, 1)
    * has national characters                   (debatable, 2)
    * is "standard" across all J-platforms      (debatable, 3)
    * is "standard" across other applicatitions
      (editable with standard editors, communicatable
      as "cleartext", and so on)                (debatable, 4)

  Unless somebody can come up with a codeset fullfilling all four points
  (and chances are bad), arguments about what to sacrifice will probably
  start flying.

- Different persons will want to call for different compromises because
  they will have different needs and priorities.  There are no absolute
  rights and wrongs.

After this long preamble:

  [Opinion]  If it indeed has enough undefined "holes", their exploition
  would be a pragmatic comprise I could personally live with.  This would
  derived a non-standard codeset from a standard one.  Roger is right on
  this but it would be possible to exchange J programs written in the standard
  Latin-x subset.  For J source code, I don't need the nice box characters.
  I would need national characters if I would be developing real applications.
  I restrict myself to using the standard Latin-x subset to exchange source
  code (==no box characters literally in the source) between platforms.
  I would continue to use straight ascii (which is a subset of Latin-x)
  on comp.lang.apl and use the pseudo box charcaters like '-|+++++++++'
  there.

  [Opinion]  I'm not sure if it is supposed to be valid to exploit boxed
  display for presenting data to the end user.  I'm not even sure if it should
  be or not.  Having said that, I wouldn't inflict Alain's severely shifted
  boxed displays on end users and would prefer ascii boxes to shifted ones.
  Alain was shifting because he tried to squeeze the boxes into Latin-1.

  [Opinion]  I would never accept a Latin1-box combination which sacrifices
  "a few" characters from the official Latin1 set, no matter which ones.
  Either the holes can make it or I'd forget that idea.  (I even wasn't
  aware that there are holes in the Latin-x'es).

Technique:  If Alain has just to squeeze two characters out of the conventional
box drawing set top fit them into Latin-1 holes:  How about using two diagonal
strokes for the four corners: '/' for UL and LR,  '\' for LL and UR.  Crudely:

/---+---\
|abc|123|
\---+---/

(I can't remember the details how much Alain's previous technique saved.
It was pretty nifty, at any rate, though I didn't liked the ouptut.)

                                                        Martin Neitzel



Tue, 20 Oct 1998 03:00:00 GMT  
 Complete font for J

With all these talks about fonts and display of boxes I would like
to hear what the oppinions are about the useability and use of
the other types of displays, Linear display and Tree display.

I tend to use Boxed or Linear display. Only occasionally look at
the Tree display and I have not spent too much time on it because
I have not been too sure how to interpret what it is supposed to
tell me. I am sure that it would open up a door to understanding
J better if I understood the Tree display.
--

http://www2.simi.is/~gosi
http://www.jsoftware.com



Tue, 20 Oct 1998 03:00:00 GMT  
 Complete font for J

Quote:

> /---+---\
> |abc|123|
> \---+---/

before I noticed that this is crap.  Sorry.  A diagonale to link straight lines
would go from corner to corner but would connect the centers of the sides.
So you would still need four different corners.

To compensate for my slip somewhat, I can offer an alternative design:  Use a diamond
for all corners.  This leaves you with just three symbols for the box drawings:
-, |, and diamond.  The result is a classic shape for (ceramic) tiles.
If it's your lucky day, you can use the "Terminal" font and
   9!:7 (1{a.) (<0;i.9)} 9!:6 ''

                                                                Martin Neitzel



Tue, 20 Oct 1998 03:00:00 GMT  
 Complete font for J

Quote:

> non-standard one.  Consider this:  why does C, Cobol, Fortran, K,
> Lisp, Pascal, ... (almost) any programming language one cares to name,
> not concern itself with fonts?  And would our concerning ourselves
> with fonts give us a significant advantage?

Very well stated !!

I can think of one language that has been struggling all its existense
with fonts.

I like the way J deals with fonts. Leaving it up to windows that is.

The only time the fonts are a problem is in the boxed outputs during
devolpment but it is a minor issue because I can always change fonts in
my window without affecting anything besides the current view. It can
take awhile to choose the correct fonts to use. I use terminal mostly
and only go over to other fonts when I need and then I sometimes keep
two windows open on the same script in different fonts.

I am sure this is a problem for many because there are so many issues
involving fonts and national codepages. I get confused sometimes and
I know a lot more about fonts and codepages than most ordinary users.

I am looking forward to common use of Unicode.
--

http://www2.simi.is/~gosi
http://www.jsoftware.com



Tue, 20 Oct 1998 03:00:00 GMT  
 Complete font for J


Ros Fovargue writes on Friday, May 3:

Quote:
> In Windows there are keyboard settings for different languages which
> affect which characters appear in the default font. Presumably, other
> programming languages use that default font. The problem with J is
> that it uses special box drawing characters which appear to conflict
> with accented letters.  ...

The last sentence is incorrect.  The user can select box
drawing characters from the 7-bit ASCII alphabet, for example
'+++++++++|-'.  (I routinely do this myself when generating
text for dissemination on the net.)  In that case, J would use
only 7-bit ASCII characters, whence there would be no interference
whatsoever with accented characters, fonts, keyboards, displays,
printers, whatever.


Wed, 21 Oct 1998 03:00:00 GMT  
 Complete font for J


Quote:
> This person is not talking about computer languages but about his
> language, the one he speaks, the one he communicates in, the one he
> uses to name verbs, nouns,etc.in his programs, the one that will
> appear on the GUI or in reports in any application he develops so that
> the users, who may not speak English, understand and can use it.

I can relate to this person because I am working in a similar
environment. I, and my application users, use fonts to read information
that can not be used for J objects.

I do not find that a hindrance in naming J objects. Many of the
Icelandic characters are using 8 bit codings so they get ruined in
7 bit translations. I can not send them to c.l.a so that is a similar
problem there.

In Icelandic there are even several codepages in use for the same
characters. Fortunately different factions who have been fighting for
their codepages have agreed on a common representation in Unicode
so that in Unicode codepage numbers form 1252 will be used on the
first level, level 0, of Unicode. Otherwise today we have a lot of
applications and people using codepages 861 and 850 besides 1252.

Unfortunately for APL there is not yet agreement on where to put the
APL characters in Unicode.

Quote:
> In Windows there are keyboard settings for different languages which
> affect which characters appear in the default font. Presumably, other
> programming languages use that default font. The problem with J is
> that it uses special box drawing characters which appear to conflict
> with accented letters.

I think that you are creating an assumption about a problem with J
which does not exist.

As I said earlier there are several ASCII codes in use by national
languages which are not accepted as names of J objects. This is by
choice to not get into conflicting codepage problems. One letter
in Icelandic has different font representation depending on what
codepage you are using at a time.

It is one of the strenghts in J that it is codepage and font
independent. So rather than getting into mixing J with these character
and font problems the developers of J should be gratulated in how
well they have handled the issue.

As the discussion started out discussing the display of boxed items
in J then you will notice that you can do what you want in a number
of  J windows. Open up several execution (JX) windows as well as
script (JS) windows and you can have different fonts in all of them.

You can also change the fonts from one font to another and look at
the display change until you have the one you want. Different styles
and sizes. Regular, Italic, Bold and so on.

It is entirely up to windows and your machine. Change the codepage and
you get an entirely different representation. The J objects will still
work and look the same. This is really one of J's strong points !!

Quote:
> I am no expert on any of this and have no solution to the original
> question, but felt that there should be some acknowledgement that
> English, including the North American dialect, is not yet the
> universal language  ;)
> Regards, Ros Fovargue

There is a solution to this and the name of that solution is Unicode.
It is closer than what you think.

It is a bit strange to notice that APL is going to continue have a
certain degree of problems left in Unicode if the different codepage
groups within the APL community will not be able to agree some time
soon.

J does not have a problem in this area. Not with Unicode and NOT NOW.
The only problem here is some persons not knowing how to manage fonts
in Windows when they are using J.

--

http://www2.simi.is/~gosi
http://www.jsoftware.com



Wed, 21 Oct 1998 03:00:00 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. JS-EAI with *JS*-callback

2. js.exception 3279.js

3. Workspace font is neglecting dolphin font option

4. Fonts and Font Menu

5. Problem with Small Fonts Big Fonts

6. Font Editor for Oberon fonts

7. ROM font question... 8x8 font

8. RFC: Accessing special font characters in 8-bit fonts

9. Deperately seeking Tk font expertise (was Re: TIP #64: Improvements to Windows Font Handling)

10. Tk system fonts don't match actual system fonts

11. font size taken wrong from X font

12. Default font for wish and/or Font tool availability

 

 
Powered by phpBB® Forum Software