Smalltalk › Cincom › VisualWorks

AspectAdaptors

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

Sylvain pralon

AspectAdaptors

Hi,

I am trying to use some adaptors for my GUI application and I do not
manage to do anything.
I read all the examples. They initialized the adaptors in the initialize
method. I can not do this because I have to set them up
after opening a file.
It seems to work because with an halt, I can see that after setting up
the adaptor (on a list), I have something in my list as expecting.
The problem is that my widget which is connected to the adaptor do not
refresh.

Anybody can help, please ?

Sylvain

Mike Bielser

[VW NC 7.5] Font problem

Hi
after digging around and evaluating countless code fragments in the
workspace, here is the code I've come up with to test math glyphs:

obj := Screen default listFontNames select: [:each | 'Math*' match: each ].

gc := (ExamplesBrowser prepareScratchWindowOfSize: 300@800) graphicsContext.
ts := TextStream on: String new.
16rf021 to: 16rf0ff do: [:each| ts nextPut: each asCharacter.
(each rem: 10) = 0
ifTrue: [ ts nextPut: Character tab.
ts nextPut: Character tab.
each printOn: ts base: 16.
ts nextPut: Character cr]
ifFalse: [ts nextPut: Character space]].

txt := ts contents asComposedText.
fd := (FontDescription new) name: 'Math1-Regular'; pixelSize: 16.
ca := CharacterAttributes newWithDefaultAttributes.
ca setDefaultQuery: fd.
ta := TextAttributes characterAttributes: ca.
ta gridForFont: nil withLead: 2.
txt textStyle: ta.
txt displayOn: gc at: 5@5.

This works on a Mac (PowerBook G4 using VW NC 7.5) using the macx object
engine, but does NOT work on WinXP. I tried different unicode ranges on
WinXP, tried different fonts and more, but this didn't help. The PopChar
utility (as well as others) show that the font is installed, not
corrupted and that the glyphs are in the same range. And now??? Maybe
I'm overlooking something trivial?

Does anybody have any ideas, hints or solutions? Is this a known bug?

Thanks for any help
Mike

P.S.
The attached screenshot shows how the window is supposed to look like...

Picture 1.png (51K) Download Attachment

Mark Plas

RE: [VW NC 7.5] Font problem

Hi Mike,

This is a known issue. On the Cincom roadmap there is an item saying:

"Make Smalltalk truly international capable: when you bring up an image,
typing/displaying the local characters should "just work""

It's not only the displaying that doesn't work. Typing and copy-pasting
characters doesn't work the way you'd expect either. I don't know what
the current status on this is but I hope this will be solved soon.

-----Original Message-----
From: Mike Bielser [mailto:[hidden email]]
Sent: dinsdag 25 september 2007 15:48
To: [hidden email]
Subject: [VW NC 7.5] Font problem

Hi
after digging around and evaluating countless code fragments in the
workspace, here is the code I've come up with to test math glyphs:

obj := Screen default listFontNames select: [:each | 'Math*' match: each
].

gc := (ExamplesBrowser prepareScratchWindowOfSize: 300@800)
graphicsContext.
ts := TextStream on: String new.
16rf021 to: 16rf0ff do: [:each| ts nextPut: each asCharacter.
(each rem: 10) = 0
ifTrue: [ ts nextPut: Character tab.
ts nextPut: Character tab.
each printOn: ts base: 16.
ts nextPut: Character cr]
ifFalse: [ts nextPut: Character space]].

txt := ts contents asComposedText.
fd := (FontDescription new) name: 'Math1-Regular'; pixelSize: 16.
ca := CharacterAttributes newWithDefaultAttributes.
ca setDefaultQuery: fd.
ta := TextAttributes characterAttributes: ca.
ta gridForFont: nil withLead: 2.
txt textStyle: ta.
txt displayOn: gc at: 5@5.

This works on a Mac (PowerBook G4 using VW NC 7.5) using the macx object

engine, but does NOT work on WinXP. I tried different unicode ranges on
WinXP, tried different fonts and more, but this didn't help. The PopChar

utility (as well as others) show that the font is installed, not
corrupted and that the glyphs are in the same range. And now??? Maybe
I'm overlooking something trivial?

Does anybody have any ideas, hints or solutions? Is this a known bug?

Thanks for any help
Mike

P.S.
The attached screenshot shows how the window is supposed to look like...

Rob Vens-2

Re: AspectAdaptors

In reply to this post by Sylvain pralon

