Jump to content
Software FX Community

Re: CFX98: Font does not scale when Paint() is called?


User (Legacy)
 Share

Recommended Posts

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...