Jump to content
Software FX Community

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


User (Legacy)
 Share

Recommended Posts

(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...