Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!decwrl!mcnc!rti!bcw From: bcw@rti.rti.org (Bruce Wright) Newsgroups: comp.windows.ms.programmer Subject: Re: MDI devloper Pen Pal Summary: Lines and mapping modes Message-ID: <1991Apr17.153517.636@rti.rti.org> Date: 17 Apr 91 15:35:17 GMT References: <25920007@hpkslx.mayfield.HP.COM> Organization: Research Triangle Institute, RTP, NC Lines: 57 In article , dsampson@x102a.harris-atd.com (sampson david 58163) writes: > > [talking about writing text separated by horizontal lines, and > problems with rounding and aliasing effects] > > This routine draws the line below the row of text. So to get the > proper position, you have to go down the height of the character plus > some fraction of the external leading. I choose 0.3 off the top of my > head as I was typing this msg. The result of the multiplication will > also have to be converted to an integer. > > What I could not home in on was the proper fraction. If you choose a > mapping mode other than MM_TEXT, the coordinate conversion distortion > you mention will rear its head and byte you :) > > This approach also leads to major verticle offset problems when you > have lots of rows. Eventually the lines will overlap the text; once > again, due to the fraction rounding error and the mapping mode > coordinate distortion. OK, that gives me a better idea of what you were doing. I had similar problems with some other things I wrote, as long as I used floating point (the program wasn't drawing text, but the principles were the same). I finally gave up on using floating point for that purpose; things were always turning out to be a pixel off or something (and as I mentioned before, the eye can be drawn to that kind of error if it's part of a pattern). I finally started doing all of the computations manually, using integers. If the computations wouldn't fit in a short integer, I'd often have to convert to a long integer (usually just within the expression using the (long) type casting). It made for somewhat messier code, but most of the mess could be confined to a single scaling routine and a couple of macros. If you're careful on setting this up you can avoid the normal floating point rounding error. Plus, the program also was smaller and ran faster - no floating point runtime overhead. I'd also suggest positioning each text cell explicitly, and drawing the line associated with it based on the position you drew the text cell, not on where you compute the text cell ought to land. In my program, the scaling routine would compute how "high" every object ought to be, and saved this in global variables. Then I could find the start of the object with a simple, integer multiplication. It works better in MM_TEXT because you don't get the aliasing effects that you'd get in other modes, but even in something like MM_ANISOTROPIC you wouldn't get cumulative effects if both the text and the lines were drawn using the same scaling factor. Good luck - Bruce C. Wright