TSE: Windows: Changing fonts shows side-effects in 4.47

11 views
Skip to first unread message

knud van eeden

unread,
Nov 25, 2022, 11:47:30 AM11/25/22
to SemWare TSE Pro Text Editor
Hello,

When opening a very large file (1.1 gigabytes) in a clean TSE beta 4.47
it shows kind of like shadow line numbers and white area gaps in the menu (see screenshot).

Important: This can be reproduced in the latest clean TSE 4.47
           but NOT in e.g. clean TSE 4.42.00

           Because it seems to have worked as expected in at least one earlier
           version, this might thus be something that has for some reason
           be introduced in e.g. the latest 4.47 version of TSE.

                  1 screenshot shows it in 4.47

                  1 screenshot shows that it is not there in 4.42.00, doing the same steps.          

===                 

Reproduction:

1. Load a very large file (1.1 gigabytes) into TSE 4.47

2. Change the font from 'Courier New' to 'Terminal' (bold and size 9) (change the font by clicking on the TSE icon in the top left corner of the window then > 'Set Font...' > 'terminal' > '9' > 'bold')

3. Then open e.g. the TSE menu > choose 'Window' and it should probably show the effect (see screenshot)

---

Thanks
with friendly greetings
Knud van Eeden

Inline image

Inline image

S.E. Mitchell

unread,
Nov 25, 2022, 12:14:55 PM11/25/22
to TSEPro Support
And it doesn't happen with smaller files? I'm having a hard time finding the connection between filesize and menu display. Totally stumped actually. 
--
Sammy

--

---
You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/semware/245937170.2908677.1669394844402%40mail.yahoo.com.

knud van eeden

unread,
Nov 25, 2022, 1:07:22 PM11/25/22
to TSEPro Support
> Sammy wrote:
> And it doesn't happen with smaller files? I'm having a hard time finding the connection between filesize and menu display. Totally stumped actually. 

I will check now after with a space " " filled text file of the same file size (to be sent as a .zip file then if reproducible) if I still can reproduce it.

I will check the different latest versions since and included 4.42.00 and let it be known.

Carlo Hogeveen

unread,
Nov 25, 2022, 1:10:26 PM11/25/22
to sem...@googlegroups.com

It is a semi-known bug.
I can reproduce it with an empty file.
Give me a few moments to document it properly.

Carlo



knud van eeden

unread,
Nov 25, 2022, 1:35:51 PM11/25/22
to TSEPro Support
Inline image

I will check the different latest versions since and included 4.42.00 and let it be known.

Result:

1. The effect starts at 4.45.00, then also 4.46.00, now also in 4.47.00

2. The effect is NOT present in tested versions e.g. 4.43.00, 4.42.00, ...

3. Conclusion starting from 4.45 there were some changes in this regard probably, compared with its 4.43.00 and earlier versions.

4. Attached the used much smaller zipped file (ddd.zip, unzip to ddd.txt and use that file) used to reproduce the above.


with friendly greetings
Knud van Eeden


ddd.zip

Carlo Hogeveen

unread,
Nov 25, 2022, 2:44:46 PM11/25/22
to sem...@googlegroups.com

The bug is easily reproduced in GUI TSE by installing the latest TSE version with default installation choices to a new folder, and change the font to "Terminal Bold".

The bug starts appearing in GUI TSE 4.44.

Relevant requirements for this variant of the bug:
- The font is Terminal Bold.
- The options "Use 3D Characters" and "Use 3D Buttons" are both OFF.
- After changing one of the 3D options, TSE settings needs to be saved, and TSE needs to be restarted for them to have effect.

I know this bug, because the Uniview extension encountered a same bug when using the Unifont font (which I advise against!).

The problem seems to be, that for some fonts, like Unifont and Terminal Bold, TSE displays some characters not wide enough, i.e. too thin, resulting in gaps to the right of them.

Based on Sammy's suggestions at that time, I can offer a work-around for the new variant of the bug, which works by changing TSE's output [display] driver for the relevant font.

Put the below code in an autoloaded macro, and restart TSE.

Carlo



