-
Notifications
You must be signed in to change notification settings - Fork 19
WSL: minor screen corruption in Print Preview #40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It's hard to say where the bug is, I can't reproduce it on Linux or Windows 10 with VcxSrv. If you run this command, how does it look?
It should just be a black bar with the white text "this is a test". If that doesn't work either, then I'm thinking it's a WSLg bug. Does it work if you set a black background in XTerm? I guess that might mean the BCE (Background Color Erase) isn't working. |
Apologies for taking so long to reply to this - I was a away from my Windows machine. First, your guess in the last paragraph was right. There is no problem if I set a black background and white foreground in Xterm. Print preview works correctly. The problem exists in a mild form if I set a blue background: some artifacts appear in the line where the corruption appears in the screen shot above, and they clear up if I press Shift+F3 twice, as in the white-on-black setup. Ignorant question coming: When you say that BCE isn't working, are you talking about Xterm under WSL or WP? I tried running the |
I'm not sure, XTerm supports BCE and WP uses it - if that was the problem I would have to think about how to workaround it! There are alternative ways to achieve the same thing, but I would be reluctant to turn it off to workaround a Windows bug.... I'd have to think about it! Yes, convert is part of ImageMagick - you can get a list of fonts fontconfig knows about using (Note: that command assumes you don't already have a |
Well, I finally figured out that I'm supposed to run the Does this help to narrow things down? EDIT: Actually, the command seems only to work with OTF fonts, not TTF or Type 1 - at least that's the only consistent thing I can see when experimenting... |
This is about the mild problem I reported where there is minor screen corruption in Print View Document - artifacts in the menu line at the foot of the window. I finally set up a pure-Linux system (using Ubuntu 24.04) on a ThinkPad P51 (Intel) laptop. I get the same minor corruption there, and can fix it by pressing Shift-F3 twice. I wonder if this is graphics-driver-related or if there is some Xterm setting that might help? (I'm only wondering aloud - this is a very minor issue, and the View Document screen is so tiny on this machine that it's not really usable anyway.) |
I think @taviso and I talked about this in private, but I hope it won't hurt to file it as an issue.
Under WSL with Ubuntu, opening
wp
withxterm
, Shift+F7, View Document produces this minor screen corruption:Pressing Shift+F3 twice corrects it to the way it looks under real Linux:
Is there any possibility of either fixing this minor problem in the code or, under WSL, inserting two Shift+F3 keystrokes when switching to any graphic mode (equation, image editor, view document)?
The text was updated successfully, but these errors were encountered: