[Bug] In Windows 10, application windows display errors.

[sr79368142]

Hello, @OlaProeis, after opening the app on Windows 10, the menu bar, toolbar, and other elements in the main window are misaligned. I've recorded and uploaded a GIF showing this issue—you can see the mouse cursor needs to be moved upward when clicking on these components. How can this be resolved?

Also, how can I set a custom font for the application? I'm using a Chinese system, and all opened files display as “囗囗” characters—very strange?

Every time I drag an MD document onto an application, it reopens a new window instead of displaying in the window where it was first opened. How can I make the file open in a multi-tab window?

Finally, I have a small feature request: could you add an option for custom line width? Reading long paragraphs is very straining. Limiting the line width would be great! 😊😊😊

Thank you so much for developing such an excellent and outstanding application—it's made life easier for many users!!

Sincerely, Wishing you smooth sailing in all endeavors and good fortune every day!

[OlaProeis]

Thanks for the detailed report and the GIF! Let me address each part:

1. UI Misalignment Bug + 2. Chinese Characters as Boxes

These two issues are likely related! When Chinese characters can't render (showing as "囗囗" boxes), the fallback font has different dimensions than actual CJK glyphs. This can throw off the entire UI layout, causing the click offset you're seeing.

We have a fix ready in PR #8 which adds CJK (Chinese/Japanese/Korean) font support via system fonts. This will be included in v0.2.3 which is coming very soon!

Once CJK fonts render correctly, the UI alignment issue should also be fixed. Please let us know if the problem persists after updating to v0.2.3!

3. Custom Line Width

Excellent suggestion! We have a Zen Mode (View → Zen Mode or Ctrl+Shift+Z) that centers text in a narrower column. Would that help for now?

I've added configurable line width to the v0.2.3 roadmap as well.

Thank you for using Ferrite and for the kind words! 😊 祝你一切顺利！

[sr79368142]

3. Custom Line Width
   Excellent suggestion! We have a Zen Mode (View → Zen Mode or Ctrl+Shift+Z) that centers text in a narrower column. Would that help for now?

dear @OlaProeis , Following your suggestion, I tried using Zen Mode, but it only supports Source and Edit modes—not View mode. In View mode, long paragraphs still wrap at the window edges. Could this be related to the bug mentioned earlier? Is it caused by the font?
Thank you so much for your prompt assistance in resolving this issue. I hope your software continues to improve, and I'm really looking forward to the bright future of this outstanding application! 😄😄😄

[OlaProeis]

Thanks for the detailed report @sr79368142! 🎉

v0.2.3 is now released and addresses your line width request! You can now configure line width in Settings (Ctrl+,) → Editor → Line Width with presets (80/100/120 chars) or a custom value. Text is centered in the viewport for comfortable reading.

Regarding your other issues:

• CJK font rendering (Chinese characters as "囗囗") - This was fixed in v0.2.3! CJK characters (Korean, Chinese, Japanese) now render correctly using system font fallback. Please update to v0.2.3.

• Menu bar/toolbar misalignment on Windows 10 - This is a separate issue we need to investigate. Could you please open a new issue with your Windows 10 version, display scaling settings (100%, 125%, 150%?), and screen resolution? This would help us reproduce and fix it if its not already fixed by the font rendering.

Thank you for your kind words and using Ferrite!

[sr79368142]

Dear @OlaProeis , I just downloaded the latest Nightly build. The font and line width issues have been perfectly resolved, but the window display error remains unresolved. Additionally, when customizing line width, the left-hand line number column and folded columns still appear in the middle instead of along the border. I'm unsure if this is normal behavior?

Based on my experience, many text editors display the fold column inside the line number column—that is, on the right side. Have you considered swapping the positions of these two toolbars?

My system is Windows 10 22H2 build 19045.6466. Since Windows 10 is no longer supported, I haven't updated it since the second half of last year. Do you need logs? Ferrite appears to be a single executable file, and I haven't found any related log files on my computer. I also didn't see any log settings in the preferences.

[OlaProeis]

Thanks for the follow-up and glad the font and line width issues are fixed!

Two things to address:

1. Line numbers/fold column in the middle - You're right, that's not ideal. When line width is limited, the gutters (line numbers and fold indicators) should stay anchored to the left edge of the text area, not float in the middle of the window. I'll look into fixing that.

And good suggestion about putting the fold column to the right of line numbers instead of left - that matches what VS Code and other editors do. I'll consider swapping them.

