In the 9-2-98 build of NGLayout,   characters render with a black filled circle, instead of blank.

I went to http://www5.localweb.com/fingerstyle/mozillaZine/home.html and could not reproduce the bug...any more clues? like does a current build do it for you? does it happen on a PC like the bug report says, or maybe on linux instead? thanks...

These bugs happen on a Win95 PC running Win95 pre OSR2, with font smoothing enabled. Curiously enough, the font smoothing occurs even with font-smoothing turned off in the display properies! Is that now a feature of NGLayout? Every build of NGLayout has had the exact same problem. Every &nbsp; renders with a black dot, sort of like the dot that can accompany a list item (but smaller). When there are many &nbsp; in a row, they run flush against one another. I had assumed that the &nbsp; was being represented by a dot for layout testing purposes (to see how much space it was taking). I guess I was wrong! :) This bug is still following me into the 9-10-98 build of NGLayout. At http://www5.localweb.com/fingerstyle/mozillaZine/ I see a little black dot on the orange field directly beside the smokestack. An &nbsp; is in that <TD></TD>. A black dot also appears beside the title of each news item (directly to the left, where I had placed an &nbsp;. Finally, One appears in the deep red field of the title of each news item, to the right of the date. Since there are no font controls in the NGLayout viewer, I can't set to a different font to see if that's the issue. Basically, all of the fonts are rendering as I expect, so you may want to try installing Verdana and Georgia on your machine. They're TrueType fonts available from the evil empire at: http://www.microsoft.com/typography/fontpack/default.htm If you look at Demo #9 in the NGLayout viewer package, in the top frame I see a string of &nbsp; between the words "Frame 1" and "Frame 2" that head the two inline frames. The chain is broken in 3 places. That's the best I can do to describe it for the moment. --chris

I did some testings on a win95 machine (it's OSR2 at least) and still could not see the problem. I tried it before installing w95gray.exe (the font smoother from microsoft) and after installing it with font smoothing enabled and disabled and could not reproduce the bug. Can you try writing a simple test page that demonstrates the bug and then using alt-print-screen to save the bits and then email the bits and the test case to me?

There was a bug in text compression....

The whitespace compression code in nsTextFrame.cpp was missing, in two places, a check for NBSP's consequently they were being rendered as is. On NT this isn't a problem, and on some fonts it's not a problem, but on a vanilla win95 with the default font it rendered a black blot.

installing myself as QA Contact en masse