WIMPSymbol font

The arrow symbols in WIMPSymbol font (asc 136-139 x88-x8B) are sometimes used as part of a text string in window icons and menus. Using RO5.20 I find that they are sometimes (always?) displayed as qGIJ respectively, as they are not in the selected desktop font.

I am sure there is some obscure setting I have not made to enable these to display properly, but I have been uable to find it. My RO4.39 VRPC displays them just fine!

What have I missed?

It shouldn’t matter if they are in the selected desktop font or not, I think. The Wimp inserts control codes into strings it sends to Font_Paint to automatically switch to the WIMPSymbol font for those special characters (unless the system encoding is UTF8).

Is your system alphabet set to UTF8? (EDIT: Not that I’d expect that to give the characters you listed, but it’s worth checking.)

Is the font cache full, so WIMPSymbol can’t be loaded, maybe? What does *FontList give you?

*alphabet gives Latin1. Font cache has 327 Kbytes free.
Thanks for the clues how it works … next suggestions please?

In !Edit they display as [8b] both in RSC OS 4.39 (VRPC), 5.21 (Pi) and 5.16 (Iyonix) in the Trinity font but as arrows in the System (sic) font. That’s what I would expect. Not sure what you are trying to do.

I am just trying to display a window from an application (Keystroke) that has some icons which contain these characters. I know they are not in my desktop font … but they display ok in RO4.39 and not in my RO5.20. They should display correctly by some Wimp magic as WPB says, but I have lost the magic somehow.

but they display ok in RO4.39 and not in my RO5.20.

Do they display correctly in RISC OS 3.70?

It is possible that RO4 is intercepting these characters and replacing them with the expected symbols? I can understand the Wimp doing this in things that it alone handles (menus, for instance), but would it also apply this to icon text and such?

I think the Wimp handles this automatically for any text it renders without your app’s intervention – menus, icon text, etc. Obviously if you’re painting strings yourself, you have to make your own arrangements.

Maybe a screenshot would clarify the situation, Martin?

Is WIMPSymbol listed by *FontList?

Yes, WIMPSymbol is in FontList – I can use it from XChars, Edit etc.

Here is an example from RO4.39 which is what it should look like…

Here is an example from RO5.20 which is what it should not look like…

(The example is using Select on Keystroke iconbar icon to get Keystroke Definition window then select ‘Insert text’ to get a bottom pane. Same Sassoon font in both cases.)

The problem is the use of Sassoon for your desktop font. It defines glyphs /orn.002 through /orn.005 in the base encoding, so the Wimp doesn’t make substitutions. I’m not sure yet why it works on RO4 but not RO5. It’s either due to the changes to the way encodings and Encoding files are dealt with in the UCS Font Manager, or the Wimp’s behaviour has been changed. Probably it will be possible to tell by looking at CVS.

Do either of these modified Sassoon fonts fix the problem? (I only modified the .Primary face, not the bold one.)

• Sassoon_ForWimp1, which has those glyphs removed from the Outlines file.

• Sassoon_ForWimp2, which leaves the glyphs in the file, but gives Sassoon its own Encoding file, in which the glyphs are marked as “notdef”.

They seem to work on my system (5.21, RPCEmu). Let me know if they work on yours.

I have tried the fonts you made available. I had some bother with font install not telling me it was not doing the merge, either because they were locked, or newer than the installed one, or in use. So I deleted Sassoon from my !Fonts directory and re-booted. Then I created a temporary !Fonts directory with Sassoon containing my original fonts, Sassoon1 your Wimp1, and Sassoon2 your Wimp2. I then used that with the Fonts configure Install.

Of the 6 Sassoon fonts that were now available, the only one which worked was the Sassoon1.Primary. So it seems removing the glyphs fixes the problem! I have just noticed that Sassoon.Primary.IntMetric0 has ‘Copyright 1989-1993 The Electronic Font Foundry’ at the end, which explains where they come from.

