Thanks for that very thorough explanation, Eric. I think that we users (at least speaking for myself) often think that developing this stuff is easy, when it's really not, as evidenced by Eric's comments below. I had no idea that there were so many pitfalls and obstacles in doing something that "seems" to be easy. It's obviously not as easy as I thought.
Frank -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 14, 2004 11:42 PM To: [EMAIL PROTECTED] Cc: 'MapInfo-L'; Phillips, Frank Subject: Re: MI-L Rhetorical Question about DPI on a Vector File Let me add a few more points. The comments on the effects of changing the resolution on vector output are basically correct. I like to explain it similarly to what happens when you print to a higher resolution, even if you don't change the size of your map. At a higher resolution, fewer geographic points will converge to the same pixel as they would on the screen. This is also true for graphic elements like text and symbols. Particularly if you resize the metafile in some external program, you will see the impact starting with a higher resolution has. A little history here. Until 7.5, I believe, you had no control over the resolution of an exported metafile, WMF or EMF. Internally, the resolution for these formats was boosted to about 10 times the screen resolution. When this was first done, there was no resolution option on export for any format. Rasters were exported at screen resolution. Metafiles were a special case because we felt that many people used them to copy into other print programs where the output size would be determined there. We did not want to generate the metafiles at screen resolution and then have the picture lose clarity in the other programs. We also did this same metafile resolution increase with OLE embedded objects because you might embed the map object into Word or Powerpoint and then print it. Except for Excel, no other program actually requested another image during printing. For embedded objects, the image is always a metafile (not an enhanced metafile, by the way) So, if we generated a lower resolution metafile for the screen, that would be what you would get when you printed! However, as we started doing more raster imagery layers, metafiles became a bit of a problem. Boosting the resolution 10 times makes an image copy very large. Every pixel becomes 100 pixels! We made some compromises which we have continued to look at so that rasters look good without making the file sizes overly huge. Enhanced metafiles are much better and handle large images better but unfortunately, as mentioned above, embedded objects are stuck with the older metafile type. EMF also has real problems in Windows '95 and '98 that were really difficult to deal with. These and other GDI problems were essentially limiting what we could offer our NT and beyond customers! As developers, we were glad to see those platforms drop off the supported list. When we added translucent images to the product, the situation became more complicated as that algorithm involves merging pixels with what is underneath them. There is nothing "underneath" (no image surface) in a metafile. Special code gets used in this combination to make it work. In 7.5 we revisited this problem again as we added support for higher resolution bitmap symbols that needed to be supported using transparent options that result in the same sets of problems. During the 7.0 time period, we added use of a third party image library that allowed us to export raster images at controlled resolutions and make than an option in the software. However, metafiles were exempted from this because we did it automatically. In taking a more careful look in the 7.5 time frame, we saw no reason to not give the full control to the metafile formats as well. The advantage here is that you may not need the higher resolution and so now it is your choice. This might make a small difference with entirely vector data but with raster and vector, it will make a bigger difference. We are still looking at more optimal solutions to rendering images with all the features in a metafile particularly when this is used to send to a large plotter. I hope this adds something to this discussion. Eric Blasenheim Software Architect MapInfo Corporation Mail List:mapinfo-l-return-9853-mapperlist=mapinfo.com From: on 01/13/2004 06:18 PM GMT To: "Phillips, Frank" <[EMAIL PROTECTED]> cc: "'MapInfo-L'" <[EMAIL PROTECTED]> Subject: (Document link: MapInfo -L and Co.)Re: MI-L Rhetorical Question about DPI on a Vector File Hi Frank No Frank - there is a big advantage in using more dpi even for vector output to WMF. The Windows Meta File is a record of the GDI instruction and the coordinates. For example it records to draw a line from X1,Y1 to X2,Y2. The calculations of coordinates is done AFTER you specify the dpi resolution. ie the Map gets rerendered to the values you supply. If you want high accuracy in your image then the higher the range of coordinates the more accurate the differences will be.Imagine you had a grid of 100 x values evenly spread across only 50 dpi in width half of the values would map onto the other 50. If you had 200 dpi width then they would each be 2 dpi apart and look much better. WMF has a limit of 2 bytes per ordinate ie plus/minus 32000 approx. Its big brother EMF allows 4 bytes per ordinate ie 4.2 GB byte per ordinate. This is the same as MapInfos internal accuracy ie 4 bytes per x ( and 4 per y) and so output to Enhanced MetaFile will give you the best resolution of all but you will see the file size bigger because of the 4 bytes ( instead of 2 bytes ) Regards Bob Quoting "Phillips, Frank" <[EMAIL PROTECTED]>: > If I'm correct, the WMF file format is a vector format, unlike JPG and BMP > which are raster formats, and raster formats can take advantage of image > resolution (dpi or ppi). When I do a "Save Window As" from a layout, I am > offered the chance to input a dpi measure for the WMF file, which strikes > me > as useless, considering it's a vector format. What's even more strange is > that when I wrote out two WMF files from the same layout (one at 240dpi and > one at 96dpi), the 240dpi WMF was only 10% bigger in file size than the > 96dpi WMF. > > Anyone care to comment on this? Feel free to tell me if I'm all wet....I > don't get my feelings hurt. > > Frank Phillips > Manager of Marketing GIS > Vulcan Materials Company (NYSE:VMC) > Birmingham, AL, USA > > --------------------------------------------------------------------- > List hosting provided by Directions Magazine | www.directionsmag.com | > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > Message number: 9848 > > --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 9853 --------------------------------------------------------------------- List hosting provided by Directions Magazine | www.directionsmag.com | To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Message number: 9922
