[RESOLVED] Font Help

I have an application that provides a preview of the RTF files it generates. The preview renders each page using combinations of the Times Roman and Courier New fonts with a size of 8 points.

Problem:
The size of the Courier New text is rendered larger than the Times Roman text which results in the text exceeding the page rectangle.

If I render everything in Times Roman at 8 point it matches the output from Word (My Output Reference) within a mm or so over the page length. If I render the data using Courier New I exceed the page length by 8 lines on the display.

Printing also produces a variation in text length but due to the higher printer resolution it is not as great.

I have looked at the values of the screen resolution using GetDeviceCaps(LOGPIXELSY) which returns the default 96 pixels per inch.

Using the GetDeviceCaps(VERTRES) and (VERTSIZE) I get a resolution of 91 or 76 depending on the display.

Using these resolutions improves reduces the height of the text but still not enough to achieve the required representation.

I've also tried CreateFontIndirect and CreatePointFont to see if this makes a difference which unfortunately it hasn't.

Can anyone provide some insight into a reliable method to correctly display Courier New fonts with the same accuracy as the other true type fonts.

The two images that demonstrate my issue.


The first image contains the lower portion of two printed versions. The Top most is the output generated using Word. Whilst the lower most is the same page printed fropm my application. The bottom of the columns with repect to the footer (Issue xx...) shows the variation in text sizes between the two.

The second image shows the same page rendered by my application with the colum data extending below the page and over writing the footer.


As detailed in many references and guides, "the majority of time you will spend formating output when utilising the MFC SDI/MDI printing interfaces." For this project they sure have this right.:confused:

Can you post/email code you are using in GEtDeviceCaps() and CreateFont()...

Below is the code used to determine the resolution of the Device used within my app.

Code:

---

int CalculateYPixels(CDC* DeviceContext)
{
    int VertRes = DeviceContext->GetDeviceCaps(VERTRES);
    int Height = DeviceContext->GetDeviceCaps(VERTSIZE);
    float PixelsInch = (((float)VertRes / (float)Height) * 25.4) + 0.5;

    if(PixelsInch > 300)
        PixelsInch = DeviceContext->GetDeviceCaps(LOGPIXELSY);

    return (int) PixelsInch;
}

---

The following is an extract of my code that shows how each font is created.

Code:

---

        memset(&WorkingLogFont, 0, sizeof(LOGFONT));
        DeviceContext->GetCurrentFont()->GetLogFont(&WorkingLogFont);

        WorkingLogFont.lfWidth = 0;
        WorkingLogFont.lfWeight = FW_NORMAL;
        WorkingLogFont.lfCharSet = ANSI_CHARSET;
        WorkingLogFont.lfOutPrecision = OUT_DEFAULT_PRECIS;
    WorkingLogFont.lfClipPrecision = CLIP_DEFAULT_PRECIS;
        WorkingLogFont.lfPitchAndFamily = FIXED_PITCH;

      lstrcpy(WorkingLogFont.lfFaceName, GetFontName(CellParaFont));

            WorkingLogFont.lfHeight = -MulDiv(GetFontSize(CellParaFont), PixelsInch, 72);

        if(WorkingFont->CreateFontIndirect(&WorkingLogFont))
        {
                OldFont = DeviceContext->SelectObject(WorkingFont);
        }

---

CellParaFont font is a CString which represents the font face name of either "Times Roman New" or "Courier New" and the size of the font as defined in the RTF V1.6 spec. Each of the routines using this data returns the correct values.

Stepping trough the code shows that all elements of the LogFont have been initialised with the expected values and the CreateFont indirect function return true indicating successful completion.

Using the GetTextFace funct shows that the Courier New font is being used with the TextOut function used to generate the text.

Looks close to what I use in my programs...

Code:

---

        pDC = GetDC();
        int iLogPixY = GetDeviceCaps(pDC->m_hDC, LOGPIXELSY);
        ReleaseDC(pDC);


        memset(&lf, 0, sizeof(LOGFONT));
        lf.lfHeight = -MulDiv(iDefFontSize, iLogPixY, 72);
        lf.lfWidth = 0;
        lf.lfItalic = 0;
        lf.lfWeight = FW_NORMAL;
        lf.lfOutPrecision = OUT_TT_PRECIS;
        lf.lfQuality = PROOF_QUALITY;
        lf.lfCharSet = DEFAULT_CHARSET;
        strcpy(lf.lfFaceName, szDefFontName);
        pCFont.CreateFontIndirect(&lf);

---

I've search many online resources for an answer but I can't seem to find one.

I don't know if changing the Map Mode to WW_TWIPS would help but it appears that Word uses twips to define all size data it may be a hint.

Will need to look further.

Quite possible they only use TWIPS....I only use MM_HIENGLISH in my programs and all looks the same if printed directly or to a PDF...

My APP uses the default MM_TEXT Mapping, which as stated earlier works fine for Times Roman font @ 8 point height.

I going to test it at 10 point to see if it is infact the sizing of the font by windows.

I think Microsoft may not be using the same techniques to scal the fonts in word as available via VC++.

Quote:

---

Originally Posted by sma

I think Microsoft may not be using the same techniques to scal the fonts in word as available via VC++.

---

Are you thinking that M$ might be holding back some functionality for their own use that is not available to Developers...would they do that ?? LOL

I just did a test which printed the same 15 lines of 10 point Courier New from both Word and directly to the printer from my app.

Overall Word Heght = 56mm, My App = 53.5 meaning and additional

3.5mm/14 = 0.25mm in line height.

Over 61 lines Word = 240.5, My App = 225mm -> 15.5/60 = 0.258mm

Given 1 point = 25.4/72 -> 0.352mm it is clear that some further manipulation of fon sizes is occuring.

Also noted that the Word rendering of a page on the same display at a scale of 100% shows a with variation of 4mm, Word = 234 my app shows 230 when the LOGPIXELSX is used to for all size conversions.

The line height in Word on the display is also larger than that printed so it is clear that some other scaling is occurring.

So it is actually changing the font size and not the line spacing ?

Overlaying the two printouts it appears that the individual characters are slightly larger when printed from Word. So I would say that the font size has been manipulated in some way.

This does prevent the printouts from matching exactly however the issue is with the screen representation and the inability to render all of the page data within the required area.

I was considering creating a DC of the resolution of the connected printer (600 x 600) representing the page, rendering the page and then using StrBlt to reduce this to the page area drawn on the screen.

My concern with this approach would be the clarity of the resultant text and what would I do if the end user had no printer connected?

Let me do some testing on my system using Courier New...

Ok, thanks for your help I hope you come to the same conclusions.

Quote:

---

Originally Posted by sma

Ok, thanks for your help I hope you come to the same conclusions.

---

Well actually I came up with 2 printouts that are exactly the same...I printed Courier New 10pt from within Word (2001 Small Business) and a MFC App of mine (code posted above)...I then measured the height of a "I" (upper case "i")...both were .0845in or 2.15mm in height.

Guess that either my calculations are incorrect or I have compounded rounding of values which I can't seem to locate.

When you output the text to the DC what function do you use?

Do have an example I could review?

The errors seem to be larger the lower the resoluton used when comparing printer and display outputs.

Quote:

---

Originally Posted by sma

Guess that either my calculations are incorrect or I have compounded rounding of values which I can't seem to locate.

When you output the text to the DC what function do you use?

Do have an example I could review?

The errors seem to be larger the lower the resoluton used when comparing printer and display outputs.

---

Ck your PM inbox...

Thank you for the code, I think that my issue is with the use of the MM_TEXT mapping which means 1 pixel = 1 logical unit which is not of a high enough resolution to make my results accurate.

The use of MM_HIENGLISH means that the logical unit is mapped to represent 0.001 inches which means any calculations will be more accurate less rounding errors.

Unfortunately it means that my drawing algorithms now need modifying to reverse the Y coordinates as +ve now means up.

Also what Text drawing function do you use, textout, exttextout, drawtext etc?

Also from your code you have effectively scaling factors used with each resolution are the standard or something you have determined yourself?