not sure if I understand your problem correctly, but if you are using AspectAdapters, you can tell them sendUpdates: true to make them propagate changes in the domain

2007/9/25, Sylvain Pralon < [hidden email]>:

Hi,

I am trying to use some adaptors for my GUI application and I do not
manage to do anything.
I read all the examples. They initialized the adaptors in the initialize
method. I can not do this because I have to set them up
after opening a file.
It seems to work because with an halt, I can see that after setting up
the adaptor (on a list), I have something in my list as expecting.
The problem is that my widget which is connected to the adaptor do not
refresh.

Anybody can help, please ?

Sylvain

Steven Kelly

RE: [VW NC 7.5] Font problem

In reply to this post by Mike Bielser

Are you sure about that, Mark? IIUC the "international capable" part of
the roadmap is aimed at things like solving the problems with entering
accented characters in Unix Unicode locales, and the need on Windows to
load the Japanese and Unicode parcels manually. On Unix the locale can
be set manually to get things working, but that's a hassle users
shouldn't have to deal with. Similarly on Windows the support for
Japanese works well, but it's a hassle to set up.

Mike's problem appears different, since it affects Windows in (probably)
any Locale.

Is there an existing AR for this problem with Symbol and Wingdings
fonts?

Steve

> -----Original Message-----
> From: Mark Plas [mailto:[hidden email]]
> Sent: 25. syyskuuta 2007 17:02
> To: Mike Bielser; [hidden email]
> Subject: RE: [VW NC 7.5] Font problem
> Importance: High
>
>
> Hi Mike,
>
> This is a known issue. On the Cincom roadmap there is an item saying:
>
> "Make Smalltalk truly international capable: when you bring
> up an image, typing/displaying the local characters should
> "just work""
>
> It's not only the displaying that doesn't work. Typing and
> copy-pasting characters doesn't work the way you'd expect
> either. I don't know what the current status on this is but I
> hope this will be solved soon.
>
>
>
> -----Original Message-----
> From: Mike Bielser [mailto:[hidden email]]
> Sent: dinsdag 25 september 2007 15:48
> To: [hidden email]
> Subject: [VW NC 7.5] Font problem
>
> Hi
> after digging around and evaluating countless code fragments
> in the workspace, here is the code I've come up with to test
> math glyphs:
>
> obj := Screen default listFontNames select: [:each | 'Math*'
> match: each ].
>
> gc := (ExamplesBrowser prepareScratchWindowOfSize: 300@800)
> graphicsContext. ts := TextStream on: String new. 16rf021 to:
> 16rf0ff do: [:each| ts nextPut: each asCharacter.
> (each rem: 10) = 0
> ifTrue: [ ts nextPut: Character tab.
> ts nextPut: Character tab.
> each printOn: ts base: 16.
> ts nextPut: Character cr]
> ifFalse: [ts nextPut: Character space]].
>
> txt := ts contents asComposedText.
> fd := (FontDescription new) name: 'Math1-Regular'; pixelSize:
> 16. ca := CharacterAttributes newWithDefaultAttributes. ca
> setDefaultQuery: fd. ta := TextAttributes
> characterAttributes: ca. ta gridForFont: nil withLead: 2. txt
> textStyle: ta. txt displayOn: gc at: 5@5.
>
> This works on a Mac (PowerBook G4 using VW NC 7.5) using the
> macx object
>
> engine, but does NOT work on WinXP. I tried different unicode
> ranges on
> WinXP, tried different fonts and more, but this didn't help.
> The PopChar
>
> utility (as well as others) show that the font is installed, not
> corrupted and that the glyphs are in the same range. And now??? Maybe
> I'm overlooking something trivial?
>
> Does anybody have any ideas, hints or solutions? Is this a known bug?
>
> Thanks for any help
> Mike
>
> P.S.
> The attached screenshot shows how the window is supposed to
> look like...
>
>

Dennis smith-4

Re: AspectAdaptors

In reply to this post by Rob Vens-2

Based on your original email -- are you creating the AspectAdaptors yourself? and if so, is it after the window opens?
You must let the code create them during the windows open as its designed to do. You can then UPDATE the things
they point to, but the GUI framework will be hanging onto those original instances and may not ask for them again.

Rob Vens wrote:

not sure if I understand your problem correctly, but if you are using AspectAdapters, you can tell them sendUpdates: true to make them propagate changes in the domain

2007/9/25, Sylvain Pralon < [hidden email]>:
Hi,

