HyperHCl / gdipp

Automatically exported from code.google.com/p/gdipp
0 stars 0 forks source link

Java - Font clipping #69

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Which program triggers the problem? Specify the filename if possible.
Netbeans, MATLAB (Java based), but not Eclipse

What steps will reproduce the problem?
1. Type text
2a. Netbeans: Set font to Consolas 16
2b. MATLAB: Set Desktop Code font to Consolas 10/12/14/16

What is the expected output? What do you see instead?
Highly clipped characters

What version of gdipp (including renderer)? On which operating system?
0.8 x64 on Win 7 Enterprise x64, renderer=2 in settings.xml

Please provide any additional information below. Screenshots always help.

Original issue reported on code.google.com by harshava...@gmail.com on 31 May 2010 at 11:44

Attachments:

GoogleCodeExporter commented 8 years ago
I don't debug these applications, but seems the problem may be caused that the 
words
and glyph runs are issued character by character, and the clipping rectangle is
specified too restrictive.

Original comment by crendk...@gmail.com on 1 Jun 2010 at 11:41

GoogleCodeExporter commented 8 years ago
OK. Any tips on what settings I can use in the .xml for such processes?

P.S - Thanks a lot for gdipp, it is much more easier and appealing to use 
windows now, 
esp for programming.

Original comment by harshava...@gmail.com on 2 Jun 2010 at 7:42

GoogleCodeExporter commented 8 years ago
I took a look at NetBeans, and found that this is similar to issue 69
(http://code.google.com/p/gdipp/issues/detail?id=66). My guess was right, that
NetBeans calls ExtTextOut character by character. However, after one character 
is
ExtTextOut, it will not be ever called again, until the font size is changed.
Obviously Java does font caching internally, probably like the Flyweight pattern
(http://en.wikipedia.org/wiki/Flyweight_pattern, which is suitable for text 
editors).

The problem is caused like this, taking Consola 18pt "n" as an example: the cell
ascent is 14 rows. Text origin is (0, -7). ClearType has exactly 7 rows ascent 
while
FreeType has 8 rows. Therefore, 1 row above the origin Y-axis, which is 
discarded by
NetBeans.

General solution could be hooking GDI's metrics calculating APIs and supply
FreeType's new metrics. However, this may require system-wide caching to 
guarantee
acceptable performance, which is rather a long-term plan.

Original comment by crendk...@gmail.com on 3 Jun 2010 at 5:24

GoogleCodeExporter commented 8 years ago
I revisited this issue, and found the source of the problem. Java font manager 
uses GetGlyphOutline() to get the actual metrics of each character. Then it 
calls ExtTextOut with the glyph origin and bounding box to get glyph bitmap 
without internal space, therefore minimize cache size.

To solve the problem, it is required to override GetGlyphOutline and return the 
metrics the current gdipp renderer would generate. I think it is possible to 
accomplish, however, the introduced compatibility issue is still unknown.

Original comment by crendk...@gmail.com on 3 Jul 2010 at 4:44

GoogleCodeExporter commented 8 years ago
Solved in the development version. We hook GetGlyphOutline, and adjust the 
glyph metric. Now NetBeans 6.9 work perfectly.

Original comment by crendk...@gmail.com on 9 Aug 2010 at 7:12

Attachments:

GoogleCodeExporter commented 8 years ago
I found the "workaround" I used to solve this problem conflicts with Google 
Picasa. This is because the replacement of GetGlyphOutline() is not complete 
yet. Only the glyph metrics is substituted with the FreeType version. Therefore 
this issue will remain open until a full GetGlyphOutline() replacement is 
completed in some later version.

Original comment by crendk...@gmail.com on 21 Aug 2010 at 3:49

GoogleCodeExporter commented 8 years ago
Thanks for the update and the great work.

Could you tell me know to exclude the netbeans.exe process from gdipp? I put in

        <process name="netbeans.exe">
            <renderer>0</renderer>
        </process>

so that it does not use gdipp, but that does not have any effect at all on 
netbeans. If I change netbeans.exe to notepad.exe, I can clearly see the 
default rendering taking place in the windows notepad editor pane, so I atleast 
know that the .xml is correct.

Thanks.

Original comment by harshava...@gmail.com on 27 Aug 2010 at 1:04

GoogleCodeExporter commented 8 years ago
To exclude a process, you should put the process executable name in the 
<exclude>/<process> nodes, as shown in the documentation and the default 
setting file.

You can also do what you show here. I can't reproduce the problem you see. 
Every text is rendered by ClearType.

Original comment by crendk...@gmail.com on 27 Aug 2010 at 2:14

GoogleCodeExporter commented 8 years ago
Still cannot exclude netbeans, or even eclipse for that matter, after putting 
the process name in exclude/process nodes. Only when i exclude javaw.exe does 
netbeans and eclipse get excluded. 

System is Win7 x64 enterprise, and in process manager netbeans 6.9 shows up as 
"netbeans.exe *32".

Original comment by harshava...@gmail.com on 30 Aug 2010 at 4:55

GoogleCodeExporter commented 8 years ago
My solution is add the following code in your gdimm section:

<process name="idea.*">
    <renderer>20</renderer>
</process>

Restart your IntelliJ IDEA (or netbeans or any other Java GUI app) and you see 
the perfect effects

Original comment by greenlaw...@gmail.com on 5 Apr 2012 at 5:25