Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!mips!dimacs.rutgers.edu!rutgers!soleil!mlb.semi.harris.com!trantor.harris-atd.com!trantor!dsampson From: dsampson@x102a.harris-atd.com (sampson david 58163) Newsgroups: comp.windows.ms.programmer Subject: Re: MDI devloper Pen Pal Message-ID: Date: 16 Apr 91 15:55:52 GMT References: <25920007@hpkslx.mayfield.HP.COM> <1991Apr16.033639.11295@rti.rti.org> Sender: news@trantor.harris-atd.com Organization: Harris Gov't Aerospace Systems Division Lines: 70 In-reply-to: bcw@rti.rti.org's message of 16 Apr 91 03:36:39 GMT In article <1991Apr16.033639.11295@rti.rti.org> bcw@rti.rti.org (Bruce Wright) writes: You might have been seeing aliasing caused by having the mapping mode not match the display resolution. If you are setting the loop up properly the aliasing shouldn't be cumulative (as seems to have been the case with your problem from your description), but some lines would appear to be a pixel or two off. (Although this doesn't seem like a lot, for screens with a lot of horizontal or vertical lines the eye can often zero in on those that are a bit "off", even if the line isn't really very far off). The distortion from scaling from a mapping mode world coordinate system to the screen pixels was definitely a factor, but I don't think it was the major problem. If you look at the diagram in the Petzold book where he explains the tmHeight, tmInternalLeading, and tmExternalLeading, you can see that the area you have to play with in terms of drawing a line, is somewhere in the tmExternalLeading region. So as plan B, I tried to trigger the line drawing off of a fractional relationship like this: /* this is declared somewhere in the code */ yChar = tmHeight + tmInternalLeading + tmExternalLeading; /* now for the loop to draw the line between rows of text */ for (y = 1; y <= someMaxNum; y++) { /* location to draw line */ yLine = (yChar + .3 * tmExternalLeading) * y; /* then draw the line at yLine */ } 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. Any thoughts on a better approach? -- A new world record in the javalin throw / / / I ------------------------------------------------- David Sampson Harris Corporation dsampson@x102a.ess.harris.com Gov't Aerospace Systems Divison uunet!x102a!dsampson Melbourne, Florida -------------------------------------------------------------------------------