I am trying to use some adaptors for my GUI application and I do not
manage to do anything.
I read all the examples. They initialized the adaptors in the initialize
method. I can not do this because I have to set them up
after opening a file.
It seems to work because with an halt, I can see that after setting up
the adaptor (on a list), I have something in my list as expecting.
The problem is that my widget which is connected to the adaptor do not
refresh.

Anybody can help, please ?

Sylvain

-- 
Dennis Smith                 		         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              <a class="moz-txt-link-freetext" href="sip:dennis@CherniakSoftware.com">sip:dennis@...
Canada			         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

Steven Kelly

RE: [VW NC 7.5] Font problem

In reply to this post by Mike Bielser

Mike,

I don't have any Math* fonts, but I was able to get Wingdings working
with the following changes to your code:

"Manually use the dingbat encoding of E0##"
16re021 to: 16re0ff ...

"Note use of family: not name:"
"name: will never match the full long names on Windows"
fd := (FontDescription new) family: 'Wingdings'; pixelSize: 16.

If you want to use Symbol, you can replace 'Wingdings' with 'Symbol' and
use 16r03a0 to: 16r0400, plus 16r2130-2340, 16rF8F0-FF etc.

This works in both 7.4.1 and 7.5, so I guess we can state the VW problem
a little more exactly as "VW should map characters to glyphs in symbol
and dingbat fonts in the same way as the operating system". In other
words if pressing D in Windows with the Symbol font shows a capital
Delta (triangle), then $D in VW should display as the same Delta glyph
in the Symbol font.

I've attached a text file which workspace contents to calculate and
display all legal codepoints for a given font, and an example screenshot
for Symbol.

HTH,
Steve

> -----Original Message-----
> From: Mike Bielser [mailto:[hidden email]]
> Sent: 25. syyskuuta 2007 16:48
> To: [hidden email]
> Subject: [VW NC 7.5] Font problem
>
>
> Hi
> after digging around and evaluating countless code fragments in the
> workspace, here is the code I've come up with to test math glyphs:
>
> obj := Screen default listFontNames select: [:each | 'Math*'
> match: each ].
>
> gc := (ExamplesBrowser prepareScratchWindowOfSize: 300@800)
> graphicsContext.
> ts := TextStream on: String new.
> 16rf021 to: 16rf0ff do: [:each| ts nextPut: each asCharacter.
> (each rem: 10) = 0
> ifTrue: [ ts nextPut: Character tab.
> ts nextPut: Character tab.
> each printOn: ts base: 16.
> ts nextPut: Character cr]
> ifFalse: [ts nextPut: Character space]].
>
> txt := ts contents asComposedText.
> fd := (FontDescription new) name: 'Math1-Regular'; pixelSize: 16.
> ca := CharacterAttributes newWithDefaultAttributes.
> ca setDefaultQuery: fd.
> ta := TextAttributes characterAttributes: ca.
> ta gridForFont: nil withLead: 2.
> txt textStyle: ta.
> txt displayOn: gc at: 5@5.
>
> This works on a Mac (PowerBook G4 using VW NC 7.5) using the
> macx object
> engine, but does NOT work on WinXP. I tried different unicode
> ranges on
> WinXP, tried different fonts and more, but this didn't help.
> The PopChar
> utility (as well as others) show that the font is installed, not
> corrupted and that the glyphs are in the same range. And now??? Maybe
> I'm overlooking something trivial?
>
> Does anybody have any ideas, hints or solutions? Is this a known bug?
>
> Thanks for any help
> Mike
>
> P.S.
> The attached screenshot shows how the window is supposed to
> look like...
>

ShowFont.txt (1K) Download Attachment

ShowFont-Symbol.gif (11K) Download Attachment

Mike Bielser

Re: [VW NC 7.5] Font problem

Hi Mark, Hi Steve
thanks for your comments.
Mark:
Now that you mentioned the thing with "Make Smalltalk truly international capable" I remember having
read that on the roadmap. But that is actually not the problem I'm fighting with right now. I'm
actually only working in the C locale, so for the moment let's forget about locales &
internationalization (although I have "localized" my app completely, meaning that the user can
switch between US-English and German on-the-fly).

Steve:
The "Math*" fonts are all from Mathematica (from older versions, I believe; new versions come with
fonts called "Mathematica*"). Back in the old days you could even download them separately. I tried
your code, it works on my WinXP box, I'll try it on my Mac a little later. With the experience so
far (i.e. WinXP only), I completely agree with your formulation of the problem. Anyhow, I do think
it's a bug that should be fixed. At least it's not the behavior I'd have expected.

Thanks again for your kind help!
Mike

Andre Schnoor

Re: [VW NC 7.5] Font problem

In reply to this post by Mike Bielser

Hi Mike,

you may want to have a look at the package "CGN Tools-Fonts" in the OR. The class FontMetricsInspector includes code that has proven to be safe for platform-specific fonts of all sizes. IIRC, using VariableSizeTextAttributes and PlatformCharacterAttributes solved many issues for me. Here's a rough excerpt from the code ..

textAttributes
    | characterAttributes ta scale fd |
    fd := self fontDescription.
    scale := self characterAttributesScalingFactor.

    characterAttributes := (PlatformCharacterAttributes newWithDefaultAttributes)
        setPlatformId: self fontPolicy fontClass platformName asSymbol;
        setPlatformQuery: fd;
        setPortableQuery: (FontDescription new family: #( 'helv*' '*' ); yourself);
        at: #base put: [ :query | fd ]; "used to refer to the default style when calculating leading & baseline"
        yourself.
    scale == 1
        ifTrue:[ characterAttributes noScaling ].

    ta := VariableSizeTextAttributes new
        setCharacterAttributes: characterAttributes;
        scalingFactor: scale;
        useFourSpaceTabWidth;
        fontAttributeForLeading: #base;
        install;
        yourself.
    scale == 1
        ifTrue:[ characterAttributes noScaling ]. "hack: was reset by above scalingFactor: message"
    characterAttributes
        updatedQueryFor: self fontPolicy.
    ^ta

... showing how to setup a TextAttributes that work with a specific font. I tested on MacOS X and Windows with many fonts and weird Unicode chars. The class also includes code for creating appropriate FontDescriptions etc.

HTH

Andre

--

Mike Bielser wrote:

Hi
after digging around and evaluating countless code fragments in the
workspace, here is the code I've come up with to test math glyphs:

obj := Screen default listFontNames select: [:each | 'Math*' match: each ].

gc := (ExamplesBrowser prepareScratchWindowOfSize: 300@800) graphicsContext.
ts := TextStream on: String new.
16rf021 to: 16rf0ff do: [:each| ts nextPut: each asCharacter.
    (each rem: 10) = 0
        ifTrue: [ ts nextPut: Character tab.
                    ts nextPut: Character tab.
                    each printOn: ts base: 16.
                    ts nextPut: Character cr]
        ifFalse: [ts nextPut: Character space]].

txt := ts contents asComposedText.
fd := (FontDescription new) name: 'Math1-Regular'; pixelSize: 16.
ca := CharacterAttributes newWithDefaultAttributes.
ca setDefaultQuery: fd.
ta := TextAttributes characterAttributes: ca.
ta gridForFont: nil withLead: 2.
txt textStyle: ta.
txt displayOn: gc at: 5@5.

This works on a Mac (PowerBook G4 using VW NC 7.5) using the macx object engine, but does NOT work on WinXP. I tried different unicode ranges on WinXP, tried different fonts and more, but this didn't help. The PopChar utility (as well as others) show that the font is installed, not corrupted and that the glyphs are in the same range. And now??? Maybe I'm overlooking something trivial?

Does anybody have any ideas, hints or solutions? Is this a known bug?

Thanks for any help
Mike

P.S.
The attached screenshot shows how the window is supposed to look like...

-- 
Andre Schnoor
Cognitone GmbH
www.cognitone.com

Mike Bielser

Re: [VW NC 7.5] Font problem

Hi Andre
I am aware of "CGN Tools-Fonts", I actually have it loaded in the image I'm using to test all this
font/glyph related problems. What I didn't do is use any code from this package. But please take a
look at the attached screenshot which perfectly illustrates my point: It shows "Font Metrics
Inspector" open, together with "Unicode Font Viewer". Now take the small (Latin) letter "d" (hex
$0064, so this is definitely NOT in some exotic unicode plane). Quite obviously if I type "d" (small
Latin) on the keyboard, I expect to get the small (Greek) "delta" IF I use the Symbol font. Now take
a look at "Font Metrics Inspector": All I get is a bunch of black squares ?!
Now don't get my wrong: I do NOT believe this is your mistake (or whoever coded this "Font Metrics
Inspector"), it's a VW issue. I expect things like these to "work out of the box" WITHOUT even
loading additional packages (after all, VW brags being unicode internally).

Just my two cents
Mike

P.S.
This issue beautifully illustrates my main concern with the Smalltalk-VW duo (and I guess any other
Smalltalk duo, like Smalltalk-Squeak, would qualify): A lot of the efficiency gained by using
Smalltalk is lost dealing with issues like the one above. A pity! But I'll stop rambling...

Mike Bielser

Re: [VW NC 7.5] Font problem

...looks like the screenshot got lost. Hope it works this time.

Mike

FontMetricsInspector.jpg (213K) Download Attachment

Michael Lucas-Smith-2

Re: [VW NC 7.5] Font problem

Have you tried this code on WinXP with the AllEncodings preview parcel
loaded in to your image?

Michael

Mike Bielser wrote:
> ...looks like the screenshot got lost. Hope it works this time.
>
> Mike
>
> ------------------------------------------------------------------------
>

Mike Bielser

Re: [VW NC 7.5] Font problem

Michael Lucas-Smith wrote:
> Have you tried this code on WinXP with the AllEncodings preview parcel
> loaded in to your image?
>
> Michael

Just tried with AllEncodings loaded; unfortunately at least here on my WinXP box it didn't make any
difference at all. Plaese see the attached screenshot (created with the code below). Here is the
code I'm using (slightly adjusted from the one I already published):

obj := Screen default listFontNames select: [:each | 'Symb*' match: each ].
gc := (ExamplesBrowser prepareScratchWindowOfSize: 300@800) graphicsContext.
ts := TextStream on: String new.
16r0000 to: 16r00ff do: [:each|
(each rem: 10) = 0
ifTrue: [ts nextPut: Character cr.
each printOn: ts paddedWith: $0 to: 5 base: 10.
ts nextPut: Character tab.
ts nextPut: Character tab]
ifFalse: [ts nextPut: Character space].
ts nextPut: each asCharacter.].

txt := ts contents asComposedText.
fd := (FontDescription new) family: 'Symbol*'; pixelSize: 16.
ca := CharacterAttributes newWithDefaultAttributes.
ca setDefaultQuery: fd.
ta := TextAttributes characterAttributes: ca.
ta gridForFont: nil withLead: 2.
txt textStyle: ta.
txt displayOn: gc at: 5@5.

Main change: I replaced "name:" with "family:" when creating the FontDescription (as suggested),
although I don't see the point here. After all, I inspect the first line of code to get the unique,
platform-dependent font name that (my guess) VW constructs; something like
"Symbol~0~400~0~0~0~symbol~4" on my WinXP box. So I assumed (wrongly maybe) that this is a unique,
valid font description.
This is exactly the reason why I chose the fonts Wolfram supplies with Mathematica for my test: One
can be sure that they give identical results irrespective of the platform (otherwise Mathematica
workbooks wouldn't be portable)

Mike

SymbolFont.jpg (58K) Download Attachment

Andre Schnoor

Re: [VW NC 7.5] Font problem

IIRC, VW uses Unicode internally, so you should perhaps use the
appropriate 2-Byte Unicode chars to get the symbols you want. I tested
with the font inspector and it worked fine (will publish the change).
BTW: Just typing "d" did not get me "delta" here, even with the "Symbol"
font.

See the attached screen snippet as an example.

HTH

Andre

symbols.png (52K) Download Attachment

Steven Kelly

RE: [VW NC 7.5] Font problem

In reply to this post by Mike Bielser

Yep, that's the issue: why does pressing 'd' in the Symbol font show
delta in Notepad, but not in VW. I'd expect the VW font encoder to take
care of mapping $d to the correct character. Currently it maps Character
value: 16r03b4 to 100, which of course is the integer value of $d. The
solution appears to be as simple as telling VW to use the Windows-1252
encoder rather than the 'symbol' encoder, for this font. This can be
demonstrated by adding the following line to ShowFont.txt (attached
yesterday).

platFont setEncoder: ByteCharacterEncoder mscp1252.

Interestingly, the same problem appears to exist for Mozilla:
http://hutchinson.belmont.ma.us/tth/Wfonts.html

I guess the base issue is that VW expects you to use the correct Unicode
values: Character value: 16r03b4 _is_ a small delta, regardless of the
font, and Character value: 100 _is_ a lower-case Roman d, regardless of
the font. In that sense, VW is correct. But when we press d on the
keyboard with a Symbol font chosen, we're used to seeing a delta. Maybe
VW could encode BOTH 16r03b4 and 100 to the same value in the 'symbol'
encoder, by extending ScreenFont symbolEncoder with #encodeVariant:as:,
at least for the values that don't overlap. E.g.

encoder := ScreenFont symbolEncoder.
($a asInteger to: $z asInteger), ($A asInteger to: $Z asInteger) do:
[:int |
encoder encodeVariant: (Character value: int) as: int].

The results and code to reproduce are attached. Pressing C correctly
shows a Chi (X) rather than Gamma, just like in Notepad.

Steve

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]]
> Sent: 26. syyskuuta 2007 13:22
> To: Mike Bielser
> Cc: [hidden email]
> Subject: Re: [VW NC 7.5] Font problem
>
>
> IIRC, VW uses Unicode internally, so you should perhaps use the
> appropriate 2-Byte Unicode chars to get the symbols you want.
> I tested
> with the font inspector and it worked fine (will publish the change).
> BTW: Just typing "d" did not get me "delta" here, even with
> the "Symbol"
> font.
>
> See the attached screen snippet as an example.
>
> HTH
>
> Andre
>

