Menu
▾
▴
#38 wx3270 response times always use 3270 font
Tested in 1.1ga5.
wx3270 uses the 3270 font by default but users can choose a different font in their profile. When a different font is chosen, the 3270 font is still used to correctly display symbols in the OIA area but other details like the luname and cursor position are displayed in the selected font.
When "show timing" is enabled, the timing is displayed with a clock symbol and the response time. Both of these components are displayed using the 3270 font but it would be more correct for the clock symbol to be in the 3270 font and the response time value in the font specified in the profile. It would then look more consistent with other information displayed in the OIA.
I would call this an enhancement request rather than a bug. The entire OIA is drawn using the 3270 font, if it is available. The downside of this is, as you mention, text fields being drawn in a font that is different from the main display.
The potential downside of mixing fonts in the OIA comes when the display font and the 3270 font are not actually compatible, e.g., they have different baselines, heights or weights even though their font metrics appear to be the same. The result of this is a lot uglier than seeing the response time and LU name in a vintage 3278 font.
Hi Paul,
firstly thank you for fixing the other issues I've reported so quickly, I'm definitely looking forward to the next version release.
In the attached example, I have selected Lucida Console as my font. My issue was that all alphanumeric text in the OIA was in the chosen font except the response time (and thus it looked inconsistent) but I see that is not true as characters like "A" for alt, "T" for typeahead are also in the 3270 font.
(I've tried to like the new 3270 windows font but I'm so used to the fonts in x3270 that I find the windows font a little blurry and hard to look at for long periods. I'm not sure but when looking at the fonts really closely it might have been some windows font smoothing that is causing it to look that way.)
I don't think it is worthy of an enhancement request, so I withdraw the issue.
I would like to ask briefly about unlockDelay (I'm not sure it is a bug but I have seen some unusual behaviour). The documentation indicates that the default for unlockDelay is now false in all emulators but it was defaulting to true in my wx3270 install. I disabled it and thought I had noticed that keypresses were occasionally lost (but I have no evidence of this). Then when I was looking at the OIA just now and saw the typehead indicator "T" I noticed something unusual.
With unlockDelay false, I was in SDSF with auto update "&30" turned on. I typed some characters (eg. "aaa") which shows "T" in the OIA to indicate data in the typeahead buffer. I then hit attention to cancel the auto update and I expect the text in the type ahead buffer to appear on the command line. But it doesn't and "T" remains in the OIA. Now the next time I press an AID character and the screen updates, the text in the type ahead buffer appears (and the "T" is cleared). So with unlockDelay set to false I am seeing the buffer delayed until the next AID in some circumstances. When I tested with unlockDelay true, the type ahead buffer was output on the screen after the attention as I would have expected. This appeared to work in my testing even if unlockDelayMs was a small non-zero value like 1.
So I'm not sure if this behaviour is actually a bug or maybe a timing issue, but I think I will be going back to unlockDelay true and possibly unlockDelayMs 1 as I don't like the fact that I can enter anything other than attention and have it processed ahead of text previously entered in the typeahead buffer.
I haven't attempted to reproduce this under x3270, but the x3270 I use under cygwin is very old.
Thanks again.
(1)
Now that I've looked at your report again, I will say that this is probably a bug.
The OIA is made up of fields, and wx3270 displays some OIA fields using the main display font, and others using the 3270 font. Unfortunately, the timing field is mixed -- the clock symbol (which is exclusive to the 3270 font) and a count -- and both parts are displayed in the 3270 font, which does look odd. I will see how hard this is to fix properly.
(2)
I agree that the 3270 font does not scale cleanly on Windows. For some sizes it's sharp, but for others it's not. I used FontStruct to create it; perhaps there are better tools available to create scalable versions of old bit-mapped fonts.
(3)
I don't know why I set unlockDelay to true in wx3270. It should not be set that way. Please open a separate bug report on this and I will fix it.
There is no reason for unlockDelay to be on for interactive use. Its original purpose was for macros and scripts, and 99% of the time it is no longer needed in those cases, either. (And when it is needed for macros and scripts, there are simple alternatives that do not slow down every single AID sent to the host.)
(4)
I agree that unlockDelay is probably complicating your typeahead issue. Its net effect is to make keystrokes end up in the typeahead buffer more often when you are typing quickly. That in itself should not be a problem, but it does not serve a useful purpose.
The ATTN key does not interact with typeahead directly. That is, your keystrokes end up in the typeahead buffer when the keyboard is locked; when you press ATTN the host unlocks the keyboard, which then causes the emulator to run the typeahead buffer.
There could certainly be subtle bugs in this area. If you could capture a data stream trace of possible misbehavior in this area, I would very much appreciate it -- again, in a separate bug report.
The OIA mixed-font issue has been fixed and will be released in wx3270 1.2ga5. The font scaling issue has been addressed by including Ricardo Bánffy's IBM 3270 font in 1.2. And unlockDelay is now false by default (this happened sometime during 1.2 development).