2. The window click offset issue - This one is harder to debug remotely. A few things that might help:
   • What's your display scaling percentage? (Right-click desktop > Display settings > Scale)
   • Are you running single or multiple monitors?
   • Does it happen immediately on launch or only after certain actions?

For logs, you can run Ferrite from command line with: ferrite --log-level debug
That will output debug info to the terminal. If you can reproduce the offset issue and share what shows up, that might help narrow it down.

Alternatively if you could record a short video showing exactly where you click vs where the button highlights, that would help me understand the offset.

Thanks for sticking with this!

[sr79368142]

Hello, respected @OlaProeis!
I am using a single display screen, and the display scale is set to 100%.
The GIF I sent in my feedback is meant to show the window error; this GIF actually records the entire window.
You can see that every time I move the mouse, I have to move it up a little bit to select the button icons on the toolbar. Also, the top title bar is completely blank, and all the content has shifted downward, including the title and the three main window buttons on the right.
I am not at my computer right now, please forgive me!
I might not be able to do it until the evening; once I get back, I will immediately enable the logs and submit them.
Sincerely!

[OlaProeis]

This looks like a Windows DWM (Desktop Window Manager) frame offset issue specific to certain system configurations. Even with decorations disabled, Windows sometimes reserves space for a "ghost" title bar, causing:
Content to shift down
Click positions to be offset from visual positions
A few more diagnostic questions that would really help:

GPU: What graphics card/driver are you using? (Intel/NVIDIA/AMD?)

Quick test: Could you try running Ferrite in compatibility mode? (Right-click ferrite.exe > Properties > Compatibility > try "Windows 8" mode)

Registry check (optional): Do you have any custom DPI or window scaling settings applied system-wide?

Also, when you get the debug logs with ferrite --log-level debug, please also include the output of this PowerShell command:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' | Select-Object ProductName, ReleaseId, CurrentBuild, UBR

This is a tricky issue to fix remotely since it depends on how Windows reports the window frame on your specific configuration. I'll investigate options like:
Explicitly setting DPI awareness mode in the manifest
Adjusting how we handle the non-client area offset

Thank you for your patience - borderless windows + Windows = sometimes painful!

[sr79368142]

dear @OlaProeis ,I followed your instructions, first trying compatibility mode, but that didn't resolve the issue. Then I checked the display settings in System Settings to ensure all parameters were default and hadn't been modified.

After entering the first command “ferrite --log-level debug” in PowerShell, Ferrite launched, but I couldn't locate any log files. I only found the application's data folder in Roaming: “C:\Users\Mate Meber\AppData\Roaming\ferrite”;

After entering the second command in PowerShell: Get-ItemProperty -Path ‘HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion’ | Select-Object ProductName, ReleaseId, CurrentBuild, UBR, it displayed my system version?

In the config file, I saw the following parameters:

  “window_size”: {

    “width”: 1920.0,

    “height”: 1056.0,

    “x”: -8.0,

    “y”: -8.0,

    “maximized”: false

  },

A small request: Could you add settings for portable mode? As a single-file application, it would be convenient to store related configuration and data files within the installation folder.

Currently, the application's window height cannot be adjusted, though the width is fine. There are black borders on the left and top edges. When using a light theme on a dark system background, these borders are very noticeable:

[OlaProeis]

Thank you so much for your persistence with this issue.

After investigating extensively, I believe I've identified the root cause. This is a Windows DWM (Desktop Window Manager) frame offset issue that affects certain Windows 10 configurations when using borderless windows.

When an application uses a borderless window (no native title bar), Windows DWM still internally reserves an invisible ~8 pixel border around the window for shadows and resize handles. On most systems, this is handled transparently. However, on your specific Windows 10 22H2 configuration, the coordinate system isn't being properly adjusted, causing:
Visual content to shift down - creating the black bar at the top

• Click positions to be offset - you need to click above where buttons visually appear
• The -8, -8 position in your config - confirms Windows is including this "ghost frame" in calculations

Why It's Hard to Reproduce
This issue depends on a combination of factors specific to your system:

• Windows 10 22H2 build 19045.6466
• Your graphics driver and adapter
• Possibly specific Windows DWM composition settings
• Since Windows 10 support ended, these edge cases may not receive fixes from Microsoft, making them harder to work around.

Questions That Would Help

• What graphics card/driver are you using? (Intel/NVIDIA/AMD? Driver version?)
• Have you tried updating your graphics driver? Sometimes driver updates affect how DWM behaves
• Windows Visual Effects: In System Properties → Performance Options, what's selected? "Let Windows choose" or custom settings?
• DWM Composition: Is there any software that might affect DWM (like DisplayFusion, actual window managers, etc.)?