ShowFont-Symbol2.png (8K) Download Attachment

ShowFont-Symbol2.txt (1K) Download Attachment

Mike Bielser

Re: [VW NC 7.5] Font problem

Steven Kelly wrote:
> Yep, that's the issue: why does pressing 'd' in the Symbol font show
> delta in Notepad, but not in VW. I'd expect the VW font encoder to take
> care of mapping $d to the correct character.

Yes, that's exactly my point. The default behavior of VW should be to reproduce the (possibly
platform dependent) expected behavior.
Mike

Andre Schnoor

Re: [VW NC 7.5] Font problem

Mike Bielser wrote:
> Steven Kelly wrote:
>> Yep, that's the issue: why does pressing 'd' in the Symbol font show
>> delta in Notepad, but not in VW. I'd expect the VW font encoder to take
>> care of mapping $d to the correct character.
>
> Yes, that's exactly my point. The default behavior of VW should be to
> reproduce the (possibly platform dependent) expected behavior.
> Mike
>

But VW is expected to be /platform independent/, hence Unicode.
Otherwise, all strings in the image would need to be converted to the
current platform encoding upon image startup. OTHO, character /input/ is
not related to a font, i.e. I would consider it badly dirty to translate
keyboard input depending on a particular font.

Andre

Steven Kelly

RE: [VW NC 7.5] Font problem

In reply to this post by Mike Bielser

Steven Kelly wrote:
> >> Yep, that's the issue: why does pressing 'd' in the Symbol
> >> font show delta in Notepad, but not in VW. I'd expect the
> >> VW font encoder to take care of mapping $d to the correct
> >> character.

Mike Bielser wrote:
> > Yes, that's exactly my point. The default behavior of VW
> > should be to reproduce the (possibly platform dependent)
> > expected behavior.

Andre Schnoor wrote:
> But VW is expected to be /platform independent/, hence Unicode.
> Otherwise, all strings in the image would need to be converted
> to the the current platform encoding upon image startup. OTHO,
> character /input/ is not related to a font, i.e. I would
> consider it badly dirty to translate keyboard input depending
> on a particular font.

I'm not suggesting translating keyboard input. I was suggesting
translating the characters when we display them. Did you look at the
ShowFont-Symbol.txt code?

However, it gets even more interesting. What if we write abcd (the
normal Roman codepoints) plus Delta (the Unicode delta) to a UTF-8 file,
and open it in Notepad as Unicode:

f := 'abcdDelta.txt' asFilename.
ws := (f withEncoding: #utf8) writeStream.
"Byte order mark"
ws binary nextPut: 239; nextPut: 187; text.
[ws nextPutAll: 'abcd'; nextPut: (Character value: 16r03b4)] ensure: [ws
close].

1) Do the above in Smalltalk
2) Start Notepad with NO file
3) File | Open | Encoding: UTF-8, File: abcdDelta.txt
4) Format | Font... | Lucida Sans Unicode (or other Unicode font)
You'll see abcd<delta>
5) Format | Font... | Symbol
You'll see <alpha>, <beta>, <chi>, <delta>, <illegal character
rectangle>.

In other words, in Windows the encoding for the Symbol font is basically
ASCII, not a symbol font encoder. That fits with what we see in VW, and
what is seen in Mozilla: to get Symbol fonts to work, we need to set
their encoding to MS_CP_1232 or similar, NOT symbol.

So the real correction is probably something like changing a line in
ScreenFont class>>initializeEncoding,
(FontEncodings at: 'MS-Windows') at: 'symbol' put: msEncoder.
"was symbolEncoder"
and probably similarly for 'general-dingbat'

Steve