United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4896465 : Box drawing characters have wrong font metrics in LucidaTypewriterRegular.ttf

Details
Type:
Bug
Submit Date:
2003-07-25
Status:
Open
Updated Date:
2012-09-27
Project Name:
JDK
Resolved Date:
Component:
client-libs
OS:
generic
Sub-Component:
2d
CPU:
generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
1.4.0,1.4.2
Targeted Versions:

Related Reports

Sub Tasks

Description

Name: dk106046			Date: 07/25/2003

java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)

Problem also seen in 1.4.1 and 1.4.0


------------
Open the font shipped with the JDK in any font viewer program. For
example on Unix/Linux:
xfd -start 9472 -fn -jdk-lucidatypewriter-medium-r-normal--0-0-0-0-m-0-iso10646-1

This should start xfd on the page containing the characters affected.
0x2500 <==> decimal 9472.

Characters from Unicode 0x2550 to 0x256c appear to be affected.

The xfd program clearly shows the box drawing characters overlapping the
character bounding box. This is also how the affected characters appear
when displayed on Java graphical components.

The problem can be partly seen on Windows Character Map utility. However
this program clips the characters affected. Java graphical components
on Windows do not clip the characters affected - they are displayed
overlapping the character bounding box.

======================================================================

                                    

Comments
WORK AROUND



Name: dk106046			Date: 07/25/2003

None, for this particular font the affected characters are always displayed
overlapping the bounding box because that's the information contained in
the font itself.
======================================================================
                                     
2004-06-11
EVALUATION



Name: inR10103			Date: 07/30/2003


  I confirm that problem is reproducible if you select 
"Lucida Sans Typewriter" if Font2DTest and set unicode range to 2500-267f
(affected glyphs are in range 2565-2666).
  I also checked other software (like Microsoft Charmap and even Fontlab)
also have the problem with these glyphs because they have too big descent
(comparing to font metrics).

In fact font metrics for the font are:
 Font metrics=sun.font.FontDesignMetrics[font=java.awt.Font[
    family=Lucida Sans Typewriter,name=Lucida Sans Typewriter Regular,
    style=plain,size=50]ascent=48, descent=11, height=59]
and bounds for one of glyphs (\u2fcf)
  Glyph metrics=java.awt.geom.Rectangle2D$Float[x=0.0,y=-43.328125,w=20.484375,h=80.296875]

Therefore:
  1) i do not see any Java2D font rendering problem here 
      (we do the best we can)
  2) all code that rely on usage of FontMetrics may show these glyphs 
      with artefacts. 

      Generic solution (not for this particular
      font) depends on particular case - it could be either 
      usage of GlyphMetrics instead of FontMetrics or clipping region
      outside font bounding box or something else. 

      If these symptoms could be observed on standard AWT/Swing components 
     then i suggest to file bugs against these components. 
      
  3) Font2DDemo also shows overlaps but i do not think this is bug
       because it gives impression about difference of FontMetrics
       and GlyphMetrics. Clipping here is not good idea because 
       this is just hiding symptoms (that can be important to make decisions).
       Moreover, zoomed version of any glyph is clipped.

  4) Generally speaking there is no obligation that all font glyphs 
     are fitting into font bounding box. 
     But because "Lucida Sans Typewriter" font is shipped with JDK and 
      is supposed to be used with JDK it could be nice to update 
      shipped fonts somehow (if it possible).      

Conclusion:
   I propose to recategorize this bug to those who are responsible for fonts
shipped with jdk.


======================================================================
                                     
2004-06-11



Hardware and Software, Engineered to Work Together