There are several blank lines where there should be text in the article at http://www.microsoft.com/presspass/features/7-23realnet.htm
Rick, I think this is a parser problem.
The content model has the text in place; it's not a parser problem but must be a layout problem instead...
The missing text contains octal 222 characters which trigger our text code going into the "it's unicode" path which is not yet implemented.
The problem with the text code not rendering unicode data has been fixed. Now the problem is that the rendering system (gfx) doesn't know how to handle unicode rendering properly (it needs to support the font set abstractions from navigator so that different ranges of characters can select into different fonts since most fonts don't support the entire unicode character set). That's why I'm reassigning the bug to greg since he's now been tagged as libfont boy :-)
Trying to reassign *again*
Troy -- I'm not sure who on your team is handling this now -- could you please reassign to the appropriate person. Thanks.
Who handled libfont?
Sparky: I'm giving this *hot potato* to you, since it involves complex fonts. Keep this as a placeholder until the i18n guys fix the font stuff.
Setting all current Open/Normal to M4.
changing the component to i18n since this deals with unicode related font issues. Also, I sent a side note to i18n QA asking who should be qa assigned. Changing assigned to - to bobj
1. update the URL to the right one 2. reassign to erik
Octal 222 is decimal 146, hex 92, name RIGHT SINGLE QUOTATION MARK. This code is part of CP 1252 (windows-1252). The Windows GFX font engine can display this character, so it must be the parser or scanner that is not properly converting from CP 1252 to Unicode. Re-assigning to ftang. Frank, are you working on this part?
Change the summary to "ISO-8859-1 should be converted as CP 1252" from "Missing line of text" Cata, we should use cp1252.uf and cp1252.ut to deal with ISO-8859-1 charset. Mark it as M5.
*** Bug 4551 has been marked as a duplicate of this bug. ***
change back to M4
fixed and check in
Teruko, this looks fixed to me... I'll leave it to you to verify it though.
I verified this in 4-26-8 Win32 build.