GetTextExtentPoint32() 中的设备句柄

Question

I want to use GetTextExtentPoint32 to compute the size of the string in pixels. GetTextExtentPoint32 has the follwoing syntax:

BOOL GetTextExtentPoint32(
  _In_  HDC     hdc,
  _In_  LPCTSTR lpString,
  _In_  int     c,
  _Out_ LPSIZE  lpSize
);

where hdc [in] is the handle to the device context.

QUESTIONS:

I am using the following code to load fonts in libharu

    //-----UTF8 Encoding
    HPDF_UseUTFEncodings(pdf);
    const char *fontname = HPDF_LoadTTFontFromFile(pdf, "FreeSans.ttf", HPDF_TRUE);
    HPDF_Font font = HPDF_GetFont(pdf, fontname, "UTF-8");

How to I pass/compute the device handle to GetTextExtentPoint32() ?

UPDATE: I am using Win-7 on a monitor of resolution (1920x1080). My aim is to generate a PDF report using Libharu libraries. I want to compute the length of a string in pixels and for that purpose, I want to use GetTextExtentPoint32()

Answer 1

So to get the width of a string of text in your PDF with libharu, use HPDF_Font_TextWidth() . This returns a HPDF_TextWidth structure; use its width field. The width will be measured in either 1/1000th of an em or 1000 ems , I'm not sure which (using whatever sense of "em" TrueType uses for the em square), which I'm assuming PDF uses natively for measurements. You'd have to check the rest of HPDF's documentation.

I'm not sure if this takes kerning into consideration or not.

Confirmation: the source of HPDF's general font handling, the source of HDPF's TrueType font handling, Apple's TrueType font reference. The exact calculation is

width of one glyph = advance_width(units) * 1000 / units_per_em

Answer 2

Windows GDI works with pixels. Haru PDF works with points (72 points/inch). There is no direct equivalent to GetTextExtentPoint32() in Haru PDF.

If you want to duplicate your GDI results in PDF, you will need to:

[1] Call GetTextExtentPoint32() to get the text size in GDI pixels.

[2] Divide the width in pixels by the Device Context resolution (pixels/inch), then multiply by 72 to get points. Call GetDeviceCaps(hdc, LOGPIXELSX) to get the pixels/inch. Call this result fTargetWidth . This is how wide you expect your string to be.

[3] When writing the PDF, call HPDF_Font_TextWidth() to get the string's width as seen from Haru. If the PDF width is greater than GDI's "points" width, tighten the spacing a tad, subtracting the excess over the range of characters:

// how long is this string?
HPDF_TextWidth htw = HPDF_Font_TextWidth(pdfFont, (HPDF_BYTE *)string, len);
// convert to actual points
fWidth = (htw.width * fontPoints) / 1000.f;
// does it overflow?
if(fWidth > fTargetWidth && htw.numchars > 0)
{   excess = fWidth - fTargetWidth;    // by how much
    charSpace = -excess / htw.numchars;  // note negative
    // tighten up the spacing
    HPDF_Page_SetCharSpace(page, charSpace);
}

HPDF_Page_TextOut (page, x, y, string);
HPDF_Page_SetCharSpace(page, 0.f);      // reset

For some reason, HPDF_Page_SetWordSpace() doesn't seem to have any effect.

How come the same font, at the same size, has such a difference in width? So much for WYSIWYG :o)