User (Legacy) Posted September 1, 2000 Report Share Posted September 1, 2000 Francisco Padron wrote... > >dc.GetDeviceCaps() > >Is not MFC ???? No, it is not. As I wrote earlier, I do use WTL (template library) which transforms the upper mentioned call almost directly to the ::GetDeviceCaps(). The WTL::CDC (or WTL::CDCHandle) hides the only DC handle. Its methods are very straightforward. Unlike MFC, no magic is hidden inside. >MFC keeps TWO hDC inside de CDC, that's why you get a result. The print >preview in MFC DOES crate a memory DC. > >If you are printing directly to a Printer DC, just remove all scalling (map >one logical pixel to 1 physical pixel) and call Paint with CPAINT_PRINT, >Chart FX will make the appropriate conversions. [...] As I wrote in previous message (see below), I do not use any preview support. Would it useful if I prepared some simple demonstration application? Petr (the older text follows) >"Petr Prikryl" ><Answer.via.news.please.prikrylp@nospam.skil.nospam.cz.nospam> wrote in >message news:gR8ukMmEAHA.1416@sfxserver.softwarefx.com... >> (the shortened version of the original article can be >> found at the end of this message) >> >> Thanks, Frank, for clarifying the reasons. However, >> it seems to me that this does not fully fit to the >> observed situation. I think that I need more >> information about how the size of fonts is >> recalculated. Could you comment this or could you >> point to some documentation? >> >> (BTW, I did read the Q1381013, but it was rather >> difficult to access the page. The search engine >> does not show any link -- probably the missing >> title of the document is the reason. I did access >> the page finally using >> http://support.softwarefx.com/kb/138/1/013.htm >> >> There probably is the logical error in the >> article. The second argument in the SetWindowExt() >> should probably contain nPrnHeight, not the >> nPrnWidth. Another minor problem is that I had to >> replace tabs for spaces to be able to print the >> HTML page; some code falled out of the right >> margin of the paper.) >> >> After the following details, I do ask another >> question that is related to scaling the fonts when >> the chart is displayed on the screen in a preview >> window (hand written code) with THE ZOOM FACTOR >> SETTING REQUIRED. >> >> >> Details on the problem with scaling fonts >> ----------------------------------------- >> >> I did observe the problem of font scaling in the >> situation when the device context was directly >> related to a physical printer. When I called the >> following just before the chart Paint()... >> >> int xOutRes = dc.GetDeviceCaps(LOGPIXELSX); >> int xOutWidth = dc.GetDeviceCaps(HORZRES); >> >> spChartFX->Paint(reinterpret_cast<long>(dc.m_hDC), >> rcChart.left, rcChart.top, >> rcChart.right, rcChart.bottom, >> ChartfxLib::CPAINT_PRINT, 0); >> >> I did obtain xOutRes equal to 600 (HP LaserJet 5) and >> xOutWidth equal to 4727 (i.e. 7.8783333... inch) which >> corresponds well with the 200mm returned when called >> dc.GetDeviceCaps(HORZSIZE). >> >> The dc is the instance of WTL::CDCHandle. I do not >> use MFC, nor any "preview code" implemented in WTL. >> In other words, there is no special code hidden >> behind the scene, and the device context is the >> printer's device context (not the memory DC). >> >> I think that the behaviour is somehow related to the >> mapping mode which was set as follows (before the >> Paint()): >> >> dc.SetMapMode(MM_ANISOTROPIC); >> >> dc.SetWindowExt(2540, 2540); >> dc.SetViewportExt(dc.GetDeviceCaps(LOGPIXELSX), >> dc.GetDeviceCaps(LOGPIXELSY)); >> >> Here the 2540 is one inch in hundredths of >> milimeters. >> >> When the same result is printed (physically) to >> LaserJet 3 and LaserJet 5, then the default height of >> the Y-axis labels is about 0.5 mm for the 300 dpi >> printer and about 0.25 mm for 600 dpi printer (hard >> to measured, the height on 600dpi printer seems to be >> the half of height on 300dpi printer). >> >> I admit that I am not fluent with mapping modes and >> there may be some error "between the chair and the >> keyboard". But what mistake am I doing? >> >> >> Related question to displaying chart with scaled font >> on the screen >> ----------------------------------------------------- >> >> This question is closely related to the upper question. >> I tried to play with the code based on the one from >> the Q1381013 article in situation when the preview is >> displayed on the display. >> >> The problem is that the zoom capability is required >> here. In other words, the user can choose how big the >> preview window or what even what part of the page he >> or she wants to look at (window with scrolls with >> high magnification -- only the smal part of the page >> is visible). Here, the font of the chart should be >> scaled according to the current mapping mode >> (Window/Viewport ratio). >> >> The chart part of the page should behave as if it was >> a picture (fonts scaled to the size for the final >> output device). The difference, in comparison with >> the hypothetical picture, is no dependency on the >> display and/or final output device resolution. I.e., >> the chart should be painted again, but the ratio of >> font size to the chart size should be preserved. >> >> I was not successfull to implement the above >> mentioned feature. Fonts were always scaled so that >> they looked the same size on the display >> independently on the zoom factor of the preview. >> >> Am I doing a mistake or is it the CFX98 feature? >> >> >> Thanks for explanation, >> >> Petr >> >> >> "Francisco Padron" <frankp@softwarefx.com> wrote... >> > >> > When CPAINT_PRINT is specified the size of the fonts >> > is recalculated based on the resolution of the >> > current device context vs. the screen resolution. If >> > the device context you are passing is a Memory DC >> > (e.g Metafile) this can not be obtained therefore >> > the conversion will not be made. >> > >> > Check out article Q1381013 for more details >> [...] >> > >> > "Petr Prikryl" [...] wrote ... >> [...] >> > > >> > > I do have problem when calling the Paint(). The font >> > > which is used for labeling axes (I did not try other >> > > fonts) does not scale for different device context >> > > while the chart does. >> [...] >> > > The device context uses MM_ANISOTROPIC mapping mode. >> > > The logical coordinates are in 1/100 of mm. The >> > > ViewportExt and WindowExt are set differently for a >> > > display and for various printers to obtain 1:1 >> > > visual appearance. The auxiliary ruler marks and >> > > some text (painted using the device context) show >> > > that the mapping works as desired both on the >> > > display and on the tested printers. >> > > >> > > The chart displayed by Paint() fills correctly the >> > > given rectangular area leaving only some (expected) >> > > small margins. However, the font on 300 DPI printer >> > > is very small. The chart fills the given rectangle >> > > correctly again. In other words, the ratio between >> > > the font size and the chart-box size changes. >> > > I tried to choose a different font name and size, >> > > but the problem remains. >> [...] -- Petr Prikryl, SKIL s.r.o., e-mail: prikrylp at skil dot cz Please, don't reply via e-mail. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.