More Printing questions..... Merry Christmas
Cameron_C
I have been struggling with this item for some time.
For a while I was content to ignore it, but it has finally made it to the
top of my list.
I have an application where the User may choose reporting fonts.
Three fonts. One for the header, one for the body, and one for the footer of
the various reports. I save the LOGFONT structures for later use.
At the time I do a StartDocument I grab the LOGFONT structures I had
previously saved, and CreatePointFontIndirect to create the fonts.
As I walk through the code in debug mode, everything seems to work fine.
However, the printing works perfectly on an HP 9040DN, but no details appear
when I print to a Brother or the HP Photosmart I have. The graphics boxes do
appear though.
Anyway my first question relates to the voodoo-like black magic of scaling
the font.
I want a ten point font. I select a ten point font from the CFontDialog, and
save it. Later, when I want to create the font I call
CreatePointFontIndirect, and I pass a value that is in tenths of a point. So,
now I would pass 100, for my ten point font.
From experience this never worked. After poking through various web sites, I
found someone had success with using a "Cook''s Constant" of 42/13. So, I
have taken my value of 100, and multipled by 42/13. Is this obtuse or am I
off base here? Anyway, this appears to do the trick, at least for the HP
printer.
I checked the Microsoft docs, and they suggest using something along the
lines of -MulDiv(m_lfReportHeader.lfHeight/10,
m_dc.GetDeviceCaps(LOGPIXELSY), 72);
Now, I have tried this with the printers that do not deliver the report as
execpted, and I see no difference. I have not tried this with the HP printer
that is really working.
Here is a code snippet showing how I have created the fonts.
/*
Assign default Report Header Font for the Reports
Note: m_szIniSectionName will refer to the specific Report for the Printer.
m_ProcessIni.m_szIniSectionName will refer to the DEFAULT entries
for the Printer.
*/
LOGFONT lfIniDefaults;
BOOL bFlag=FALSE;
TEXTMETRIC myTextMetrics;
m_ProcessIni.m_szIniKeyName.LoadString(IDS_REPORTHEADERFONT);
bFlag = m_ProcessIni.getKeyValueForFont(&lfIniDefaults,
m_ProcessIni.m_szIniKeyName, m_szIniSectionName);
if (!bFlag) // No font information available from the ini file, so save
DEFAULT
{
m_ProcessIni.setKeyValueForFont(m_plfReportHeader,
m_ProcessIni.m_szIniKeyName, m_szIniSectionName);
}
else
{
m_lfReportHeader = lfIniDefaults;
}
lfIniDefaults = m_lfReportHeader;
lfIniDefaults.lfHeight*=(42/13); // I have no idea why this scaling is
required... But it is. Found this in a news group.
// lfIniDefaults.lfHeight = -MulDiv(m_lfReportHeader.lfHeight/10,
m_dc.GetDeviceCaps(LOGPIXELSY), 72);
/*
Establish Font characteristics for the Report Header lines.
lfIniDefaults Points to a LOGFONT structure that defines the
characteristics
of the logical font.
The lfHeight member of the LOGFONT structure is measured in tenths of a
point
rather than logical units.
(For instance, set lfHeight to 120 to request a 12-point font.)
CreatePointFontIndirect returns non-zero when successful.
If bFlag is zero, we have a problem!
*/
CFont*pOldHeaderFont, *pOldFooterFont, *pOldBodyFont;
m_cfReportHeader.DeleteObject();
bFlag = m_cfReportHeader.CreatePointFontIndirect(&lfIniDefaults, &m_dc);
pOldHeaderFont = m_dc.SelectObject(&m_cfReportHeader);
m_pcfReportHeader = &m_cfReportHeader;
// m_hFontReportHeader is the CGdiObject public data member that stores
the handle
m_hFontReportHeader = (HFONT) pOldHeaderFont->GetSafeHandle();
//m_hFontReportHeader = (HFONT) m_pcfReportHeader->GetSafeHandle();
/* Get Average size of printed text for the Header Font */
m_dc.GetTextMetrics(&myTextMetrics);
m_yLineHeader = myTextMetrics.tmHeight;
Later when I want to use the font in a report, I select the font, and do a
DrawText.
Here is a code snippet:
pcfOriginal =
ts->_this->PrinterControl.m_dc.SelectObject(ts->_this->PrinterControl.m_pcfReportHeader);
iPrintedHeight=ts->_this->PrinterControl.m_dc.DrawText(szHeader,
rclHeader, DT_TOP|DT_CENTER);
iPrintedHeight=ts->_this->PrinterControl.m_dc.DrawText(szSubHeader,
rclSubHeader, DT_TOP|DT_CENTER);
pcfOriginal =
ts->_this->PrinterControl.m_dc.SelectObject(ts->_this->PrinterControl.m_pcfReportFooter);
iPrintedHeight=ts->_this->PrinterControl.m_dc.DrawText(szFooter,
rclFooter, DT_BOTTOM|DT_CENTER);
szBuffer.Format(_T("Page %d"), ++lPageNumber);
iPrintedHeight=ts->_this->PrinterControl.m_dc.DrawText(szBuffer,
rclFooter, DT_BOTTOM|DT_RIGHT);
pcfOriginal =
ts->_this->PrinterControl.m_dc.SelectObject(ts->_this->PrinterControl.m_pcfReportBody);
One last question, I know that the Fonts are applicable for the DC that has
been selected. When the DC is destroyed, and recreated, do the Fonts need to
be recreated? Do I need to destroy and recreate the fonts every time I
destroy and recreate the DC? Should I?
Today, I plan to try to sift through SuperPad. I believe it is the Microsoft
sample which may help me out here.
Thanks for any information, and Merry Christmas!
.......Cameron
Joseph M. Newcomer
On Tue, 22 Dec 2009 05:27:01 -0800, Cameron_C <Came...@discussions.microsoft.com> wrote:
>Hello Everyone.
>I have been struggling with this item for some time.
>For a while I was content to ignore it, but it has finally made it to the
>top of my list.
>I have an application where the User may choose reporting fonts.
>Three fonts. One for the header, one for the body, and one for the footer of
>the various reports. I save the LOGFONT structures for later use.
>At the time I do a StartDocument I grab the LOGFONT structures I had
>previously saved, and CreatePointFontIndirect to create the fonts.
>As I walk through the code in debug mode, everything seems to work fine.
>However, the printing works perfectly on an HP 9040DN, but no details appear
>when I print to a Brother or the HP Photosmart I have. The graphics boxes do
>appear though.
>
>Anyway my first question relates to the voodoo-like black magic of scaling
>the font.
>I want a ten point font. I select a ten point font from the CFontDialog, and
>save it. Later, when I want to create the font I call
>CreatePointFontIndirect, and I pass a value that is in tenths of a point. So,
>now I would pass 100, for my ten point font.
****
The truth is that the font is scaled to the display. If you want to use that font on a
printer, you must scale it to the printer.
Typically, you want to use CFont::CreatePointFontIndirect and for the second parameter
pass in your printer DC for printing and either NULL or your display DC for display.
*****
>From experience this never worked. After poking through various web sites, I
>found someone had success with using a "Cook''s Constant" of 42/13. So, I
>have taken my value of 100, and multipled by 42/13. Is this obtuse or am I
>off base here? Anyway, this appears to do the trick, at least for the HP
>printer.
****
Sounds like sheer luck. I have no idea what this is doing.
*****
>I checked the Microsoft docs, and they suggest using something along the
>lines of -MulDiv(m_lfReportHeader.lfHeight/10,
>m_dc.GetDeviceCaps(LOGPIXELSY), 72);
>Now, I have tried this with the printers that do not deliver the report as
>execpted, and I see no difference. I have not tried this with the HP printer
>that is really working.
*****
It may be a function of the printer dirvers, but it seems obtuse if it is.
****
>Here is a code snippet showing how I have created the fonts.
> /*
> Assign default Report Header Font for the Reports
> Note: m_szIniSectionName will refer to the specific Report for the Printer.
> m_ProcessIni.m_szIniSectionName will refer to the DEFAULT entries
> for the Printer.
> */
> LOGFONT lfIniDefaults;
> BOOL bFlag=FALSE;
> TEXTMETRIC myTextMetrics;
>
> m_ProcessIni.m_szIniKeyName.LoadString(IDS_REPORTHEADERFONT);
> bFlag = m_ProcessIni.getKeyValueForFont(&lfIniDefaults,
>m_ProcessIni.m_szIniKeyName, m_szIniSectionName);
****
Have you considered the Registry for this? My Registry library actually saves some font
information automatically. I see no value in parsing font information from a .INI file (I
gave up doing that when I abandoned Win16 many years ago)
****
> if (!bFlag) // No font information available from the ini file, so save
>DEFAULT
> {
> m_ProcessIni.setKeyValueForFont(m_plfReportHeader,
>m_ProcessIni.m_szIniKeyName, m_szIniSectionName);
> }
> else
> {
> m_lfReportHeader = lfIniDefaults;
> }
> lfIniDefaults = m_lfReportHeader;
> lfIniDefaults.lfHeight*=(42/13); // I have no idea why this scaling is
>required... But it is. Found this in a news group.
****
Neither do I, it looks really bogus, like someone discovered some random value which gave
the illusion of working so claimed it made sense. 42/13 is silly anyway; 42/13 is 3, and
expressed as 42/13 doesn't change the fact it is 3. And I have no idea what 3 does. Now
42.0/13.0, working as a double, e.g.,
something =(int)( (double) something * 42.0 / 13.0)
might have meaning, but "3" is just silly.
****
>// lfIniDefaults.lfHeight = -MulDiv(m_lfReportHeader.lfHeight/10,
>m_dc.GetDeviceCaps(LOGPIXELSY), 72);
****
If you get rid of the gratutitous *=3, this should work correctly. But it is what
CreatePointFontIndirect does. Read the code.
****
>
> /*
> Establish Font characteristics for the Report Header lines.
> lfIniDefaults Points to a LOGFONT structure that defines the
>characteristics
> of the logical font.
> The lfHeight member of the LOGFONT structure is measured in tenths of a
>point
> rather than logical units.
> (For instance, set lfHeight to 120 to request a 12-point font.)
> CreatePointFontIndirect returns non-zero when successful.
> If bFlag is zero, we have a problem!
> */
> CFont*pOldHeaderFont, *pOldFooterFont, *pOldBodyFont;
*****
Never use commas in declaration lists. And there is no reason to save old state like
"OldHeaderFont"; instead, use CDC::SaveDC and CDC::RestoreDC to mainain the purity of your
DC.
****
>
> m_cfReportHeader.DeleteObject();
> bFlag = m_cfReportHeader.CreatePointFontIndirect(&lfIniDefaults, &m_dc);
****
OK, you Are using CreatePointFontIndirect, so why all that other stuff which either
duplicates it or duplicates it badly?
****
> pOldHeaderFont = m_dc.SelectObject(&m_cfReportHeader);
****
I have not saved an "old setting" on SelectObject in about 20 years. Use
SaveDC/RestoreDC. Otherwise, you get a lot of garbage variables and lose track of them
(there are over 30 DC parameters you might want to save the "old" version of!)
****
> m_pcfReportHeader = &m_cfReportHeader;
*****
How in the world does this assigment make any sense whatsoever? It is complete nonsense.
Get rid of it.
****
> // m_hFontReportHeader is the CGdiObject public data member that stores
>the handle
> m_hFontReportHeader = (HFONT) pOldHeaderFont->GetSafeHandle();
*****
This makes even less sense. Why do you need an HFONT anyway? There is something
seriously wrong hwere with what you are doing.
****
> //m_hFontReportHeader = (HFONT) m_pcfReportHeader->GetSafeHandle();
> /* Get Average size of printed text for the Header Font */
> m_dc.GetTextMetrics(&myTextMetrics);
> m_yLineHeader = myTextMetrics.tmHeight;
>
>Later when I want to use the font in a report, I select the font, and do a
>DrawText.
>Here is a code snippet:
> pcfOriginal =
>ts->_this->PrinterControl.m_dc.SelectObject(ts->_this->PrinterControl.m_pcfReportHeader);
****
There is no need to store the original. m_dc.SaveDC() will save the DC state. Get rid of
the assignment.
What is _this?
If this is a subroutine that is being called for each of the headers, just pass the font
in as a CFont& and when you need the address, use & on that. This business of having some
memver variable which is set to a pointer doesn't make sense.
****
> iPrintedHeight=ts->_this->PrinterControl.m_dc.DrawText(szHeader,
>rclHeader, DT_TOP|DT_CENTER);
> iPrintedHeight=ts->_this->PrinterControl.m_dc.DrawText(szSubHeader,
>rclSubHeader, DT_TOP|DT_CENTER);
> pcfOriginal =
>ts->_this->PrinterControl.m_dc.SelectObject(ts->_this->PrinterControl.m_pcfReportFooter);
****
I'm already confused. You set pcfOriginal to one value when you select the header font,
and then you overwrite that when you select the footer font (and why would you not simply
write
&ts->_this->PrinterControl.m_cfReportFooter
instead of that silly technique of storing pointer variables which you then use here?) so
what is it going to be restored to?
****
> iPrintedHeight=ts->_this->PrinterControl.m_dc.DrawText(szFooter,
>rclFooter, DT_BOTTOM|DT_CENTER);
> szBuffer.Format(_T("Page %d"), ++lPageNumber);
> iPrintedHeight=ts->_this->PrinterControl.m_dc.DrawText(szBuffer,
>rclFooter, DT_BOTTOM|DT_RIGHT);
> pcfOriginal =
>ts->_this->PrinterControl.m_dc.SelectObject(ts->_this->PrinterControl.m_pcfReportBody);
****
You really need to understand what the & operator does, and where you use it. All those
intermediate pointer-to-font variables are completely silly!
I note that at no point do you restore the font you changed, that is, I see no
....m_dc.SelectObject(pcfOriginal);
and that means that saving the value is pointless. And then you leave the font selected
into the DC, which is poor practice. See my essay on SaveDC/RestoreDC on my MVP Tips
site.
****
>
>
>One last question, I know that the Fonts are applicable for the DC that has
>been selected. When the DC is destroyed, and recreated, do the Fonts need to
>be recreated? Do I need to destroy and recreate the fonts every time I
>destroy and recreate the DC? Should I?
****
Yes. Because if I create a font for my one printer (1200dpi) then close the printer, and
then open another DC on the other printer (600 dpi), my fonts would be 2x too large. So
it is rare I would create the fonts as member variables at all. I would typically create
them in the printing routine handler, and let the normal CFont::~CFont destructor get rid
of them when I was done printing. I don;t use global variables when local variables would
do. And I'm willing to pass parameters around, including a parameter which is my printing
context, e.g.,
class PrintingContext {
public:
CFont Header;
CFont Section;
CFont MajorTitle;
CFont Text;
};
and initialize those variables. I'd probably have a constructor that took the CDC and
created the fonts relative to it. And I'd probably have other things in it such as the
current line, current page #, etc., and never, ever, under any conditions imaginable would
those be member variables in any view class or anyplace outside this PrintingContext
object. Then all my functions would take a PrintingContext& parameter that would give me
access to this information. When the printing is done, it goes away, all the fonts go
away, and I never see any of them ever again until I need to do another print run. I
would have a "generic" LOGFONT structure that I used for storing the data, but it would
only be passed in to my font constructors in my PrintingContext object.
Localize information as tightly as you can,
And never store a pointer-to-something if you can COMPUTE the pointer-to-something on
demand. You added meaningless complexity to your class and your code by introducing these
pointer variables!
joe
****
>
>Today, I plan to try to sift through SuperPad. I believe it is the Microsoft
>sample which may help me out here.
>
>Thanks for any information, and Merry Christmas!
>
>.......Cameron
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Cameron_C
I removed the coding for the 42/13, and tried with the
m_dc.GetDeviceCaps(LOGPIXELSY), 72);
almost read some of it.
But this is progress, at least something is printing.
I also just found that if I use SetBkMode(TRANSPARENT) just before I begin
to print, the report appears on my HP Photosmart printer. (Found it by
accident when I accidentally uncommented the wrong line).
When I print, I get a printer dc, then I define the fonts. The I select the
font I want and I drawtext.
This works fine on one printer. And, since I added the SetBkMode it works on
another (although I have no understanding of why this would be). But still
fails to print on my little Brother printer.
One more curiousity, when I create font defaults, I do the following:
CFont cfPrinterFont;
m_bFlag = m_pApp->CreatePrinterDC(m_dc);
/* Establish Default Font characteristics for the Reports */
cfPrinterFont.Attach(::GetStockObject(DEVICE_DEFAULT_FONT));
LOGFONT lf;
cfPrinterFont.GetLogFont(&lf);
lf.lfHeight *= 10;
cfPrinterFont.Detach();
cfPrinterFont.CreatePointFontIndirect(&lf, &m_dc);
cfPrinterFont.GetLogFont(&m_lfReportHeader);
Now, later when I try to use the LOGFONT, I get characters that are the
expected height, but are so thin they are unrecognizable.
So, I reset the lfWidth to zero, in this LOGFONT structure, before I
CreatePointFontIndirect.
And, at least then I can see the characters.
Why does the width need to be 0 (which requests the default)? I thought if I
requested the DEVICE_DEFAULT_FONT for the printer DC, I would get all of the
values I needed?
Are there any other values I get in the LOGFONT that I should reset before
creating a font?
And then one more question.
Maybe this is not an appropraite technique? I use a CFontDialog to allow the
Users to select the fonts for the reports.
LOGFONT lf = m_pPrinterControl->m_lfReportHeader;
lf.lfHeight = -MulDiv(m_pPrinterControl->m_lfReportHeader.lfHeight/10,
m_pDC->GetDeviceCaps(LOGPIXELSY), 72);
CFontDialog fdHeader(&lf,
CF_PRINTERFONTS | CF_EFFECTS | CF_INITTOLOGFONTSTRUCT | CF_ENABLEHOOK
| CF_FORCEFONTEXIST,
m_pDC);
Should the m_DC refer to the printerDC? Or to the display DC.
I think it has to be the display but I am not sure?
Thanks,
"Joseph M. Newcomer" wrote:
> .
>
Stephen Myers
> Thanks Joe,
> I removed the coding for the 42/13, and tried with the
> lfIniDefaults.lfHeight = -MulDiv(m_lfReportHeader.lfHeight/10,
> m_dc.GetDeviceCaps(LOGPIXELSY), 72);
Why divide lfHeight by 10? You are about to divide by 72 anyway. Doing
so creates resolution problem for you. Consider that you will get the
same font for all starting heights of 10 through 19.
Steve
Cameron_C
When I run the code with the division by 10, the printed font appears to be
very very small maybe a two or three point font.
When I do not do the division by ten I get a font that is about half an inch
high.
When I invoke GetPointFontIndirect, I am passing 60, as the lfHeight, which
I believe indicates that I want 60 tenths of a point or a six point font.
Printing does not seem to be very straightforward.
Merry Christmas.
Thanks,
Joseph M. Newcomer
joe
***
Never set lfWidth. Leave it 0 (default). Otherwise, you get the strange effects you are
seeing.
You can download my font explorer and play with it, but you will see that lfWidth is not a
good value to use.
****
>So, I reset the lfWidth to zero, in this LOGFONT structure, before I
>CreatePointFontIndirect.
>And, at least then I can see the characters.
>Why does the width need to be 0 (which requests the default)? I thought if I
>requested the DEVICE_DEFAULT_FONT for the printer DC, I would get all of the
>values I needed?
****
TrueType/OpenType fonts will adjust themselves by horizontal scaling to conform to the
lfWidth if you do not default it.
****
>Are there any other values I get in the LOGFONT that I should reset before
>creating a font?
>
>And then one more question.
>Maybe this is not an appropraite technique? I use a CFontDialog to allow the
>Users to select the fonts for the reports.
> LOGFONT lf = m_pPrinterControl->m_lfReportHeader;
> lf.lfHeight = -MulDiv(m_pPrinterControl->m_lfReportHeader.lfHeight/10,
>m_pDC->GetDeviceCaps(LOGPIXELSY), 72);
> CFontDialog fdHeader(&lf,
> CF_PRINTERFONTS | CF_EFFECTS | CF_INITTOLOGFONTSTRUCT | CF_ENABLEHOOK
>| CF_FORCEFONTEXIST,
> m_pDC);
>
>Should the m_DC refer to the printerDC? Or to the display DC.
>I think it has to be the display but I am not sure?
****
Ideally, the printer DC for selecting printer fonts. Again, get rid of the /10 (note this
is integer divide, so 18/10 = 1, which leads to your problems). But generally, if you use
the display, the fonts are available for the display. This dichotomy predates the
TrueType world, and in those days it allowed you to specify native printer fonts for
dot-matrix printers and primitive inkjet and laser printers. It is generally no longer an
issue.
joe
****
Cameron_C
I think this may relate to using MM_TWIPS rather than MM_TEXT.
When I replaced MM_TEXT with MM_TWIPS, AND I divided the logical font height
(in tenths of a point) by ten, I think I am seeing the correct results. At
least on one printer.
"Stephen Myers" <""StephenMyers"@discuss" wrote:
Cameron_C
What value should be in the lfHeight, when I am looking for a six point font?
I know that I should use tenths of a point (so sixty) when I
CreatePointFontIndirect.
But, what do I want to put through the scaling math? Do I need tenths of a
point? Or full point values?
I believe that the MulDiv(a,b,c) is supposed to give me (a*b)/c.
But, do I start with tenths of a point or point values? Six or sixty?
When I use sixty, my font is now about one inch high.
And when I use six, I get something pretty small. Maybe it is six points.
And this is since I changed to set to MM_TWIPS after creating the printer DC.
Maybe I should not use MM_TWIPS?
Stephen Myers
where you put the divide.
Change the 72 to 720 and you will get values on the same order of
magnitude without throwing away resolution.
Consider MulDiv(19/10,1024,72) vs MulDiv(19,1024,720)
14 vs 27
Steve
Joseph M. Newcomer
decipixels. But that is a feature CreatePointFont (look at its code). So yes, if you are
giving font heights in decipoints, you want the / 10, but you had not actually indicated
that you were using decipoint heights.
If you are doing CreateFontIndirect, you must use the actual height with the muldiv
computation. If you are doing CreatePointFont[Indirect] to a printer DC, the base
computations are already done for you, so you don't want to do them yourself; the result
will not be meaningful.
Your choice of font height representation is yours. But remember that if you are doing
CreateFont[Indirect] you want the height in pixels, not decipixels. If you are doing
CreatePointFont[Indirect], its specificaiton is decipixels, in which case you would not be
doing a muldiv yourself.
Ultimately, you are going to get a font in pixels. To get a 10-point font on a 10ppi
display, there is a 1:1 correspondence,but on a 600dpi display, to get a 10-point font it
would be 10 * (600/72). If you do this in floating point, you get 6000/72, and that is
essentially 83 pixels high. So if you single-step in far enough to
CreatePointFont[Indirect] you should see a real CreateFont creating a font which is the
right number of pixels for your device. An 18-point font would be 18*600/72 or about 150
pixels high. Notice that the order matters. I tend to do computations in floating point
and then round them and convert back to an integer; saves all kinds of hassle with integer
truncation problems.
If you are using MM_TWIPS, then you have 1440 pixels/inch, so an 18-point font is
18*1440/72 = 360 pixels high. GDI takes care of mapping twips-based coordinates to
physical device coordinates.
Note that if you are using a raw printer DC, the assumption is that you are using MM_TEXT.
So if you want to use CreatePointFont[Indirect] and specify a DC, the DC has to be in the
mapping mode you are going to use. Doesn't matter if it is TWIPS, LOENGLISH, HIENGLISH,
LMETRIC, HIMETRIC, or your own custom ISOTROPIC or ANISOTROPIC mapping, whatever mapping
you are going to use for the drawing is what should be set. Generally you do this in
OnPrepareDC, so you would call that at the point where you are about to create the font.
Frankly, I would not waste any effort trying to create the font in advance of printing.
When I got into the OnDraw handler, after PrepareDC is called, that is the only place I
would create the fonts. They would not be member variables of the class; they would be
local variables of the OnDraw function. When I left OnDraw, they would be implicitly
destroyed by the destructors of the local variables. I would have no reason for them to
exist outside the context of OnDraw (or OnPaint).
joe
Cameron_C
This answers everything I need to know about the calculations.
Honestly, I have searched through Microsoft's documentation, but I did not
find this explained. At least not in any meaningful way I could understand.
After making the changes, the scaling is fine.
I can print to two printers now.
I am still not having much luck with my Brother printer.
I will keep researching and I will post back anything I find.
Merry Christmaas Joe, you have been very helpful all year long.
Thanks,
.......Cameron