Thanks for your help on this I will let you know how I get on.

Quote:

---

Originally Posted by sma

Also what Text drawing function do you use, textout, exttextout, drawtext etc?

Also from your code you have effectively scaling factors used with each resolution are the standard or something you have determined yourself?

Thanks for your help on this I will let you know how I get on.

---

I use TextOut() unless I need to do a WordBreak then I use DrawText()...

The scaling factor was from hours of rough calc's then fine tuning with hundred of pages printed and faxed...

Changed over to use MapMode MM_HIGHENGLISH

No luck or improvement.

Distance over 33 Lines:

Word = 127.94
App HIGHENGLISH = 117.98
App TEXT = 119.33

Measured I

Word = 2.12mm close enough to your measurements.
App HIGHENGLISH = 2.12mm
App TEXT = 2.12m

Quote:

---

Originally Posted by sma

Changed over to use MapMode MM_HIGHENGLISH

No luck or improvement.

Distance over 33 Lines:

Word = 127.94
App HIGHENGLISH = 117.98
App TEXT = 119.33

Measured I

Word = 2.12mm close enough to your measurements.
App HIGHENGLISH = 2.12mm
App TEXT = 2.12m

---

If font height is the same then I would look for the problem in the line spacing...

Looking at this if difference =9.96mm ofver 33 lines then extra spacing =0.31125mm.

Which using HIENGLISH = 0.01225' = where 1 logical unit = 0.001' then we need to add 12.25 logical units.

I will add this between the characters and give it a try.

Quote:

---

Originally Posted by sma

Looking at this if difference =9.96mm ofver 33 lines then extra spacing =0.31125mm.

Which using HIENGLISH = 0.01225' = where 1 logical unit = 0.001' then we need to add 12.25 logical units.

I will add this between the characters and give it a try.

---

if that doesn't work you can email me printing code and I'll take a look..

How are you calculating the next line Y spacing ?

Yes, I am using GetTextExtent to obtain the line height, just looking at Word to see if there is a default line spacing which is added to each line of text. On the paragraph options there is an ability to include additional line spacing so I guess it may be defaulting to this whenthe RTF is opened and printed.

This still leaves me with the issue of providing an accurate screen representation. With the fix for the printing the screen rendering of the text still exceeds the screen. Might need to scale the screen representation to suit.

In your code here...you are adding .5 could this be why it is printing long ?

Code:

---

float PixelsInch = (((float)VertRes / (float)Height) * 25.4) + 0.5;

---

The code you referenced was an attempt to reduce the rounding errors during the calculation of a font. The 0.5 was added to ensure the number of pixels was always round up which is also performed by the MulDiv function. This method was extracted from a Windows Graphics Programming reference book I have.

After changing the code to use MM_HIGHENGLISH I nolonger use this function to calculate the required sizes.

I've changed the printed font back to 8pt from the 10 I was doing all the measurements on and now the line spacing is too much however I think it is a proportion of the size of the font. TextExtent.cy @ 10pt = 134 so I think I only need to multiply this by a factor of 0.1 to find the additional line spacing required.

As for the sceen representation I can scale this to suit and manipulate the overall page size.

There has to be some logical reason in the code for the size difference as you shouldn't have to multiply the cy by a .1 to get correct/matching line spacing...

Looking a bit further:

Word has a minimum line spacing for paragraphs and this has been identified a 6pt on the systems here.

I can't tell you if this includes the external leading element of the font or not however when you try to set this value to 0 in word it stipulates that this value can not be less than 0.7pt.

Anyway, I think we have found the source of the problem and as the font size varies this additional line spacing also varies so I have tailored the height value to a factor of 1.08.



Once again thank you for your assistance.

No problem...hope it helped in some way...

The issue is with the spacing Word adds to lines so this is a simple fix to add additional space between the lines of text.

The Print to Screen issue has been isolated to the rendering of the fonts and the respective resolutions of the devices.

Word and other word processes must use some intergral scaling functions to ensure that the fonts are scaled to ensure the text and page relationship is consistent to prevent overun of the respective page edges.

Overall a very interesting exercise.