47714 - Incorrect Symbol entity mapping

Reporter

Description

•

24 years ago

Navigator 6 uses the Unicode code points for the Symbol font glyphs, so, for 
example, the Symbol glyph lfloor is assigned code point 0x230A instead of 0xEB, 
as it was in Navigator 4.5.  Unfortunately, Navigator 6's mapping of that code 
point back to the proper Symbol font glyph is broken on the Macintosh -- it just 
displays a question mark.  (The Symbol font has the same layout on the Mac as on 
Windows.)

Here's a test page:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/
TR/REC-html40/loose.dtd">
<HTML><HEAD></HEAD>
<BODY>
<P>Symbols:<BR>
perp: <FONT face="Symbol">&#8869;</FONT><BR>
lceil: <FONT face="Symbol">&#8968;</FONT><BR>
rceil: <FONT face="Symbol">&#8969;</FONT><BR>
lfloor: <FONT face="Symbol">&#8970;</FONT><BR>
rfloor: <FONT face="Symbol">&#8971;</FONT><BR>
lang: <FONT face="Symbol">&#9001;</FONT><BR>
rang: <FONT face="Symbol">&#9002;</FONT><BR>
</P>
</BODY>
</HTML>

The first line (perp) works on the Mac, but the others are displayed as question 
marks.  There is currently no way to display these Symbol font characters.

    Waldemar

[It would be even nicer if this worked without having to say <FONT face="Symbol"> 
(as it does in the Windows version of Navigator), as that would allow the same 
page to work on both Navigator and Internet Explorer.]

A larger test script is at <http://www.mozilla.org/js/language/
testUnicodeCompatibility.html>.

[Assigning to ftang, who wrote adobesymbol.uf]

Waldemar Horwat

Reporter

Comment 1

•

24 years ago

Marking html4 -- this breaks the standard HTML 4.0 entities &lceil, &rceil, &
lfloor, etc.

Keywords: fonts, html4, nsbeta3

Frank Tang

Assignee

Comment 2

•

24 years ago

This problem is not caused by the Symbol to/from Unicode mapping inside Mozilla.
We currently let the Apple's ATSUI render those glyph. However, according to
Apple's Symbol font mapping table

0xE2    0xF8E8  # registered sign sans serif
0xE3    0xF8E9  # copyright sign sans serif
0xE4    0xF8EA  # trade mark sign sans serif
0xE5    0x2211  # N-ARY SUMMATION
0xE6    0xF8EB  # left paren top
0xE7    0xF8EC  # left paren extender
0xE8    0xF8ED  # left paren bottom
0xE9    0xF8EE  # left square bracket top
0xEA    0xF8EF  # left square bracket extender
0xEB    0xF8F0  # left square bracket bottom
0xEC    0xF8F1  # left curly bracket top
0xED    0xF8F2  # left curly bracket mid
0xEE    0xF8F3  # left curly bracket bottom
0xEF    0xF8F4  # curly bracket extender
0xF0    0xF8FF  # Apple logo
0xF1    0x232A  # RIGHT-POINTING ANGLE BRACKET
0xF2    0x222B  # INTEGRAL
0xF3    0x2320  # TOP HALF INTEGRAL
0xF4    0xF8F5  # integral extender
0xF5    0x2321  # BOTTOM HALF INTEGRAL
0xF6    0xF8F6  # right paren top
0xF7    0xF8F7  # right paren extender
0xF8    0xF8F8  # right paren bottom
0xF9    0xF8F9  # right square bracket top
0xFA    0xF8FA  # right square bracket extender
0xFB    0xF8FB  # right square bracket bottom
0xFC    0xF8FC  # right curly bracket top
0xFD    0xF8FD  # right curly bracket mid
0xFE    0xF8FE  # right curly bracket bottom

They are mapped into 0xF8XX range instead. That is why you cannot see those
Symbol character on Mac. From the ATSUI point of view. These characters are not
in the Symbol true type font.
I also use Fontographer to look at the Symbol font. Those glyph are in the font
but encoded as the Apple Unicode table

Possible fix is to do a remapping (Unicode to Unicode) in the ATSUI fallback
code before calling ATSUI.

Status: NEW → ASSIGNED

Frank Tang

Assignee

Comment 3

•

24 years ago

This is interesting, in http://www.w3.org/TR/html4/sgml/entities.html#h-24.3

