Currently, Fixedsys is the default font on Windows.
It is not suitable for recent High DPI environments.
msgid "DefaultFontNameForWindows"
msgstr "Courier New"
Close #12919
https://github.com/vim/vim/pull/13266
(3 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Merging #13266 (864604f) into master (b74ebfc) will increase coverage by
4.46%.
The diff coverage isn/a.
@@ Coverage Diff @@ ## master #13266 +/- ## ========================================== + Coverage 78.33% 82.79% +4.46% ========================================== Files 150 150 Lines 153287 182917 +29630 Branches 39519 41029 +1510 ========================================== + Hits 120076 151453 +31377 + Misses 20932 18486 -2446 - Partials 12279 12978 +699
| Flag | Coverage Δ | |
|---|---|---|
| huge-clang-Array | 82.79% <ø> (?) |
|
| linux | 82.79% <ø> (?) |
|
| mingw-x64-HUGE | ? |
|
| mingw-x86-HUGE | ? |
|
| windows | ? |
Flags with carried forward coverage won't be shown. Click here to find out more.
see 159 files with indirect coverage changes
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@k-takata pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@k-takata commented on this pull request.
In src/testdir/test_mswin_event.vim:
> - let args.col = 7
+ let args.col = 5
let args.move = 1
let args.cell = 1
call test_mswin_event("mouse", args)
call feedkeys("\<Esc>", 'Lx!')
let pos = getmousepos()
call assert_equal(9, pos.screenrow)
- call assert_equal(7, pos.screencol)
+ call assert_equal(5, pos.screencol)
Without this change, the following error occurs:
https://github.com/k-takata/vim/actions/runs/6406241128/job/17390448472#step:11:9232
From test_mswin_event.vim: Found errors in Test_mswin_event_mouse(): command line..script D:/a/vim/vim/src/testdir/runtest.vim[601]..function RunTheTest[54]..Test_mswin_event_mouse line 56: Expected 1 but got 2
Not sure why.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
@k-takata pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Is there a reason why we need to provide a localized default font? Is it just to enable Fixedsys for Japanese/etc locales (basing this from your comment on the linked issue)? I would imagine most Japanese programmers would still want to use something other than Fixedsys since it's not really the kind of font most people like to use these days. Does the font substitution mechanism in Windows not work well enough? I would imagine that is the recommended path for handling localization and the OS also has more leeway in determining how to properly substitute the font based on your locale instead of just relying on the font (e.g. "," looks different depending on which CJK locale you are using in the OS, which is information that the font doesn't have).
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
Is there a reason why we need to provide a localized default font?
I don't think about using Fixedsys at all.
I am considering using MS Gothic as the Japanese default font. It is the most widely used Japanese fixed-pitch vector font.
I think there are similar kinds of fonts for other CJK languages.
That's the reason why I'm going to provide a way to set a localized default font.
The problem might be that the ANSI part is not so beautiful compared to Consolas.
I guess one issue is that the substituted font is usually not a monospace font
Yes. The Japanese part is not shown well aligned if Consolas is used.
Using 'guifontwide' shows the ANSI part and the Japanese part very nicely. However, using 'guifontwide' has some pitfalls.
So, I don't want to make this the default.
set gfn=Consolas gfw=MS_Gothic

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Right. FWIW, part of the reason why I'm asking is that I'm changing how MacVim is rendering fonts and was looking at the GTK/Win32 code for reference.
I'm planning to change it so that in MacVim, if you do set guifont=Consolas,MSGothic, MSGothic will be chosen as a fallback font and automatically used when the first font doesn't support the Unicode value of the character you need (e.g. Japanese characters). Right now, the Vim fallback logic is just picking the first font in the list that loads, but it doesn't do per-character fallback. Doing this also kind of means guifontwide is unnecessary as you can just specify the entire fallback list you want in guifont. Only issue is you have to query the font to for every character you want to render to see if it's supported by the font you want, so I need to profile if there's a performance cost at all or whether caching is necessary.
Also, the existing behavior is also why people have to rely on patched fonts (e.g. Nerd Font) for Powerline etc because Vim can only load one font at a time. Terminals like Kitty actually already provide fallback font options so you can do what I just mentioned above and have Kitty automatically pick a font that supports the character you are typing. I think some terminals also support different Italic/Bold font as well (I think I may support that in MacVim as well using a special syntax in guifont, e.g. something like set guifont=Menlo:h12,Monaco:sItalic).
Sorry to get a little off topic, just wanted to share this before I work on it in case the Windows/GTK implementations of gVim may want something like that as well and want to share the syntax.
Yes. The Japanese part is not shown well aligned if Consolas is used.
Regardless of default font choice, I kind of feel like this could be fixed up? I think the Win32 code mandates fixed-width font right now but I never knew if there's a particular technical reason or whether it's just because it looks bad otherwise. The issue with the mandate is that the OS is going to internally substitute with a non-fixed-width font anyway when they try to render CJK characters (as was the case when you were using Consolas). Is it something that could be fixed up in the font rendering code to make them align better? I haven't touched the Win32 font rendering code so I don't have a lot of contexts.
Also, just curious how are you generating that list of CJK / Hiragana / Katakana etc symbols? Is that a custom script / file you use?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Also, just curious how are you generating that list of CJK / Hiragana / Katakana etc symbols?
:dig!
This is useful when checking the font rendering. (This doesn't include Kanji / Hanzi, though.)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@k-takata pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@k-takata pushed 3 commits.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@k-takata pushed 1 commit.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@k-takata pushed 2 commits.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@k-takata pushed 2 commits.
—
View it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@k-takata commented on this pull request.
In src/testdir/test_mswin_event.vim:
> - let args.col = 7
+ let args.col = 5
let args.move = 1
let args.cell = 1
call test_mswin_event("mouse", args)
call feedkeys("\<Esc>", 'Lx!')
let pos = getmousepos()
call assert_equal(9, pos.screenrow)
- call assert_equal(7, pos.screencol)
+ call assert_equal(5, pos.screencol)
The font size of Consolas is smaller than Fixedsys when the DPI is 100%.
So, this can happen.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()
thanks!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()