Software FX Posted September 1, 2000 Report Share Posted September 1, 2000 Please. If you can send us a sample program that reproduces the problem it will be much easier to help you. -- Frank SFX "Petr Prikryl" <Answer.via.news.please.prikrylp@nospam.skil.nospam.cz.nospam> wrote in message news:IPaN#mAFAHA.1416@sfxserver.softwarefx.com... > > 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.