it said 
<!-- Miscellaneous Technical -->
            <!ENTITY lceil    CDATA "&#8968;" -- left ceiling = apl upstile,
                                                 U+2308 ISOamsc  -->
            <!ENTITY rceil    CDATA "&#8969;" -- right ceiling, U+2309 ISOamsc  
-->
            <!ENTITY lfloor   CDATA "&#8970;" -- left floor = apl downstile,
                                                 U+230A ISOamsc  -->
            <!ENTITY rfloor   CDATA "&#8971;" -- right floor, U+230B ISOamsc  
-->
            <!ENTITY lang     CDATA "&#9001;" -- left-pointing angle bracket = 
bra,
                                                 U+2329 ISOtech -->
            <!-- lang is NOT the same character as U+003C 'less than' 
                 or U+2039 'single left-pointing angle quotation mark' -->


However, these characters are not encoding in the symbol.txt file under 
ftp://ftp.unicode.org .

Sean Richardson

Updated

•

24 years ago

Blocks: 17962

Frank Tang

Assignee

Comment 4

•

24 years ago

nsbeta3- per i18n bug meeting. Although I still want to fix this and it should 
be easy.

Whiteboard: nsbeta3-

rbs

Comment 5

•

24 years ago

The glyphs under consideration in the Symbol font are not really the glyphs
for &lceil, &lfloor, etc. In fact, these glyphs are "partial glyphs". MathML 
uses these pieces to build larger variants. For example to build a really *tall*
right square bracket ']' in a given area, the top glyph 0xF9 ("right _square
bracket_ top") will be placed at the top, the bottom glyph 0xFB ("right _square
bracket_ bottom") will be placed at the bottom, and as many pieces of the middle
glyph 0xFA ("right _square bracket_ extender") will be used to fill the gap
between the top and the bottom. This "stretching" process is also used to build
large parenthesis, etc, using the other partial glyphs in the Symbol font (or
some other "symbolic font"). An example showing the final outcome of the 
stretching process that MathML does with these glyphs can be seen at: 
http://www.mozilla.org/projects/mathml/screenshots/start.gif

So the summary of this bug is not correct. There are other fonts (such as those
in the ucvmath module) that have the real glyphs for &lceil, &lfloor, etc.

Frank Tang

Assignee

Comment 6

•

24 years ago

fix-
Index: nsUnicodeRenderingToolkit.cpp
===================================================================
RCS file: /cvsroot/mozilla/gfx/src/mac/nsUnicodeRenderingToolkit.cpp,v
retrieving revision 1.17
diff -c -2 -r1.17 nsUnicodeRenderingToolkit.cpp
*** nsUnicodeRenderingToolkit.cpp	2000/06/14 23:40:25	1.17
--- nsUnicodeRenderingToolkit.cpp	2000/08/16 00:34:20
***************
*** 96,100 ****
    (0x2666 == (c))      \
    )
! 
  #define BAD_TEXT_ENCODING 0xFFFFFFFF
  
--- 96,104 ----
    (0x2666 == (c))      \
    )
! #define SPECIAL_IN_SYMBOL_FONT(c) ( \
!   IN_RANGE(c, 0x2308, 0x230b) || \
!   (0x2329 == (c))   || \
!   (0x232a == (c))    \
!   )
  #define BAD_TEXT_ENCODING 0xFFFFFFFF
  
***************
*** 261,264 ****
--- 265,269 ----
  }
  //------------------------------------------------------------------------
