c164-1bj@cordelia.berkeley.edu (Jonathan Dubman) (10/19/87)
I have found a definite, repeatable bug in 1.2. The problem is in the Intuition text routines, when scrolling underlined text in a CLI window. An underlined charcter in the far upper right of a console device window leaves behind a dot when it scrolls. To see the bug, just type a Lattice map file (I know the 3.03 map file works) that is more than one screen long. Use the full-size 80 column CLI. At first I thought it was a flaky bit in memory. But it only occurred in the CLI and with map files. When I typed a different file with an underline in the upper right and saw the same bug, I realized the source. What worries me is the dot it might be leaving behind SOMEWHERE ELSE... *&(Jonathan "I do windows" Dubman)
dpvc@ur-tut.UUCP (Davide P. Cervone) (10/26/87)
In article <4442@zen.berkeley.edu> c164-1bj@cordelia.berkeley.edu (Jonathan Dubman) writes: >I have found a definite, repeatable bug in 1.2. The problem is in the >Intuition text routines, when scrolling underlined text in a CLI window. >An underlined charcter in the far upper right of a console device window leaves >behind a dot when it scrolls. I think this is more an unusual interaction between the console device and the text routines, rather than an honest-to-goodness bug. I believe what is happening is this: the console device determines what it thinks is the writable area of the window (i.e., the space within the left boundry and the right boundry areas; note that the right-hand boundry is wider than the left since it includes the sizing gadget). When the text moves off the right-hand side, it wraps it to the next line. WHen the text moves off the bottom of the window, it calls ScrollRaster on the writable area of the window, thus causing the scroll. Note that the console device does the scrolling, not the Intuition routines. In this case, I suspect what has happened is that the last dot of the underline has been written outside the scrolled area (i.e., it is in the right-hand boundry, which is not scrolled), so it never moves. Why does this happen? I can see two possibilities: either the console device does not use the underline text attribute when it calls IntuiTextLengh to find out how much space the text will take up; or, IntuiTextLength does not count the final dot. If it is the latter, then I might call it an Intuition bug, but I'm still not sure. The last dot is really the space between the last letter of the text and the next letter that will be printed. There are valid reasons why you would not want to include that dot in the length count. I'm not sure that IntuiTextLength guarentees that all rendering will occur within the length that it returns. In fact, I'm reasonably sure it doesn't. I'm pretty sure I can have letters that lap over the edges of their character boxes (like with descenders), and you should be able to do that horizontally, too. (for cursive-writing, for instance). >What worries me is the dot it might be leaving behind SOMEWHERE ELSE... I wouldn't worry about it causing any damage. It just might leave a bit or two here and there. If you are programming your own, you can take measures to avoid them. If you want them to go away on the CLI window, just resize the window to force it to redraw the borders. That will clear it up. > *&(Jonathan "I do windows" Dubman) Davide P. Cervone dpvc@tut.cc.rochester.EDU dpvc@ur-tut.UUCP DPVC@UORDBV.BITNET