Community
Participate
Working Groups
Created attachment 274722 [details] Screenshot display like the screenshot. This display has already existed a long time, but only when line start with Chinese character(or first spaces then Chinese character).If line start with English character or symbol(half size), this do not happen. Javadoc start with "/**" or "*", and general comments start with "//", so this abnormal display do not happen often. But now, even line start with half size symbol, the abnormal display is still happen, so every Chinese javadoc/comment display abnormally. When before 4.8: Start with Chinese character: abnormal. Start with half size symbol like "// 注释": normal. Now: Start with half size symbol like "// 注释": abnormal. Please solve this problem. In the best case, it can configure different fonts for Chinese and English, just like Microsoft Office Word.
Choosing other font, can not solve this. I have try this: - Inconsolata & Source Code Variable: Chinese characters can have same size, but spaces at the beginning of the line are still abnormal. - Microsoft YaHei: all characters have normal size, but this font is not designing for Coding, It looks very uncomfortable(very small word spacing).
Created attachment 275063 [details] All ASCII characters should be Consolas, not chinese (CJK) font. This issue happened at PDT(PHP), HTML and JavaScript editor, too.
Created attachment 275064 [details] Eclipse 4.7 and 4.8 This issue happened at Eclipse 4.8
Niraj, please have a look. Looks like a regression. See also bug 537475.
Created attachment 275402 [details] additional information Additional information, please see attachment.
Created attachment 275404 [details] additional information #2
Created attachment 275585 [details] Consolas_10_Chinese_Chars (In reply to Oliver Liu from comment #0) > Created attachment 274722 [details] > Screenshot > > display like the screenshot. > > This display has already existed a long time, but only when line start with > Chinese character(or first spaces then Chinese character).If line start with > English character or symbol(half size), this do not happen. Javadoc start > with "/**" or "*", and general comments start with "//", so this abnormal > display do not happen often. Sharing my Eclipse screen shot, I don't see the issue as reported in attachment 274722 [details].
Please share exact steps to reproduce this issue at our end, deferring this bug.
1. Confirm your Eclipse 'restore opened files on start up'. 2. Create a file, type some comments like attachment file (Screenshot.png) 3. Keep this file is open then exit Eclipse 4. run Eclipse again 5. You will see this issue (this defect can be reproduce, but not everytime) Sometimes, if I click other tab (file) then click back, the defect will gone, but sometimes it does not. If I opened multiple files, sometimes only one file is abnormal, sometimes multiple files are abnormal. Even though I just exit Eclipse then run Eclipse again.
Created attachment 275608 [details] Consolas example in my PC public class Comments { // comment // 注释 // 注释，注释 // comment注释 // comment注释，注释 /* comment */ /* 注释 */ /* 注释，注释 */ /* comment注释 */ /* comment注释，注释 */ /* * comment */ /* * 注释 */ /* * 注释，注释 */ /* * comment注释 */ /* * comment注释，注释 */ }
(In reply to Niraj Modi from comment #8) > Please share exact steps to reproduce this issue at our end, deferring this > bug. I have added a new attachment to show this issue. I provided the source code. You can copy it to your environment to see the display. Please pay attention to this place:"注释，注释". The word's display before and after the Chinese full-width punctuation is not the same. This problem always appears on my computer. My computer environment is this: Windows 10 Pro 1803, 中国(China), 中文（简体，中国）(Chinese Simplified, CN).
Created attachment 276295 [details] Similar in Eclipse 4.9 with Japanese text * Notice the boxes with "?" in them for comments 2 and 5 instead of readable glyphs. * Notice the bad indentation for comment 6.
Created attachment 276296 [details] This is what happens if a place an "x" at the front of every line Notice how the glyphs now renders properly.
Commenting to add that we're experiencing this after updating from Eclipse 4.7 to 4.9 and the problem renders many of our comments unreadable as glyphs are replaced by boxes. Versions are as follows: Eclipse: 2018-09 (4.9.0) (Build id: 20180917-1800) OS: Windows 10 1803 (with Japanese UI language) Font used in Eclipse: Consolas 10pt
(In reply to Dragon Chuang from comment #9) > 1. Confirm your Eclipse 'restore opened files on start up'. > 2. Create a file, type some comments like attachment file (Screenshot.png) > 3. Keep this file is open then exit Eclipse > 4. run Eclipse again > 5. You will see this issue (this defect can be reproduce, but not everytime) > With snippet in comment 10 I always see correct symbols after fresh Eclipse restart. > Sometimes, if I click other tab (file) then click back, the defect will > gone, but sometimes it does not. > > If I opened multiple files, sometimes only one file is abnormal, sometimes > multiple files are abnormal. Even though I just exit Eclipse then run > Eclipse again. Issue is occasionally reproducible after some random operation as mentioned above. And sometimes issue automatically goes away.. not sure what is causing this problem.
I always have this problem. I don't know how to post attachment. see the google drive share link below: https://drive.google.com/open?id=1C2BqtdW7rTg9Euuu6hgrDZMRKaqW22P5
Eclipse Version： Version: 2018-09 (4.9.0) Build id: 20180917-1800 OS Version： Windows 10 Professional 1803 (17134.376), Chinese Locale
Possible work-around: Instead of having a space(s) before the Chinese characters // 注释 use a Tab space, which makes the Chinese characters visible. // 注释
Again one more observation here, issue is not reproducible with SWT stand-alone CustomControlExample.java > StyledText tab. Issue only seen occasionally/randomly in Eclipse with unknown set of steps to reproduce it.
Eclipse Java EE IDE for Web Developers. Version: 2018-09 (4.9.0) Build id: 20180917-1800 Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Just download a fresh Eclipse, extract, create a simple java project, new a Test.java add java doc on Test.java, if first letter is Chinese, its probably happen. If not, restart eclipse
Created attachment 276641 [details] Reproduction in SWT CustomControlExample (In reply to Niraj Modi from comment #19) > Again one more observation here, issue is not reproducible with SWT > stand-alone CustomControlExample.java > StyledText tab. I was able to reproduce in "CustomControlExample.java > StyledText tab" with varying degrees of success. It's a lot harder than in plain Eclipse but was still possible. I used "swt-4.9-win32-win32-x86_64.zip" and "org.eclipse.sdk.examples.source-4.9.zip" from http://download.eclipse.org/eclipse/downloads/drops4/R-4.9-201809060745/ I'm running with: C:\Program Files\Java\jdk1.8.0_181\bin\java.exe -cp swt-4.9-win32-win32-x86_64/swt.jar;org.eclipse.sdk.examples.source-4.9/plugins/org.eclipse.swt.examples_3.106.200.v20180821-0759.jar org.eclipse.swt.examples.controlexample.CustomControlExample FWIW: * Same reproducibility with javaw.exe. * Same reproducibility with javaw.exe after setting "Compatibility Mode" to "Windows 8". Steps to reproduce: 1. Run CustomControlExample with the above command 2. Switch to the "StyledText" tab 3. Select "Font" under "Colors and Font" 4. Click "Change..." 5. Select "Consolas" (my default is "Yu Gothic UI"). "Script" will become "Western" by default. 6. Click "OK" to close the font selector 7. Into "StyledText" pane, add enter the line "// てすと" after the existing text. (I'm doing this by pasting copied text). e.g. The text box becomes: ------ >8 ------ >8 ------ The quick brown fox jumps over the lazy dog. One Two Three // てすと ------ >8 ------ >8 ------ 8. At this point, the bug may already be reproduced. 9. If not, I toggle "SWT.FULL_SELECTION" under "Styles" a bunch of times until it does. It usually reproduces after 10 - 20 clicks.
FYI, yesterday my Eclipse Oxygen got a push update to "Eclipse IDE for Java Developers" (among other items) and with it I lost my workaround of using an older Eclipse installation because it was updated to Photon. However, I found another workaround: If I open the property for "eclipse.exe" in explorer and set the Compatibility mode to "Windows 8", instances of Eclipse afterwards are appear to be devoid of the problem.
That's awesome!
Checked on which bug caused this regression: With my tests I see this problem got introduced in 4.8 M5 release, in which SWT native build was upgraded to latest VisualStudio2017/Win10 SDK bug 526802
(In reply to Atsushi Nakagawa from comment #22) > FYI, yesterday my Eclipse Oxygen got a push update to "Eclipse IDE for Java > Developers" (among other items) and with it I lost my workaround of using an > older Eclipse installation because it was updated to Photon. > > However, I found another workaround: > > If I open the property for "eclipse.exe" in explorer and set the > Compatibility mode to "Windows 8", instances of Eclipse afterwards are > appear to be devoid of the problem. Above workaround suggests it's a problem with Windows OS. Found one MSDN article talking about Consolas font, not 100% sure if related: https://social.msdn.microsoft.com/Forums/en-US/07897b77-a125-430d-8e41-f905c493b9a5/consolas-font-crippled-after-installing-net-fw-update-kb4055532?forum=visualstudiogeneral
Looks like latest Win10 update(Insider preview) solved this problem: I signed to latest "Windows Insider preview release" with 'slow' option and now at version 1809... I am yet to see this issue. Can someone else also try this out and confirm ?
I'v updated to version 1809(17763.107) java version "1.8.0_181" Java(TM) SE Runtime Environment (build 1.8.0_181-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.181-b13, mixed mode) Eclipse Java EE IDE for Web Developers. Version: 2018-09 (4.9.0) Build id: 20180917-1800 This problem still exists, run with compatible mode is fine
*** Bug 541618 has been marked as a duplicate of this bug. ***
Will investigate further in 4.11
Win10 1809 177633.168 Eclipse Java EE IDE for Web Developers. Version: 2018-09 (4.9.0) Build id: 20180917-1800 The problem still exists, but not always. The problem's existence will be switched when restarting eclipse or switch font,
This problem still exists in Eclipse IDE for Enterprise Java Developers. Version: 2018-12 (4.10.0) Build id: 20181214-0600 java version "1.8.0_192" Java(TM) SE Runtime Environment (build 1.8.0_192-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.192-b12, mixed mode) Win 10 pro 1803 17134.471 Disappointing
It also appears in windows 7... ...Not only win 10.
*** Bug 541523 has been marked as a duplicate of this bug. ***
This display has already existed a long time!
(In reply to Niraj Modi from comment #26) > Looks like latest Win10 update(Insider preview) solved this problem: > I signed to latest "Windows Insider preview release" with 'slow' option and > now at version 1809... I am yet to see this issue. > > Can someone else also try this out and confirm ? For me the problem is totally gone after applying all out-standing patches from Microsoft on Win10 and Win7.
(In reply to Niraj Modi from comment #35) > (In reply to Niraj Modi from comment #26) > > Looks like latest Win10 update(Insider preview) solved this problem: > > I signed to latest "Windows Insider preview release" with 'slow' option and > > now at version 1809... I am yet to see this issue. > > > > Can someone else also try this out and confirm ? > > For me the problem is totally gone after applying all out-standing patches > from Microsoft on Win10 and Win7. Please note: On Win7 I also installed all other patches from Microsoft .Net 4.7.2 for all languages including the DBCS one including Chinese.
IMO, "Consolas" fonts library might have been fixed at Windows level itself. I am marking this as "NOT_ECLIPSE"
(In reply to Niraj Modi from comment #37) > IMO, "Consolas" fonts library might have been fixed at Windows level itself. > I am marking this as "NOT_ECLIPSE" Why it's okey in eclipse 4.7 and wrong in eclipse 4.8+ at same windows 10 pc? I think the problem belong to SWT itself.
(In reply to sunx well from comment #38) > (In reply to Niraj Modi from comment #37) > > IMO, "Consolas" fonts library might have been fixed at Windows level itself. > > I am marking this as "NOT_ECLIPSE" > > Why it's okey in eclipse 4.7 and wrong in eclipse 4.8+ at same windows 10 > pc? I think the problem belong to SWT itself. Can you confirm that you have all patches installed on your machine as indicated by Niraj?
(In reply to sunx well from comment #38) > (In reply to Niraj Modi from comment #37) > > IMO, "Consolas" fonts library might have been fixed at Windows level itself. > > I am marking this as "NOT_ECLIPSE" > > Why it's okey in eclipse 4.7 and wrong in eclipse 4.8+ at same windows 10 > pc? I think the problem belong to SWT itself. Niraj, did SWT change font related code between those versions?
It's okey on eclipse 4.7.3-, and wrang on eclipse 4.8+ at SAME windows 10 pc(my Surface 4 Pro with os as Windows 10 1607 14393.1944)。 I have disabled the Windows Update service after 14393.1944 because it would upgrade to next big version with more garbage (more than 40 system processes added) using more cpu and memory itself!
(In reply to Niraj Modi from comment #35) > (In reply to Niraj Modi from comment #26) > > I signed to latest "Windows Insider preview release" with 'slow' option and > > now at version 1809... I am yet to see this issue. > > For me the problem is totally gone after applying all out-standing patches > from Microsoft on Win10 and Win7. It's still very much reproducible here. I'm using a consumer version of Win10 (version 1809 build 17663.253) and it's difficult to tell if we have the same set of patches, but pressing "Check for updates" in Windows Update shows "You're up to date". These recent updates are shown in update history: KB4481031: Cumulative update for .NET Framework 3.5 and 4.7.2 KB4480056: Cumulative Update for .NET Framework 3.5 and 4.7.2 KB4480116: OS Build 17763.253 Niraj, can you confirm the "Windows 8 compatibility mode" workaround was *disabled* when you performed your tests? The problem may very well be with Windows and it's hard to deny or conclude that. But on the opposing camp, a fact remains that this doesn't seem to occur in Notepad.exe, WordPad or EmEditor (all set to use "Consolas" in "Western" script), and neither Chrome[1] or Firefox[1]. SWT/Eclipse so far the only software I've seen that has anything resembling this problem. [1] Tested with: <style>* { font: normal 10pt Consolas; color: red; }</style> <textarea rows="20" cols="80"></textarea>
Created attachment 277568 [details] DotNet4.7.2_locale_specifc_Updates (In reply to Niraj Modi from comment #36) > Please note: On Win7 I also installed all other patches from Microsoft .Net > 4.7.2 for all languages including the DBCS one including Chinese. Attaching a quick grab for the .Net 4.7.2 language specific patches which I see in my Win7 setup.
(In reply to Dani Megert from comment #40) > (In reply to sunx well from comment #38) > > (In reply to Niraj Modi from comment #37) > > > IMO, "Consolas" fonts library might have been fixed at Windows level itself. > > > I am marking this as "NOT_ECLIPSE" > > > > Why it's okey in eclipse 4.7 and wrong in eclipse 4.8+ at same windows 10 > > pc? I think the problem belong to SWT itself. > Niraj, did SWT change font related code between those versions? No Font related changes.
(In reply to Atsushi Nakagawa from comment #42) > (In reply to Niraj Modi from comment #35) > > (In reply to Niraj Modi from comment #26) > > > I signed to latest "Windows Insider preview release" with 'slow' option and > > > now at version 1809... I am yet to see this issue. > > > > For me the problem is totally gone after applying all out-standing patches > > from Microsoft on Win10 and Win7. > > It's still very much reproducible here. I'm using a consumer version of > Win10 (version 1809 build 17663.253) and it's difficult to tell if we have > the same set of patches, but pressing "Check for updates" in Windows Update > shows "You're up to date". > > These recent updates are shown in update history: > KB4481031: Cumulative update for .NET Framework 3.5 and 4.7.2 > KB4480056: Cumulative Update for .NET Framework 3.5 and 4.7.2 > KB4480116: OS Build 17763.253 Please see attachment 277568 [details] which IMO would have fixed the issue for me on Win7. > > Niraj, can you confirm the "Windows 8 compatibility mode" workaround was > *disabled* when you performed your tests? I didn't changed the compatibility mode at all, so it's always remains system default. > The problem may very well be with Windows and it's hard to deny or conclude > that. Agree, but workarounds like above also suggests it's a problem with Windows OS. > But on the opposing camp, a fact remains that this doesn't seem to occur in > Notepad.exe, WordPad or EmEditor (all set to use "Consolas" in "Western" > script), and neither Chrome[1] or Firefox[1]. SWT/Eclipse so far the only > software I've seen that has anything resembling this problem. > > [1] Tested with: > <style>* { font: normal 10pt Consolas; color: red; }</style> > <textarea rows="20" cols="80"></textarea> At the same time in SWT we don't have any font specific handling code. Ideas are welcome if we could narrow down this issue to some SWT code.
My Windows update is open, and there is having recent updates to the .NET Framework (February 12, 2019-KB4483452). I switched the font to Consolas 14, and the display is normal. I will use it for a while to see if it will always display normally. It should be noted that the normal display is just meaning that it is the same as `version 4.7`. It is still displaying abnormally when line is starting with first spaces and then Chinese character, the starting spaces are not all displayed. This problem has been around since I started using eclipse, but it is not related to this bug.
(In reply to Oliver Liu from comment #46) > My Windows update is open, and there is having recent updates to the .NET > Framework (February 12, 2019-KB4483452). I switched the font to Consolas 14, > and the display is normal. I will use it for a while to see if it will > always display normally. > > It should be noted that the normal display is just meaning that it is the > same as `version 4.7`. It is still displaying abnormally when line is > starting with first spaces and then Chinese character, the starting spaces > are not all displayed. This problem has been around since I started using > eclipse, but it is not related to this bug. Yes! and I think it has nothing to do with Consolas font. Because it's wrang with other font such as Courier New. please pay attention to this bug. Olny eclipse has the problem! the bug exists in SWT or JFace. A space char followed by no-ascii char can lead to the problem.
Created attachment 277580 [details] wrang dispaly with Courier New font also. I think it has nothing to do with Consolas font. Because it's wrang with other font such as Courier New. please pay attention to this bug. It's the problem of eclipse! not Windows OS or Consolas font or others.
(In reply to Niraj Modi from comment #45) > At the same time in SWT we don't have any font specific handling code. > Ideas are welcome if we could narrow down this issue to some SWT code. I have a feeling it does. This isn't to say there're issues with this particular code but see [1]. [1] https://github.com/eclipse/eclipse.platform.swt/blob/51263809dca49073ec49620f9b38900b00c2b78f/bundles/org.eclipse.swt/Eclipse%20SWT/win32/org/eclipse/swt/graphics/TextLayout.java#L3433-L3449 I've noticed: * Consolas (or New Courier for that matter) don't have CJK glyphs. * ScriptShape returns USP_E_SCRIPT_NOT_IN_FONT for them. * Uniscribe or some such is required as fallback glyphs. * Reproduce the issue appears to be timing related. Perhaps it's state a initialization problem. (Possibly in either Windows itself or in some way SWT uses the Win32 API.) Documentations I've wondered into: https://docs.microsoft.com/en-us/windows/desktop/intl/using-shaping-engines https://docs.microsoft.com/en-us/windows/desktop/intl/using-font-fallback https://docs.microsoft.com/en-us/windows/desktop/api/Usp10/nf-usp10-scriptshape FWIW, I've reduced my reproducing code down to this: -------- 8< -------- 8< -------- 8< -------- 8< -------- import org.eclipse.swt.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); shell.setSize(400, 400); String text = "\n" + "public class Foo {\n" + " // てすと\n" + "x // てすと\n" + " //x てすと\n" + "\n" + "}\n" + "//てすと\n" + ""; Composite canvas = new Composite(shell, SWT.NONE); canvas.addListener(SWT.Paint, event -> { TextLayout layout = new TextLayout(display); layout.setFont(new Font(display, "Consolas", 10, SWT.NONE)); layout.setText(text); layout.draw(event.gc, 100, 100); }); shell.addMouseWheelListener(e -> canvas.redraw()); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } } -------- 8< -------- 8< -------- 8< -------- 8< --------
Unfortunately, today the problem has appeared again. `restart eclipse`, `switch to another font and then switch back`, both don't solve the problem.
(In reply to Oliver Liu from comment #50) > Unfortunately, today the problem has appeared again. `restart eclipse`, > `switch to another font and then switch back`, both don't solve the problem. I still believe the issue lies outside of Eclipse(not reproducible on my side on Win7/Win10), reopening this bug for discussion to continue.
Created attachment 277614 [details] Animated gif for Bug 536562 Eclipse IDE for PHP Developers Version: 2018-12 (4.10.0) Build id: 20181214-0600 Microsoft Windows Version 10.0.17763.316 (Update to 2019-02) Attachment is a animated gif, you can see first comment block is normal, secondary comment block has issue. I just add a SPACE to between '*' and 'Chinese', this issue has gone. Even I removed the SPACE, this issue has not appeared again.
Moving out of 4.11
This problem still exists... version: Eclipse 4.11
Created attachment 277957 [details] Bug536562-20190322154200 Eclipse IDE for PHP Developers Version: 2019-03 (4.11.0) Build id: 20190314-1200 Microsoft Windows Version 10.0.17763.379 (Updated to 2019-03) Font has changed when I moved cursor (press DOWN) to line 6.
I'v reviewed all SWT code changes between version 4.7.3 and 4.8, there is a inconspicuous change related to font display in src/javaw.exe.manifest by inserting code fragment as bellow: ``` <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings> <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</dpiAware> <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, PerMonitor</dpiAwareness> <!-- Un-comment the line below to enable GDI-scaling in this project. This will enable text --> <!-- to render crisply in DPI-unaware content --> <!--<gdiScaling xmlns="http://schemas.microsoft.com/SMI/2017/WindowsSettings">true</gdiScaling>--> </windowsSettings> </application> <!--Specifically targeting your application for Windows 8.1 or Windows 10: https://msdn.microsoft.com/en-us/library/windows/desktop/dn481241(v=vs.85).aspx --> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <!-- Windows 10 --> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> <!-- Windows 8.1 --> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> <!-- Windows Vista --> <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> <!-- Windows 7 --> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> <!-- Windows 8 --> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> </application> </compatibility> ``` Who can explain the effects of this code fragment because I known nothing about windows GUI programming? And how to disabled the it and to test againt?
I rebuild swt-win32-4924r25.dll (eclipse 4.11) with src/javaw.exe.manifest restored as eclipse 4.7.3. Now it's OKey! Maybe this is not a good way, but I decide to use eclipse 4.11 with my modified swt-win32-4924r25.dll. :)
(In reply to sunx well from comment #57) > I rebuild swt-win32-4924r25.dll (eclipse 4.11) with src/javaw.exe.manifest > restored as eclipse 4.7.3. > > Now it's OKey! > > Maybe this is not a good way, but I decide to use eclipse 4.11 with my > modified swt-win32-4924r25.dll. > > :) Doesn't work! The problem remains.
Created attachment 278289 [details] disable DPI scaling via Compatibility Mode I'm sure this is a problem about DPI scaling. After Disable DPI scaling by setting Compatibility Mode with win 7, it's okey.
Created attachment 278309 [details] Eclipse font issue (Mixed English and CJK) Eclipse has some font bug on CJK (Chinese, Japanese, Korean). Please see attachment, when 'Text Font' setting is 'Consolas 12', the CJK text is smaller than 'Consolas 11'.
The problem remains.
Created attachment 278345 [details] new effect The Chinese font changed but different when I inserted 'A' or '*'.
(In reply to sunx well from comment #56) > I'v reviewed all SWT code changes between version 4.7.3 and 4.8, there is a > inconspicuous change related to font display in src/javaw.exe.manifest by > inserting code fragment as bellow: > > ``` > <application xmlns="urn:schemas-microsoft-com:asm.v3"> > <windowsSettings> > <dpiAware > xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">true/pm</ > dpiAware> > <dpiAwareness > xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2, > PerMonitor</dpiAwareness> > <!-- Un-comment the line below to enable GDI-scaling in this > project. This will enable text --> > <!-- to render crisply in DPI-unaware content --> > <!--<gdiScaling > xmlns="http://schemas.microsoft.com/SMI/2017/WindowsSettings">true</ > gdiScaling>--> > </windowsSettings> > </application> > <!--Specifically targeting your application for Windows 8.1 or Windows > 10: > https://msdn.microsoft.com/en-us/library/windows/desktop/dn481241(v=vs.85). > aspx --> > <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> > <application> > <!-- Windows 10 --> > <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> > <!-- Windows 8.1 --> > <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> > <!-- Windows Vista --> > <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> > <!-- Windows 7 --> > <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> > <!-- Windows 8 --> > <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> > </application> > </compatibility> > ``` > > Who can explain the effects of this code fragment because I known nothing > about windows GUI programming? > And how to disabled the it and to test againt? Above javaw.exe.manifest changes were done as part of fix for bug 533138, please refer below bug description for the nature of the change: https://bugs.eclipse.org/bugs/show_bug.cgi?id=533138#c0 Corresponding MSDN link highlighting the need of it: https://docs.microsoft.com/en-us/windows/desktop/SysInfo/targeting-your-application-at-windows-8-1
Created attachment 278508 [details] Same issue at Git Commit Message textbox Same issue at Git Commit Message textbox
Moving out to 4.13
Please fix this issue as soon as possible, please!
*** Bug 539610 has been marked as a duplicate of this bug. ***
*** Bug 540679 has been marked as a duplicate of this bug. ***
*** Bug 539445 has been marked as a duplicate of this bug. ***
*** Bug 537475 has been marked as a duplicate of this bug. ***
*** Bug 544750 has been marked as a duplicate of this bug. ***
Just wondering if this is a StyledText bug that is now uncovered after saying that Eclipse is Windows 8+ "compatible" via bug 533138? This would explain why changing compatibility mode to Windows 7 seem to "fix" the problem. May be some font related windows API (font metrics?) behaves differently in "Windows 8+" mode, so that StyledText renders/layouts text differently?
Take a vote and keep an eye on the bug
I've had a chance to debug this a bit more and have narrowed things down to this OS.ScriptItemize() native method, called on this line: https://github.com/eclipse/eclipse.platform.swt/blob/51263809dca49073ec49620f9b38900b00c2b78f/bundles/org.eclipse.swt/Eclipse%20SWT/win32/org/eclipse/swt/graphics/TextLayout.java#L2744 For some reason, even when called with the same input, OS.ScriptItemize() is returning two different variations of pItems. One of these variations results in correct rendering, and the other causes bad glyph rendering later on in OS.ScriptShape(). Here's a fairly minimal code to test this. The resulting cItems is 24 when it's correct, and 19 when it's broken. ``` import java.util.TreeMap; import java.util.concurrent.atomic.AtomicInteger; import org.eclipse.swt.SWT; import org.eclipse.swt.internal.win32.OS; import org.eclipse.swt.internal.win32.SCRIPT_CONTROL; import org.eclipse.swt.internal.win32.SCRIPT_ITEM; import org.eclipse.swt.internal.win32.SCRIPT_STATE; public static void main(String[] args) { String text = "\n" + "public class Foo {\n" + " // てすと\n" + "x // てすと\n" + " //x てすと\n" + "\n" + "}\n" + "//てすと\n" + ""; TreeMap<Integer, AtomicInteger> counts = new TreeMap<>(); for (int i = 0; i < 100; i++) { int length = text.length(); SCRIPT_CONTROL scriptControl = new SCRIPT_CONTROL(); SCRIPT_STATE scriptState = new SCRIPT_STATE(); final int MAX_ITEM = length; long hHeap = OS.GetProcessHeap(); long pItems = OS.HeapAlloc(hHeap, OS.HEAP_ZERO_MEMORY, (MAX_ITEM + 1) * SCRIPT_ITEM.sizeof); if (pItems == 0) SWT.error(SWT.ERROR_NO_HANDLES); int cItems; try { int[] pcItems = new int[1]; char[] chars = new char[length]; text.getChars(0, length, chars, 0); int hr = OS.ScriptItemize(chars, length, MAX_ITEM, scriptControl, scriptState, pItems, pcItems); if (hr == OS.S_OK) { cItems = pcItems[0]; } else { cItems = -1; } } finally { OS.HeapFree(hHeap, 0, pItems); } counts.computeIfAbsent(cItems, k -> new AtomicInteger()).incrementAndGet(); } System.out.println(counts); } ``` Although I haven't reached a solution, here are some things I've noticed: * Calling OS.ScriptItemize() with `scriptControl = null` makes the rendering problem go away...!! I don't know if this is a good fix though. * Although I don't think this is the cause, there appears to be a potential buffer overflow bug here: https://github.com/eclipse/eclipse.platform.swt/blob/51263809dca49073ec49620f9b38900b00c2b78f/bundles/org.eclipse.swt/Eclipse%20SWT/win32/org/eclipse/swt/graphics/TextLayout.java#L2744 According to the documentation, the buffer length of pItems should be `(cMaxItems + 1) * sizeof(SCRIPT_ITEM)` but OS.ScriptItemize() is being called with the same number of `cMaxItems` and length of `pItems`. Documentation for ScriptItemize(): https://docs.microsoft.com/en-us/windows/win32/api/usp10/nf-usp10-scriptitemize Some information regarding ScriptItemize(): * "Uniscribe Mysteries" - http://www.catch22.net/tuts/neatpad/uniscribe-mysteries * "Uniscribe: The Missing Documentation & Examples" - https://maxradi.us/documents/uniscribe/
Created attachment 280363 [details] Testing behaviour of ScriptItemize() in C# FWIW, I've ported and tested the above code in C# (attached) but there appears to be no problems there. (Always returns cItems = 24.)
New Gerrit change created: https://git.eclipse.org/r/151427
Thanks for your debugging! With it, it was easy to understand what went wrong. I have prepared a patch now. Regarding '(cMaxItems + 1)', I did some quick testing, but results are pretty strange. I would say that MSDN is actually wrong. Passing 'length' instead of 'MAX_ITEM' will often result in 'E_OUTOFMEMORY' or 'E_INVALIDARG' errors. At the same time, passing 'MAX_ITEM' does not seem to result in memory corruption. I would say that we actually need to pass 'MAX_ITEM'. Unfortunately I don't have time to debug it further right now, but I've put it on my todo.
I just worked out the cause and came here to write up it but Alexandr beat me to it. ;-) Yeah, the problem was lack of initialisation of this SCRIPT_CONTROL, thereby causing sporadic raising of bits fMergeNeutralItems and fUseStandardBidi: https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT%20PI/win32/library/os.c#L8337 I see https://git.eclipse.org/r/151427 fixes the problem by adding the missing bit fields to the structure, but I thought maybe SCRIPT_CONTROL should also be initialised the zero to prevent a similar repeat of the problem next time the SDK is updated and fReserved is further reduced. e.g.: ``` SCRIPT_CONTROL _arg3 = {0}, *lparg3=NULL; ``` Just a suggestion. I'm fine either way if the problem is fixed. Regarding MAX_ITEM, I was concerned because I saw example code such as the one at https://maxradi.us/documents/uniscribe/ that deliberately passes one less cMaxItems than the size of the buffer. The docs could be wrong as you say, but it's also not a one-off mention and it reiterates the point by stating "It is invalid to call this function with a buffer to hold less than two SCRIPT_ITEM structures." and "The function always adds a terminal item", so I'm not too sure. On the other hand, I think reducing MAX_ITEM is risky because Eclipse has worked with (length + 1) up to this point, and since as you say passing `length` can causes E_OUTOFMEMORY maybe continue with `cMaxItems = length + 1` but also allocated the buffer as `cMaxItems + 1` to make it in line with the docs? e.g. ``` final int MAX_ITEM = length + 1; ... long /*int*/ pItems = OS.HeapAlloc(hHeap, OS.HEAP_ZERO_MEMORY, (MAX_ITEM + 1) * SCRIPT_ITEM.sizeof); // Allocate one extra for terminal item ```
> maybe SCRIPT_CONTROL should also be initialised the zero This code is auto-generated and doesn't quite allow custom additions to it. I thought about writing a unit test to prevent this from repeating, but after some googling I concluded that the structure didn't change for a very long while. Just SWT's copy was even older. > Regarding MAX_ITEM I think it needs some research before changing. When I changed it to be in line with docs it started crashing :) So the idea of "let's patch it quickly" should be abandoned, I guess.
Fair enough on both points. :-) Thanks for creating a patch. I've reviewed it and it looks good. (I've added my +1, I hope I did it correctly.)
Well done. Please also test the new fonts such as 'Cascadia Code' or 'Fira Code' after applying the patch [https://git.eclipse.org/r/151427] The requirements of developers are getting higher and higher! Eclipse can't lose to VS Code on such a low-level problem! Fira Code: https://github.com/tonsky/FiraCode Cascadia Code: https://github.com/microsoft/cascadia-code
> Please also test the new fonts such as @sunx Please feel free to do it yourself, and open a new bug if something arises.
Gerrit change https://git.eclipse.org/r/151427 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=3aa0cc06e3a9c7632bb4c7fe5cfc7f776fef8335
(In reply to Alexandr Miloslavskiy from comment #78) > Thanks for your debugging! With it, it was easy to understand what went > wrong. I have prepared a patch now. > (In reply to Atsushi Nakagawa from comment #81) > Fair enough on both points. :-) > > Thanks for creating a patch. I've reviewed it and it looks good. > (I've added my +1, I hope I did it correctly.) Thanks Atsushi for the tricky investigation/debugging and Alexandr for getting it to a fix patch, appreciate it.
(In reply to Alexandr Miloslavskiy from comment #80) > > maybe SCRIPT_CONTROL should also be initialised the zero > > This code is auto-generated and doesn't quite allow custom additions to it. > I thought about writing a unit test to prevent this from repeating, but > after some googling I concluded that the structure didn't change for a very > long while. Just SWT's copy was even older. Unfortunately we don't have an automatic way of knowing/detecting if SWT structure is old and needs to be updated. Ideas are welcome here!
Curiously it was already noticed that SWT's structure is incomplete, see: Bug 352927 Comment 10
Usually WINAPI structures are designed to be backwards compatible, but this one was quite a backstab. The same problem would occur in native applications. I don't think that we could automatically test for such things. I had one idea with initializing struct to 0xFF, then writing zero fields according to JNI spec, then checking for any remaining 1 bits - but this idea is defeated by C++ struct field padding. Also, this won't work for structs that are extended in backwards compatible way. One thing we could do is teaching JniGenerator to always zero-initialize structs before filling them. The speed of memset() should be in ballpark og 1gb/sec, so it shouldn't introduce a performance hit.
> an automatic way of knowing/detecting if SWT structure is old I don't have an idea for wholesale checking, but I think specific structs could be tested by setting the struct to 0xFF (similar to Alexandr's idea) then looking at the length of the `fReserved` field: e.g. ``` SCRIPT_CONTROL buf = {0}; memset(&buf, 0xFF, sizeof(buf)); assert(buf.fReserved == 0x3f); // Expect 6-bits ``` > Curiously it was already noticed that SWT's structure is incomplete, see: > Bug 352927 Comment 10 Yeah, I noticed `fMergeNeutralItems` was once enabled in 2011-10 for Bug 352927 then later removed in 2012-05 for Bug 377472. Some time afterwards, I suspect the SDK used for building was updated, and with it usp10.h, causing `fMergeNeutralItems` to start getting raised again randomly. (Btw, I didn't mention it earlier but `fMergeNeutralItems` was also the cause of this current problem, so it's in a way a recurrence of Bug 377472.) > The same problem would occur in native applications. That's true, but native applications usually initialise the structure to zero because regular applications don't usually set every single field these WINAPI structs have, and rather only the fields they're concerned with. > One thing we could do is teaching JniGenerator to always zero-initialize structs before filling them. This does sound like the most robust approach. :-)
(In reply to Eclipse Genie from comment #84) > Gerrit change https://git.eclipse.org/r/151427 was merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=3aa0cc06e3a9c7632bb4c7fe5cfc7f776fef8335 Marking this bug as resolved, raised bug 552409 to continue on item discussed in comment 86 to comment 89.
Fix is available in below Eclipse I-Build on wards: https://download.eclipse.org/eclipse/downloads/drops4/I20191023-1810/ Please verify your respective test-cases and confirm. Thanks!
(In reply to Niraj Modi from comment #91) > Fix is available in below Eclipse I-Build on wards: > https://download.eclipse.org/eclipse/downloads/drops4/I20191023-1810/ > > Please verify your respective test-cases and confirm. Thanks! It's good, but still doesn't support font ligatures because fMergeNeutralItems is false. so some font such as 'Cascadia Code' or 'Fire Code' has no completely effective. see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=398656 The following code has been tested, seems ugly but maybe worth considering: ``` segmentsText.getChars(0, length, chars, 0); // enable font ligatures and avoid ligatures between ascii and non-ascii chars scriptControl.fMergeNeutralItems = true; for (int i = length - 2; i > 0; i--) { char i0 = chars[i]; char i1 = chars[i + 1]; if (i0 > 255 && i1 < '~' && i1 >= ' ') { chars[i + 1] = 'A'; } else if (i1 > 255 && i0 < '~' && i0 >= ' ') { chars[i] = 'A'; i--; } } OS.ScriptItemize(chars, length, MAX_ITEM, scriptControl, scriptState, pItems, pcItems); ```
I do not currently possess required knowledge about Chinese/Japanese/etc writings to fully understand the problem here. Just came in to fix an obvious problem that Atsushi Nakagawa identified (thanks again for great research!). Also, I have too many other tasks to complete :( If anyone is willing to continue, please do!
(In reply to sunx well from comment #92) > still doesn't support font ligatures because fMergeNeutralItems is false. > so some font such as 'Cascadia Code' or 'Fire Code' has no completely > effective. see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=398656 That sounds like a different problem. Isn't that what Bug 398656 is for? If not, I think a new report needs to be opened. This bug was about "Text starting with space and containing Chinese" which I believe is resolved by Alexandr's patch and fixed in I20191023-1810. Please see the original screenshot by Oliver Liu. (The title of this report was initially "Now, using font "consolas", Chinese comment display unnormal".)
Created attachment 280459 [details] Build I20191023-1810 test It has been resolved. See attachment. I additionally tested a case that the width of the space is not normal when there are Chinese characters in the line. This problem may be related to the Consolas font itself, and generally does not affect use, so there is no need to pay special attention.
The width of space is probably Bug 548140.
(In reply to Alexandr Miloslavskiy from comment #96) > The width of space is probably Bug 548140. Thanks. I think this bug can be ended.
(In reply to sunx well from comment #92) > (In reply to Niraj Modi from comment #91) > > Fix is available in below Eclipse I-Build on wards: > > https://download.eclipse.org/eclipse/downloads/drops4/I20191023-1810/ > > > > Please verify your respective test-cases and confirm. Thanks! > > It's good (In reply to Oliver Liu from comment #97) > (In reply to Alexandr Miloslavskiy from comment #96) > > The width of space is probably Bug 548140. > > Thanks. I think this bug can be ended. Marking Verified.
This bug still exists in Eclipse 2020-06 on latest Windows 10 2004.
after upgrade to 2020-06, this bug comes again~(In reply to Gavin Yang from comment #99) > This bug still exists in Eclipse 2020-06 on latest Windows 10 2004. +1 after upgrade eclipse from 2020-3 to 2020-06
when i replace plugins/org.eclipse.swt.win32.win32.x86_64_3.114.100.v20200604-0951.jar(4.16) with org.eclipse.swt.win32.win32.x86_64_3.114.0.v20200304-0601.jar(4.15), the bug is gone~~
(In reply to legend liang from comment #101) > when i replace > plugins/org.eclipse.swt.win32.win32.x86_64_3.114.100.v20200604-0951.jar(4. > 16) with > org.eclipse.swt.win32.win32.x86_64_3.114.0.v20200304-0601.jar(4.15), the bug > is gone~~ yes, but the bug 562165 still exists in 4.15. there is no perfect solution for chinese comment layout and full ligatures support now.
(In reply to Gavin Yang from comment #102) > (In reply to legend liang from comment #101) > > when i replace > > plugins/org.eclipse.swt.win32.win32.x86_64_3.114.100.v20200604-0951.jar(4. > > 16) with > > org.eclipse.swt.win32.win32.x86_64_3.114.0.v20200304-0601.jar(4.15), the bug > > is gone~~ > > yes, but the bug 562165 still exists in 4.15. > there is no perfect solution for chinese comment layout and full ligatures > support now. see comment #92
Please clarify which specific bug has returned. Remember that I know almost nothing about Chinese and how it should look like. I only fixed one problem where the behavior was random. It doesn't really fix any problems that reproduce 100% of time.
楼上的朋友，请使用FontCreator制作混合字体（比如Consolas+微软雅黑混合字体）来解决该问题（此为终极大法）。 也可以使用Windows 8兼容模式启动Eclipse来解决Java编辑器的中文注释缩进异常，但是HTML编辑器等还是会出现该问题。 reply to Alexandr Miloslavskiy from comment #104) > Please clarify which specific bug has returned. Remember that I know almost > nothing about Chinese and how it should look like. > > I only fixed one problem where the behavior was random. It doesn't really > fix any problems that reproduce 100% of time. The problem is just as https://bugs.eclipse.org/bugs/show_bug.cgi?id=536562#c0 describes. Was it possible for Eclipse to provide a mechanism like fallback font(which Intellij IDEA uses) or font-family(which VS Code uses) to solve the problem?
当然了，如果你换用中文字体还有部分英文字体，也能解决该问题。Eclipse 2020-06版本为了全面支持Windows下的连字字体显示，导致了该问题的复现。总之，Consolas作为Eclipse Windows版本的默认字体，不应该出现该问题。
目前swt默认开启了连字，这个没问题，是好事。之前是脏内存随机触发连字。 现在的问题出在windows，会将某些ascii字符如*和非ascii字符如中文或日文字符连字，使字符整体风格走样，丑死。 貌似windows充分升级和打补丁会好，只是付出代价太高，万一某天一个新补丁打上又不好了也很无奈。这是条不归路，是下策。 也可以将eclipse.exe设置为win8兼容，这会弱化连字，从而避免ascii和其它字符连字。但会使有些ascii之间的连字也无效。是中策。 我在92楼附了一段代码，解除ascii和其它字符的连字，效果理想。我想不出一个ascii字符和一个中文字符有啥连字的必要性，所以我认为在目前情况下，是上策。
这个办法确实是目前看到的最佳方案了, 即不影响ASCII字符的连字效果, 也不会再出现这个BUG, 希望可以被合并进代码库中. PS: 帮忙补充一下说明, 这段代码需要插到这一行后面 https://github.com/eclipse/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Eclipse%20SWT/win32/org/eclipse/swt/graphics/TextLayout.java#L2730
Created attachment 283567 [details] incorrect indentation in HTML Editor HTML编辑器，某行存在前导空格，并且空格后为中文、日本或者韩文字符，该行可能出现缩进异常。 这与连字字体有关系吗？
(In reply to Gao Hao from comment #105) > 楼上的朋友，请使用FontCreator制作混合字体（比如Consolas+微软雅黑混合字体）来解决该问题（此为终极大法）。 > > 也可以使用Windows 8兼容模式启动Eclipse来解决Java编辑器的中文注释缩进异常，但是HTML编辑器等还是会出现该问题。 > > reply to Alexandr Miloslavskiy from comment #104) > > Please clarify which specific bug has returned. Remember that I know almost > > nothing about Chinese and how it should look like. > > > > I only fixed one problem where the behavior was random. It doesn't really > > fix any problems that reproduce 100% of time. > > The problem is just as > https://bugs.eclipse.org/bugs/show_bug.cgi?id=536562#c0 describes. > > Was it possible for Eclipse to provide a mechanism like fallback font(which > Intellij IDEA uses) or font-family(which VS Code uses) to solve the problem? I tried to use FontCreator to mix Fira Code and Microsoft YaHei. The mixed font is ok for the comment layout. But the ligatures is lost.
This bug, in its original form (and not the discussion about ligatures) is well and truly back as of Eclipse 2020-06. This time around there's no randomness to it, and workarounds such as setting Windows 8 compatibility mode don't work, because `fMergeNeutralItems` has been quite deliberately changed to true: https://github.com/eclipse/eclipse.platform.swt/commit/ba33d992d59d335fdf89b018cf33fd722a43e49f Sadly, this breaks Eclipse + Consolas for a part, but still significant, swaths of its audience, as Japanese texts (and other CJK languages, by the looks of these thread) are quite resoundingly unreadable: https://bugs.eclipse.org/bugs/attachment.cgi?id=276295 I believe the fix to bug 562165 have traded "Fira Code" to the detriment of a much larger user-base that don't care at all about Fira Code, by breaking Uniscribe in the process. From the look of discussions in another project, proper support for ligatures appear to be rather involved, and just changing fMergeNeutralItems, for a quick fix for Fira Code may have been rash. https://github.com/mintty/mintty/issues/601
(In reply to Atsushi Nakagawa from comment #111) > This bug, in its original form (and not the discussion about ligatures) is > well and truly back as of Eclipse 2020-06. > > This time around there's no randomness to it, and workarounds such as > setting Windows 8 compatibility mode don't work, because > `fMergeNeutralItems` has been quite deliberately changed to true: > https://github.com/eclipse/eclipse.platform.swt/commit/ > ba33d992d59d335fdf89b018cf33fd722a43e49f > > Sadly, this breaks Eclipse + Consolas for a part, but still significant, > swaths of its audience, as Japanese texts (and other CJK languages, by the > looks of these thread) are quite resoundingly unreadable: > https://bugs.eclipse.org/bugs/attachment.cgi?id=276295 > > I believe the fix to bug 562165 have traded "Fira Code" to the detriment of > a much larger user-base that don't care at all about Fira Code, by breaking > Uniscribe in the process. > > From the look of discussions in another project, proper support for > ligatures appear to be rather involved, and just changing > fMergeNeutralItems, for a quick fix for Fira Code may have been rash. > https://github.com/mintty/mintty/issues/601 Raised bug 565526 to track above issue.