+ static PRUnichar gSymbolReplacement[]=
{0xf8ee,0xf8f9,0xf8f0,0xf8fb,0x3008,0x3009};
  
  PRBool nsUnicodeRenderingToolkit :: ATSUIFallbackGetWidth(
***************
*** 269,278 ****
  {
  	if (nsATSUIUtils::IsAvailable()  
! 	    &&  (IN_STANDARD_MAC_ROMAN_FONT(*aCharPt) ||IN_SYMBOL_FONT(*aCharPt)))
  	{
  		mATSUIToolkit.PrepareToDraw(mPort, mContext );
! 		nsresult res = mATSUIToolkit.GetWidth(aCharPt, oWidth, aSize, 
  													origFontNum, 
  													aBold, 
aItalic, aColor);
  		if(NS_SUCCEEDED(res))
  			return PR_TRUE;
--- 274,295 ----
  {
  	if (nsATSUIUtils::IsAvailable()  
! 	    &&  (IN_STANDARD_MAC_ROMAN_FONT(*aCharPt) ||IN_SYMBOL_FONT(*aCharPt)||
SPECIAL_IN_SYMBOL_FONT(*aCharPt)))
  	{
  		mATSUIToolkit.PrepareToDraw(mPort, mContext );
! 		nsresult res;
! 		if(SPECIAL_IN_SYMBOL_FONT(*aCharPt)) {
! 			 short rep = 0;
! 			 if((*aCharPt) > 0x230b)
! 			 	rep = (*aCharPt) - 0x2325;
! 			 else 
! 			 	rep = (*aCharPt) - 0x2308;
! 			 res = mATSUIToolkit.GetWidth(gSymbolReplacement+rep, oWidth, 
aSize, 
! 													origFontNum, 
! 													aBold, 
aItalic, aColor);
! 		} else {
! 			 res = mATSUIToolkit.GetWidth(aCharPt, oWidth, aSize, 
  													origFontNum, 
  													aBold, 
aItalic, aColor);
+ 		}
  		if(NS_SUCCEEDED(res))
  			return PR_TRUE;
***************
*** 290,299 ****
  {
  	if (nsATSUIUtils::IsAvailable()
! 	   &&  (IN_STANDARD_MAC_ROMAN_FONT(*aCharPt) ||IN_SYMBOL_FONT(*aCharPt)))
  	{
  		mATSUIToolkit.PrepareToDraw(mPort, mContext );
! 		nsresult res = mATSUIToolkit.DrawString(aCharPt, x, y, oWidth, aSize, 
  													origFontNum, 
  													aBold, 
aItalic, aColor);
  		if(NS_SUCCEEDED(res))
  			return PR_TRUE;
--- 307,328 ----
  {
  	if (nsATSUIUtils::IsAvailable()
! 	   &&  (IN_STANDARD_MAC_ROMAN_FONT(*aCharPt) ||IN_SYMBOL_FONT(*aCharPt)||
SPECIAL_IN_SYMBOL_FONT(*aCharPt)))
  	{
  		mATSUIToolkit.PrepareToDraw(mPort, mContext );
! 		nsresult res;
! 		if(SPECIAL_IN_SYMBOL_FONT(*aCharPt)) {
! 			 short rep = 0;
! 			 if((*aCharPt) > 0x230b)
! 			 	rep = (*aCharPt) - 0x2325;
! 			 else 
! 			 	rep = (*aCharPt) - 0x2308;
! 			res = mATSUIToolkit.DrawString(gSymbolReplacement+rep, x, y, 
oWidth, aSize, 
  													origFontNum, 
  													aBold, 
aItalic, aColor);
+ 		} else {
+ 			res = mATSUIToolkit.DrawString(aCharPt, x, y, oWidth, aSize, 
+ 													origFontNum, 
+ 													aBold, 
aItalic, aColor);
+ 		}
  		if(NS_SUCCEEDED(res))
  			return PR_TRUE;

Whiteboard: nsbeta3-

Frank Tang

Assignee

Updated

•

24 years ago

Whiteboard: nsbeta3+ fix in hand

Waldemar Horwat

Reporter

Comment 7

•

24 years ago

Attached file Simple test case — Details

Waldemar Horwat

Reporter

Comment 8

•

24 years ago

It's interesting that &lang and &rang (U+2329 and U+232A) didn't work either on 
my system (Mac OS 9.0.4) using the simple test case -- they also displayed as 
question marks.  If the font table above is right, they should work.  What's 
going on?

Frank Tang

Assignee

Comment 9

•

24 years ago

fix and check in. waldemar@netscape.com - please retest this. I also fix &rang; 
and &lang;

Frank Tang

Assignee

Comment 10

•

24 years ago

fix and check in.

Status: ASSIGNED → RESOLVED

Closed: 24 years ago

Resolution: --- → FIXED

Teruko Kobayashi

Comment 11

•

24 years ago

I verified this in 2000-09-11-08 build.

Status: RESOLVED → VERIFIED

Vidar Haarr (not reading bugmail)

Updated

•

20 years ago

OS: Mac System 9.x

Bugzilla

Quick Search

Incorrect Symbol entity mapping

Categories

(Core :: Internationalization, defect, P3)

Tracking

()

People

(Reporter: waldemar, Assigned: ftang)

References

Details

(Keywords: fonts, html4, Whiteboard: nsbeta3+ fix in hand)

Crash Data

Security

(public)

User Story

Attachments

(1 file)

Description

Comment 1

Comment 2

Comment 3

Updated

Comment 4

Comment 5

Comment 6

Updated

Comment 7

Comment 8

Comment 9

Comment 10

Comment 11

Updated

Attachment

General

Description

File Name

Content Type