#ifndef INTERNAL_VERSION
#define INTERNAL_VERSION 0
#endif

proc WhenLoaded()
string startup_font_name [MAXSTRINGLEN] = ''
integer startup_font_size = 0
integer startup_font_flags = 0

// For this functionality only TSE's start-up values matter!
GetFont(startup_font_name, startup_font_size, startup_font_flags)

if isGUI()
if startup_font_name == 'Terminal'
and (startup_font_flags & _FONT_BOLD_)
// The SetOutputDriver() command was introduced after TSE 4.40 and
// before the introduction of the INTERNAL_VERSION compiler directive
// in TSE 4.41.44. So the least-bad thing we can do is test for the
// existence of INTERNAL_VERSION before using SetOutputDriver().
// We cannot use #ifdef here, because inside an #ifdef old TSE versions
// still see and raise a compile error for _DRIVER_BMPFONT_.
#if INTERNAL_VERSION
SetOutputDriver(_DRIVER_BMPFONT_)
#endif
endif
endif
end WhenLoaded



knud van eeden

unread,
Nov 25, 2022, 2:54:11 PM11/25/22
to sem...@googlegroups.com
> Carlo wrote:
> The problem seems to be, that for some fonts, like Unifont and Terminal Bold, TSE displays some characters not wide enough, i.e. too thin, resulting in gaps to the right of them.

Smart. 

That seems to be a very plausible root cause at this moment.

S.E. Mitchell

unread,
Nov 25, 2022, 6:07:39 PM11/25/22
to sem...@googlegroups.com
I found the problem.
The bug is caused by a change I made to try and better support
odd-ball fonts and characters, and unicode characters, for instance
via the unifont font.
In prior versions, I would set the character width and height via the
GetTextMetrics() function:

GetTextMetrics(hdc, &tm);
g->char_height = tm.tmHeight;
g->char_width = tm.tmAveCharWidth;

In v4.44, I started using:

GetTextExtentPoint(hdc, "W", 1, &sz);
g->char_height = sz.cy;
g->char_width = sz.cx;

If I revert back to the old code, Terminal Bold looks ok, but Unifont
looks horrible, kind of like Terminal Bold looks now.

So, pick your poison. I'm open to suggestions!
--
Sammy
> --
>
> ---
> You received this message because you are subscribed to the Google Groups "SemWare TSE Pro text editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to semware+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/semware/002f01d90106%245d78a700%241869f500%24%40ecarlo.nl.

knud van eeden

unread,
Nov 25, 2022, 6:39:51 PM11/25/22
to sem...@googlegroups.com
> Sammy wrote:
 I'm open to suggestions

Making it a configurable setting, yes or no or 1 2 3 4 5 ...
using Set() or similar.

Carlo Hogeveen

unread,
Nov 25, 2022, 6:46:16 PM11/25/22
to sem...@googlegroups.com

Sammy,

My suggestion is, that given the work-around I just posted, we do not have to exclude either Unifont or Terminal Bold.

As is, the newer TSE versions work OK-ish with Unifont, and the work-around can be used for Terminal Bold. A reverse is not possible AFAIK.

I cannot judge whether it makes sense to build the work-around into TSE, or whether that is overkill.

Carlo
To view this discussion on the web visit https://groups.google.com/d/msgid/semware/CA%2BgEvkYmLOBtqO6_W6vcnxka8iTFFGcs485%3DLe3TUPnv5V1fHQ%40mail.gmail.com.

knud van eeden

unread,
Nov 25, 2022, 7:54:42 PM11/25/22
to sem...@googlegroups.com
In general I would say, whatever the implementation (e.g. in TSE itself or using external TSE SAL source code) it should thus obviously try to avoid a situation like seen in the earlier screenshots, e.g. regarding the menu boxes, given the impression of corruption somewhere.

And users changing fonts while in TSE is not a never occurring situation.

Unicode fonts are relatively probably not important so could get less priority, as the current implementation of TSE does not include Unicode characters anyhow, with a few Unicode character exceptions
for the first pages of Unicode.

The only application and successful usage of Unicode is in a few TSE user created implementations thus at this moment.

