The character "1" appears to be handled differently with the Print statement

Unlike any other character, including all the other decimal digit characters, is handled weirdly by the Print statement, in what appears to be a bug. If you have the code:

Code:

---

Print "1"; "1"; "1"; "1"
Print "1111"

---

Those two lines of code SHOULD produce identical outputs. However (at least with VB6's default Font for Form1, which is Arial) the result is that the Print statement with 4 concatenated "1" characters is used the digits are displayed as separated slightly more from each other, compared to when the single string "1111" is displayed via the Print statement. I've tried the other numbers, and even skinny letters like "l", but none of those produce this same discrepancy. So I'm guessing this is a bug.

Can't reproduce. Form font is using the default of MS Sans Serif. Using VB 6.0 SP5 on a VM running Windows 2000 Server w/ SP4.

The code produces "pixelly identical" output, verified in MSPaint at a ridiculous zoom level.

I could reproduce it. Only with Arial normal. It didn't happen with:
Segoe UI
Arial Narrow
MS Sans Serif
Microsoft Sans Serif
Tahoma
Verdana

The VB6 default font for forms is MS Sans Serif, not Arial. Arial is the default font for the Printer object.

Quote:

---

Originally Posted by Eduardo-

I could reproduce it. Only with Arial normal. It didn't happen with:
Segoe UI
Arial Narrow
MS Sans Serif
Microsoft Sans Serif
Tahoma
Verdana

The VB6 default font for forms is MS Sans Serif, not Arial. Arial is the default font for the Printer object.

---

Whoops, I didn't even catch the mention of Arial in the first post. I changed the font to Arial and was unable to reproduce it. But I'm using an old OS in a very standard "classic" video resolution. I would guess this is somehow related to modern high resolution monitors and DPI scaling.

Code:

---

Private Sub Form_Load()
    Me.Font.Name = "Arial"
    Me.Font.Size = 16
    Me.AutoRedraw = True
    Print "1"; "1"; "1"; "1"
    Print "1111"
    Print
    Print "TwipsPerPixel: " & Screen.TwipsPerPixelX
End Sub

---

96 DPI (100%):

Attachment 196265

120 DPI (125%)

Attachment 196266

Windows 11 22H2

Quote:

---

Originally Posted by OptionBase1

Whoops, I didn't even catch the mention of Arial in the first post. I changed the font to Arial and was unable to reproduce it. But I'm using an old OS in a very standard "classic" video resolution. I would guess this is somehow related to modern high resolution monitors and DPI scaling.

---

I'm using Windows 10 (yes VB6 works even on that), and MS Sans Serif isn't even an available font (maybe is obsolete/discontinued on modern versions of Windows), so VB6 must have picked the next best option, Arial. I'm not sure what Windows version you were using to test this.


I don't have a DPI setting (such as 96 DPI) in Windows 10. Instead I have a scale factor (such as 100%). I'm using the default of 100% for the scale factor.

Quote:

---

Originally Posted by Ben321

I'm using Windows 10 and MS Sans Serif isn't even an available font

---

Yes, it is. It is on every Windows version.
Maybe there is a problem with your Windows 10 installation.

Attachment 196267

Quote:

---

Originally Posted by Ben321

I don't have a DPI setting (such as 96 DPI) in Windows 10. Instead I have a scale factor (such as 100%). I'm using the default of 100% for the scale factor.

---

That is, 100% is 96 DPI.

Quote:

---

Originally Posted by Eduardo-

Yes, it is. It is on every Windows version.
Maybe there is a problem with your Windows 10 installation.

Attachment 196267



That is, 100% is 96 DPI.

---

On my computer on my copy of visual basic, I don't find "MS Sans Serif" but I do find "Microsoft Sans Serif". So it seems that it is on my PC but under a name that VB6 isn't looking for, so it defaults to Arial.

And indeed when I manually switch to "Microsoft Sans Serif" the issue about the 1's printing differently based on if I use Print "1"; "1"; "1"; "1" or Print "1111" goes away.

The problem must be your locale configuration, and more particularly how to handle non Unicode programs. Windows 10 is hiding that font because of your Windows configuration.

Anyway, I don't know what you want. If it is to make note that strange behavior of Print method with the Arial font, yes, that's strange.

By default the kerning pairs fearture is disabled in DC but it seems Print uses it:
...

Edit: invalid test

I tested in BSPrinter that has a property FontKerning that allows to disable the kerning and it does not do the issue with kerning disabled.

Thanks for checking, I wasn't sure if kerning was actually being applied but clearly not.

Maybe it depends on the API used internally DrawText or ExtTextOut which act differently in certain contexts and repreduce the two behaviors

Quote:

---

Originally Posted by anycoder

Thanks for checking, I wasn't sure if kerning was actually being applied but clearly not.

---

I'm saying that it is the kerning (not the opposite).