Community
Participate
Working Groups
Many programmers like editing a program with monospace font. Many programmers like syntax highliting with bold. However, many monospace fonts have a problems that width of bold gryph is not same as regular, like MS Gothic in Windows. Force monospace feature corrects this problem, in draw time. I believe that force monospace feature increase user experience. Principle is simple, if font style of run is not regular, recalculate position and width of each gryph with regular style, and set these position and width to the run. It is very easy to implement force monospace feature in win32. You may implement force monospace feature in gtk and carbon, but it is not so much easy as win32. Maybe, it is difficult to implement in motif and emulate(photon), because these platform do not have the way to operate the gryph position and width.
Created attachment 12949 [details] for org.eclipse.swt plugin win32 only.
Created attachment 12950 [details] for org.eclipse.ui.editors plugin
Created attachment 12951 [details] for org.eclipse.ui.workbench.texteditor plugin
Created attachment 12952 [details] for org.eclipse.jdt.ui plugin
overview of patchs for org.eclipse.swt plugin implementation of force monospace, only win32. for org.eclipse.ui.editors plugin add a checkbox which is labeled "force monospace" to Preference->Workbench->Editors->TextEditor. for org.eclipse.ui.workbench.texteditor plugin support force monospace option in Preference. for org.eclipse.jdt.ui plugin add a checkbox which is labeled "force monospace" to Preference->Workbench->Java->Editor->Appearance. Syntax preview supports force monospace.
Created attachment 13082 [details] screenshot, before patch. Java Editor Text Font is set to "MS Gothic". "public class" is highlighted with bold. and width of highlighted "public class" is not same as not highlighted "public_class". this screenshot is used "MS Gothic"
Created attachment 13083 [details] screenshot, after patch Java Editor Text Font is set to "MS Gothic". "public class" is highlighted with bold, and width of highlighted "public class" is same as not highlighted "public_class".
Created attachment 13084 [details] monospace font checker. (for J2SE 5.0) Execute this program, then you will see the output like following. > monospc | font family name > --------+------------------ > not | Arial > not | Arial Black > not | Batang > pseudo | BatangChe > not | Bitstream Vera Sans > true | Bitstream Vera Sans Mono "not" intends that it is not monospace font. "true" intends that it is monospace font and regular width equals bold width. "pseudo" intends that it is monospace font, however regular width does not equal bold width. you can execute this program with encoding names, then you will see the output like following. > C:>java MonospaceTest ASCII > monospc | ASCII | font family name > --------+--------+------------------ > not | 76.5% | Arial > not | 76.5% | Arial Black > not | 100.0% | Batang > pseudo | 100.0% | BatangChe > not | 76.5% | Bitstream Vera Sans > true | 76.5% | Bitstream Vera Sans Mono The Number of middle column shows percentage of displayable in specified encoding.
Created attachment 13085 [details] output of "java MonospaceTest ASCII JIS BIG5 EUCCN EUCKR" This file is output of "java MonospaceTest ASCII JIS BIG5 EUCCN EUCKR" on my WindowsXP. It is clearly that WindowsXP has no "true monospace font" which can use with CJK characters. If eclipse does not support this force monospace feature, 1. Seek "true monospace font" at start, This solution increases initial cost of Eclipse. 2. Use "Courier New", and do not use their native language. This solution decreases user experience. 3. Use "pseudo monospace font", and do not highlight with bold. This solution decreases user experience. 4. Throw away monospace layout. This solution decreases user experience.
Created attachment 13088 [details] screenshot, hidemaru(Japanese famous editor) "public class" is highlighted with bold, and width of highlighted "public class" is same as not highlighted "public_class". It is same as patched screenshot.
This request is same as Bug 42114, but this is not a bug. However, many editors support a feature like force monospace feature. Current Eclipse behaviour is not satisfactory behaviour. I believe that many people hope to enhance Eclipse behaviour.
I forgot that AWT can not operate bitmap font. I will attach screenshot with bitmap font which contains Japanese glyphs. (FixedSys, SmallFonts, System, Terminal)
Created attachment 13095 [details] screenshot, FixedSys FixedSys is not monospace font.
Created attachment 13096 [details] screenshot, Small Fonts Small Fonts is "pseudo monospace font".
Created attachment 13097 [details] screenshot, System System is not monospace font.(same as FixedSys?)
Created attachment 13098 [details] screenshot, Terminal Terminal is "pseudo monospace font".
Created attachment 13125 [details] screenshot, preference window After patched, new check box which is labeled "Force monospace" is added, in preference window. If you want to enable force monospace feature, check it.
The main (enabling) patch is the one which has to be applied to SWT. Moving there for comments. Once applied please move back to text.
SSQ and FH to discuss this with SN. If I read the patches properly, we are ignoring then operating system spacing for bold fonts and hammering them to be the same as regular fonts? Although it makes Eclipse look nice, it doesn't seem right to do this. Michel, why don't you just turn bold fonts off in the Eclipse preferences and rely on coloring for key words?
> If I read the patches properly, we are ignoring then operating system spacing for bold fonts and hammering them to be the same as regular fonts? Yes, you read patches properly. > Michel, why don't you just turn bold fonts off in the Eclipse preferences and rely on coloring for key words? It is same as solution 3 in #9? I have said that the solution reduces user experience. If this solution can satisfy everyone, the bold option for key word highlighting is not needed. So you should eliminate the bold option for key word highlighting from Eclipse. Steve, why does Eclipse have bold option for key word highlighting? Of course, many people think it's useful. Many people who uses 'pseudo monospace font' think it's useful too and hope to use it.
> it doesn't seem right to do this. I can't understand. What's wrong?
*** Bug 70817 has been marked as a duplicate of this bug. ***
Steve says, "We won't override the operating system behavior, especially when there is an option in the Eclipse UI to disable bolding".
This feature is expected to all usual editors. So, I think that Eclipse should support it. (it is unnecessary for people who use only ISO-8859-X, however such people is not the whole) The most of japanese editors use more than one operating system API like my patch when rendering bold font.
I cannot believe that after so many years this issue is still open. I had the very same problem with Lucida Console. Lucida Typewriter was okay, though. I do think thise patch should make it into the core product. A little hint for all those who wonder how to work around this problem: As I explained on StackOverflow [1], Microsoft Consolas is a good choice, even in size 8, as long as you activate ClearType. Dina is also okay, but I prefer Consolas. [1] http://stackoverflow.com/questions/145904/whats-a-the-best-small-font-for-eclipse/11041900#11041900