Temporary Workaround to Try

Could you try editing your config file (C:\Users[YourName]\AppData\Roaming\ferrite\config.json) and:

• Remove or set "x": null, "y": null in the window_size section
• Remove the "maximized": false line
• Save and restart Ferrite

This will make Ferrite use default window positioning instead of the saved position that includes the offset.

I'm planning to:

Update to the latest egui 0.32 (from 0.28) which may have fixes for this
Add a Windows-specific workaround to detect and compensate for the DWM frame offset
Potentially add a "window offset correction" setting for affected users
Your patience and detailed reports are incredibly valuable - this is exactly the kind of edge case that's impossible to find without users like you helping debug!
祝你好运！/ Good luck!

[sr79368142]

@OlaProeis , My computer is five years old with a GTX 950 graphics card. I've disabled all visual effects except mouse shadow and have never used any window management applications.

I followed your instructions for testing, but none of the operations worked. Furthermore, after closing the application each time, the config.ini file reverts to the following:

“window_size”: {

“width”: 1920.0,

“height”: 1056.0,

“x”: -8.0,

“y”: 0.0,

“maximized”: true

},

If this is due to outdated hardware, I sincerely apologize. Should the error persist after your next update, I will test it on other computers.

[sr79368142]

In dual-pane mode, the line width feature has a bug: in view pane line breaks occur only at the specified character count, not at the edge of the pane. If disabled, automatic line breaks work correctly. However, when the line width is set enabled, characters in the viewing pane continue displaying until they reach the specified character count before breaking. I've uploaded screenshots where you can see the difference:

disabled：

enabled：

[sr79368142]

I still need to submit two additional reports:

1. This concerns rendering issues with the Chinese input method. Within the Chinese input method, the IME candidate box is incorrectly positioned relative to the actual input location. Input text lacks a background color, and the foreground color is also indistinct—both colors require improvement. When I undo an input error, if I undo to cancel the input method, the input method continues to undo one character further. I've attached a GIF below where you can see the comma being deleted during backspace, with the candidate box offset by approximately 60px from the actual input position:

2. Since my system's default font has always been LXGW-Neoxihei ( https://github.com/lxgw/LxgwNeoXiHei ) set via noMeiryoUI ( https://github.com/Tatsu-syo/noMeiryoUI ), I'm unfamiliar with the appearance of the previous default Microsoft Yahei font. However, during font testing, I noticed the application displayed unusually serifed fonts, whereas my system font is sans-serif.

I then examined the Ferrite font-related code: “ https://github.com/OlaProeis/Ferrite/blob/master/src/fonts.rs ”. Within the comments for CJK character handling, I found the following:

// Set up Proportional font family
// Order matters: Inter -> KR -> SC -> JP
// This allows Korean users to see Korean glyphs preferred, but Chinese characters
// missing from the KR font will fall back to the SC font.

What I mean is, CJKV ideographs actually encompass glyphs from five distinct regions: Chinese (Simplified Chinese), (Traditional Chinese), Korean (Hanja), Japanese (Kanji), and Vietnamese (Hán tự‌ or ‌Chữ Hán‌), Vietnamese (Chữ Nôm). The glyphs across these regions differ significantly. Without unified glyphs, you'll see fonts of varying sizes and odd shapes, and punctuation marks won't be standardized either. Therefore, enabling user-defined font support would be ideal.

Ferrite font：

neoxihei font：

MS Yahei font：

I'm sorry, I don't know if our Korean buddy @SteelCrab can improve the code. However, I just found a Chinese font project related to EGUi on GitHub: ( https://github.com/topki0325/egui-chinese-font ). I think we should discuss with our Korean partners whether we can adapt improvements from this project to enhance font rendering quality. Of course, it would be ideal if the maintainer of this Chinese font support library, @topki0325, could join our project. However, I noticed on their profile that they haven't been active for about half a year.

[SteelCrab]

Hi @sr79368142,
While I have a basic understanding of Chinese characters (Hanja), I'm afraid I won't be able to directly contribute to improving Chinese font rendering quality.
My contribution goals were:

• Resolving Korean display issues
• Ensuring that East Asian (CJK) characters render correctly at a basic level

Although I could potentially make surface-level fixes through vibe coding, I believe improvements to Chinese font rendering quality would be better handled by contributors who have a deeper understanding of the codebase and the specific requirements involved.