Re: Font switching on different sizes???

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@xxxxxxxxxxxx> wrote in message
news:8cojf3tghq520dc7m1dtuhc11pmp98mpbs@xxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> wrote in message
news:pd9if3lsqvdu23i0kcqjmf15lv07530n01@xxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> wrote in message
news:9hghf39lfqt9cpasno8h19nt60onuiiolp@xxxxxxxxxx
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@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm

Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm


.

Relevant Pages

  • Re: Font switching on different sizes???
    ... To make sure you can reproduce the exact bug, ... It is very easy to reproduce the bug... ... happens also with every font specified... ... On the whole, MFC doesn't seem ...
    (microsoft.public.vc.mfc)
  • Re: PostScript fonts in MsOffice 2007
    ... a "bug" is a fault or flaw in the system that results in improper operation. ... However, there is at least one consequence of that operation-as-designed of the font substitution system, it gives an intended result, the font is substituted according to the rule set; however, you see a failure to render the Cyrillic glyphs properly. ... I would suggest contacting Monotype and seek their advice on changing your corporate font to one that has the look and feel you want and whose files will work with Office 2007 and the operating system possibly an Open Type Gill Sans. ... Check your computer for any variety of Gill Sans in Truetype format. ...
    (microsoft.public.word.printingfonts)
  • Re: StyleRef Formatting Frustrations
    ... I do not have to protect the document in order to provoke the bug. ... macros and templates for Microsoft Word ... the font change immediately. ... apply the styles prior to inserting form fields. ...
    (microsoft.public.word.docmanagement)
  • Re: BUG in Winsock on P4 HT CPU
    ... Its a bug in winsock plain and simple... ... I believe the bug is clearly in MFC. ... > notifications. ... > re-enabling functions are the recv functions plus WSAAsyncSelect itself. ...
    (microsoft.public.win32.programmer.networks)
  • Re: PostScript fonts in MsOffice 2007
    ... you will better be able to offer the managers good advice. ... stipulation of the request for improving the company font, ... I mean how to formulate them the request 'To buy Gill Sans Cyr Open Type or ... I am not sure that what you are seeing is a "bug" in the strict sense. ...
    (microsoft.public.word.printingfonts)
Loading