Closed
Bug 73539
Opened 24 years ago
Closed 4 years ago
Flaw in the ASCII path of nsTextFrame
Categories
(Core :: Internationalization, defect)
Tracking
()
RESOLVED
INVALID
Future
People
(Reporter: rbs, Assigned: smontagu)
Details
(Keywords: testcase)
Attachments
(2 files)
nsTextFrame includes ASCII code paths for measuring and rendering ASCII texts.
These code paths are the ones used whenever it is determined that the current
text run is entirely an ASCII string. For example, below is a code-section which
shows how PaintUnicodeText() or PaintAsciiText() can alternatively be used:
1234 NS_IMETHODIMP
1235 nsTextFrame::Paint(nsIPresContext* aPresContext,
1236 nsIRenderingContext& aRenderingContext,
1237 const nsRect& aDirtyRect,
1238 nsFramePaintLayer aWhichLayer)
1239 {
...
1265 // Choose rendering pathway based on rendering context performance
1266 // hint, whether it needs to be transformed, and whether it's
1267 // multi-byte
1268 PRBool hasMultiByteChars = (0 != (mState & TEXT_HAS_MULTIBYTE));
1269 PRUint32 hints = 0;
1270 aRenderingContext.GetHints(hints);
1271
1272 // If we have ascii text that doesn't contain multi-byte characters
1273 // and the text doesn't need transforming then always render as ascii
1274 if ((0 == (mState & TEXT_WAS_TRANSFORMED)) && !frag->Is2b() &&
!hasMultiByteChars) {
1275 PaintAsciiText(aPresContext, aRenderingContext, sc, ts, 0, 0);
1276
1277 } else if (hasMultiByteChars || (0 == (hints &
NS_RENDERING_HINT_FAST_8BIT_TEXT))) {
1278 // If it has multi-byte characters then we have to render it as
Unicode
1279 // regardless of whether the text fragment is 1-byte or 2-byte
characters.
1280 // Or if the text fragment requires transforming then leave it up
to the
1281 // rendering context's preference
1282 PaintUnicodeText(aPresContext, aRenderingContext, sc, ts, 0, 0);
1283 }
1284 else {
1285 // Use char rendering routine
1286 PaintAsciiText(aPresContext, aRenderingContext, sc, ts, 0, 0);
1287 }
The problem is that no safeguard is taken to ensure that the font being used is
indeed an *ASCII font*. Below is an excerpt of what typically happens later
in the GFX sub-system when the input is an ASCII string. Although there is a
comment on line 1786 suggesting that the validity of the font has to be checked
first, there is no such check. Instead the first font is used. Result: in some
circumstances the final rendering of an ASCII string may be incorrect.
This problem hampers the usage of some MathFonts which claim to be Unicode
fonts but can have any glyphs at ASCII positions.
1755 NS_IMETHODIMP
1756 nsRenderingContextWin::GetWidth(const char *aString,
1757 PRInt32 aLength,
1758 PRInt32 aAvailWidth,
1759 PRInt32* aBreaks,
1760 PRInt32 aNumBreaks,
1761 nscoord& aWidth,
1762 PRInt32& aNumCharsFit,
1763 PRInt32* aFontID = nsnull)
1764 {
...
1783 // Setup the font and foreground color
1784 SetupFontAndColor();
1785
1786 // Iterate each character in the string and determine which font to use
1787 nsFontMetricsWin* metrics = (nsFontMetricsWin*)mFontMetrics;
1788 PrevBreakState prevBreakState;
1789 nscoord width = 0;
1790 PRInt32 start = 0;
1791 nscoord aveCharWidth;
1792 metrics->GetAveCharWidth(aveCharWidth);
...
}
|
||
Comment 1•24 years ago
|
||
Please provide test procedure, expect result and actual result.
Mark this bug as Future for now.
Target Milestone: --- → Future
With the font installed, the following test case (to be attached) should
render "as is":
<html>
<head><title>Testcase: bug 73539</title>
<style type="text/css">
body { font-family: cmr10 }
</style>
</head>
<body>
<p>Common characters: {|}</p>
<p>Other characters: ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿
ÀÁÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕ×
èéêëìíîïðñòóõö÷øùúûüý</p>
</body>
</html>
Current result: something else is displayed (e.g., the common characters
doesn't appear as: '{', '|', '}').
|
|
||
Comment 7•24 years ago
|
||
mark all future new as assigned after move from erik to ftang
Status: NEW → ASSIGNED
|
||
Comment 8•22 years ago
|
||
.
Assignee: ftang → smontagu
Status: ASSIGNED → NEW
Component: Layout → Internationalization
QA Contact: petersen → ylong
|
Assignee | |
Updated•16 years ago
|
Attachment #29232 -
Attachment mime type: text/html → text/html; charset=iso-8859-1
|
||
Updated•15 years ago
|
QA Contact: amyy → i18n
|
|
||
Updated•4 years ago
|
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•