I'm not sure if I have to be happy that I managed to identify a rare MFC
bug, or cry! :-(
It is very easy to reproduce the bug... Just create a new View/Doc
project, and implement the default printing functions (override OnPrint)
you can override also the OnBeginPrinting or OnPreparePrinting to set page
range or substract margins from the printing rect, but it is not
neccessary for this test...
By the way: I have just found that it happens also with english text! not
only hebrew! I recognize the fonts, and they are switching... And it
happens also with every font specified...
And another "by the way"!!!:
When writing this message, I opened the devstudio to copy a sample code in
here, and I noticed something! I was specifying the font's height as a
negative value, because it should give a more accurate match for a
character height, rather than a cell height with leading spaces...
I did a little test, and when specifying positive value instead - The bug
disappeared! The fonts remained consistent! Yippie!
For reproducing the bug, do the following in OnPrint:
CFont * pOldFont=pDC->GetCurrentFont();
CFont font;
font.CreateFont(-CalcConsistentY(pDC, 20), 0, 0, 0, FW_BOLD, FALSE, FALSE,
0, HEBREW_CHARSET,
OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, ANTIALIASED_QUALITY,
DEFAULT_PITCH , _T("Tahoma"));
pDC->SelectObject(&font);
pDC->DrawText(_T("Test text, or hebrew text here, doesn't matter"),
&pInfo->m_rectDraw, DT_TOP | DT_CENTER | DT_SINGLELINE);
pDC->SelectObject(pOldFont);
int CalcConsistentY(CDC *pDC, int iYSize)
{
CSize sz;
int perinch = pDC->GetDeviceCaps(LOGPIXELSY);
sz.cx = sz.cy = (perinch*iYSize)/72;
pDC->DPtoLP(&sz);
return sz.cy;
}
Have fun! :-p
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:8cojf3tghq520dc7m1dtuhc11pmp98mpbs@4ax.com...
I'm stuck. There's something going wrong, but I don't quite know how to
attack it without
seeing some code sample. If I had this problem, I'd be spending a lot of
time, as I said,
single-stepping through MFC code trying to see what it was doing wrong
(which probably
meant I was setting something up wrong). On the whole, MFC doesn't seem
to have the same
quality problems that products like VS has (perhaps it is actually tested
before release),
so I've seen very few actual MFC bugs over the years. But there's always
the chance
you've identified a real MFC bug.
joe
On Wed, 26 Sep 2007 02:36:02 +0200, "Martin Bl."
<guest@discussions.microsoft.com> wrote:
Yes it is UNICODE, and everything is inside _T("") brackets... The code
is
very clean, and no extra playing with the DC...
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:pd9if3lsqvdu23i0kcqjmf15lv07530n01@4ax.com...
Is this a Unicode app? I've not tried this with fonts in other ranges,
but are you using
the Unicode range to get the Hebrew fonts? Otherwise, I'm not sure how
I'd proceed with
this short of doing a lot of single-stepping through the MFC source.
joe
On Tue, 25 Sep 2007 15:19:18 +0200, "Martin Bl."
<guest@discussions.microsoft.com> wrote:
I'm specifying the font name... _T("Tahoma"), just like this! not
loading
from anywhere dynamically...
And I recognize the font when it is used, but on a certain size,
there's
the
bug. And it is not too big, because it prints well on much bigger
sizes...
"David Lowndes" <DavidL@example.invalid> wrote in message
news:9hghf39lfqt9cpasno8h19nt60onuiiolp@4ax.com...
I'm using MFC to print preview, and with most hebrew fonts (windows'
default
fonts),
the font is switching to another font on certain size. It mean that
if I
zoom in the print preview, on a certain zoom, I get another font!
Martin,
In your drawing code where you specify the font, are you explicitly
setting the font face name? I might expect what you're seeing to
happen if you're not specifying the font face name.
Dave
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm