Incorrect Symbol entity mapping

VERIFIED FIXED

Status

()

Core
Internationalization
P3
normal
VERIFIED FIXED
18 years ago
13 years ago

People

(Reporter: Waldemar Horwat, Assigned: Frank Tang)

Tracking

({fonts, html4})

Trunk
PowerPC
Mac System 9.x
fonts, html4
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: nsbeta3+ fix in hand)

Attachments

(1 attachment)

(Reporter)

Description

18 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]
(Reporter)

Comment 1

18 years ago
Marking html4 -- this breaks the standard HTML 4.0 entities &lceil, &rceil, &
lfloor, etc.
Keywords: fonts, html4, nsbeta3
(Assignee)

Comment 2

18 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
(Assignee)

Comment 3

18 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 . 

Updated

18 years ago
Blocks: 17962
(Assignee)

Comment 4

18 years ago
nsbeta3- per i18n bug meeting. Although I still want to fix this and it should 
be easy. 
Whiteboard: nsbeta3-

Comment 5

18 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.
(Assignee)

Comment 6

18 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-
(Assignee)

Updated

18 years ago
Whiteboard: nsbeta3+ fix in hand
(Reporter)

Comment 7

18 years ago
Created attachment 13085 [details]
Simple test case
(Reporter)

Comment 8

18 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?
(Assignee)

Comment 9

18 years ago
fix and check in. waldemar@netscape.com - please retest this. I also fix &rang; 
and &lang; 
(Assignee)

Comment 10

18 years ago
fix and check in.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 11

18 years ago
I verified this in 2000-09-11-08 build.
Status: RESOLVED → VERIFIED
OS: Mac System 9.x
You need to log in before you can comment on or make changes to this bug.