Strange thing is that I have just copied Sassoon from RO439 and it does not work on RO520 … and the IntMetrics and Outlines files are identical!! So the same physical font works on RO439 but not on RO520.

Thanks for your help – what did you use to remove the glyphs?

You probably didn’t need to bother installing them the “official” way – sorry I should have mentioned that. Just replacing the original Sassoon directory in !Fonts would have sufficed and saved some bother by the sounds of it.

I just used !FontEd to remove the glyphs. Simple once you figure out that you have to drag an undefined “glyph” over the one you want to remove. Not sure how you’d do it if there were no undefined glyphs in the font. There’s no “delete” menu option anywhere!

The fonts could be identical and work on RO4 but not RO5, because of the changes to the Font Manager to support UCS fonts, and possibly changes to the Wimp. (I’m not sure about that, but I’m speculating there may have been changes, given that this has broken.)

Thanks. I will have a hunt around for FontEd – I am sure I have (had?) it somewhere. Does it work on RO5 (ie 32 bit?).

It’s in CVS here, and it has been updated to cope with UCS fonts, and is 32-bitted. It would be good if it could be added to the disc build.

I have found what I think is an older !FontEd version 0.34 dated 29 Nov 2001 which seems to run. (It was in a pre-5.20 Utilities directory!). If that is sufficient, I think it would avoid me having to try to build a later version.

However, WPB said ‘remove the glyphs’. That word is not in the !FontEd !Help and I am afraid I not sure what it really means! The two fonts look identical to me – they both seem to show the same characters but I may be looking in the wrong place!

It would be nice to know what the Wimp actually uses to determine whether it displays in WimpSymbol of the Desktop font. Most of the relevant code seems to be in Wimp.s.Wimp04, but I have not managed to fathom out its cunning plan!

Does this help?

I think that for any alphabet except UTF-8, the Unicode Wimp switches to WimpSymbol if:

• &80, &84, &88, &89, &8A or &8B is in the string
• That codepoint is not defined in the current alphabet
  OR
• there is no such glyph defined in the current font

Does this help?

Yes thanks … I was looking in the wrong place.
Presumably ‘glyph’ == ‘character’ for us simple souls?
Just drag an empty one over the offending ones?

Presumably ‘glyph’ == ‘character’ for us simple souls?

In my head, yes, pretty much. Though someone with a stricter understand (nemo, I’m waiting for you to jump in) may well tell me off!

Just drag an empty one over the offending ones?

That seemed to do the trick, yes. No mention of it in the !Help file, though. I had to scratch my head a few times before I figured it out!

It’s arguably easier to do it the second way I proposed above, with a unique Encoding file for the Sassoon font which makes it look like those glyphs/characters are not defined.

That seems to have done the trick! Many thanks for your help.
It is something which has bothered me on and off for years
… probably as I changed my mind … sorry … tried out different fonts.

Apologies for neglecting you all. I can always be prodded by Twitter if I’m not paying attention here (and I probably won’t be).

Presumably ‘glyph’ == ‘character’ for us simple souls?

In my head, yes, pretty much. Though someone with a stricter understand (nemo, I’m waiting for you to jump in) may well tell me off!

Never!

For the record, the glyph is the mark – the shape – the dot or squiggle or spiky thing you see. The character is what that mark represents. The hyphen and the soft hyphen characters (&2D and &AD respectively in Latin1) are different characters, but are (usually) the same glyph.

The distinction becomes important (beyond being right on the internet, dammit) when dealing with TrueType/OpenType fonts, and CID fonts in general. And it gets even more complicated in the PostScript world… but I’ll stop now.

Hee hee! What fun, I think I set a nemo trap. I just didn’t expect it to be such a slow burn! Good to see your presence here again, nemo.

What fun, I think I set a nemo trap

I think you have to use his real name three times to produce a trap. :)

I think you have to use his real name three times to produce a trap. :)

Steve, I’m not insane. I’d never do THAT! ;)