S.E. Mitchell

unread,
Nov 25, 2022, 8:37:41 PM11/25/22
to sem...@googlegroups.com
I wish there was some kind of characteristic of the font that I could
check so I could know which method to use.
I'll study the returned TextMetrics structure, to see if I notice any
significant differences between the various fixed width fonts that
might give me a clue.
--
Sammy
> To view this discussion on the web visit https://groups.google.com/d/msgid/semware/000601d90128%241a51fa40%244ef5eec0%24%40ecarlo.nl.

S.E. Mitchell

unread,
Nov 26, 2022, 9:50:38 AM11/26/22
to sem...@googlegroups.com
After doing some research, I wrote a test program, to
show the name, average char width, max char width, and computed
char width of "W" of all fixed width fonts on my system.

After running uniq, sorting, and grouping, I get:

ACW = average char width
MCW = maximum char width
sz.x = computed char width of "W"

These have the same values:
Courier ACW 9 MCW 9 sz.x 9
Fixedsys ACW 8 MCW 8 sz.x 8
Lucida Console ACW 10 MCW 10 sz.x 10
Lucida Sans Typewriter ACW 10 MCW 10 sz.x 10
r_ansi ACW 10 MCW 10 sz.x 10
r_control ACW 10 MCW 10 sz.x 10
r_symbol ACW 10 MCW 10 sz.x 10
Terminal ACW 12 MCW 12 sz.x 12

These differ in average and max:
@MS Gothic ACW 8 MCW 32 sz.x 8
@NSimSun ACW 8 MCW 16 sz.x 8
@SimSun-ExtB ACW 8 MCW 16 sz.x 8
Cascadia Code ACW 9 MCW 36 sz.x 9
Cascadia Code ExtraLight ACW 9 MCW 36 sz.x 9
Cascadia Code Light ACW 9 MCW 36 sz.x 9
Cascadia Code SemiBold ACW 9 MCW 36 sz.x 9
Cascadia Code SemiLight ACW 9 MCW 36 sz.x 9
Cascadia Mono ACW 9 MCW 36 sz.x 9
Cascadia Mono ExtraLight ACW 9 MCW 36 sz.x 9
Cascadia Mono Light ACW 9 MCW 36 sz.x 9
Cascadia Mono SemiBold ACW 9 MCW 36 sz.x 9
Cascadia Mono SemiLight ACW 9 MCW 36 sz.x 9
Consolas ACW 9 MCW 18 sz.x 9
Courier New ACW 10 MCW 12 sz.x 10
MS Gothic ACW 8 MCW 32 sz.x 8
NSimSun ACW 8 MCW 16 sz.x 8
SimSun-ExtB ACW 8 MCW 16 sz.x 8

These differen in all 3 values:
@Unifont ACW 15 MCW 31 sz.x 8
Unifont ACW 15 MCW 31 sz.x 8


Based on this, what I'll do for now is, if the average char width
equals the maximum char width, I'll use average char width.
Otherwise, I'll use the computed char width of "W".

At least on my system, the only font this impacts is Unifont (and
whatever @Unifont is).

--
Sammy

S.E. Mitchell

unread,
Nov 26, 2022, 10:13:27 AM11/26/22
to sem...@googlegroups.com
Just to be clear - this will handle all special cases that I am
currently aware of, e.g., Terminal Bold should display as it used to,
and Unifont should also keep working.
--
Sammy

Carlo Hogeveen

unread,
Nov 26, 2022, 11:04:24 AM11/26/22
to sem...@googlegroups.com

Hopefully a superfluous suggestion:

Test this with both 3D display options OFF and settings saved and TSE restarted,
and with both 3D options ON and settings saved and TSE restarted.

(I sent my enumerated font list privately.)

Carlo


-----Original Message-----
From: sem...@googlegroups.com <sem...@googlegroups.com> On Behalf Of S.E. Mitchell
Sent: zaterdag 26 november 2022 16:13
To: sem...@googlegroups.com
Subject: Re: [TSE] TSE: Windows: Changing fonts shows side-effects in 4.47

Reply all
Reply to author
Forward
0 new messages