Unit CastleWinFontConvert

DescriptionUsesClasses, Interfaces, Objects and RecordsFunctions and ProceduresTypesConstantsVariables

Description

Convert fonts available on Windows to TBitmapFont and TOutlineFont.

This unit heavily depends on GetGlpyhOutline WinAPI function. This function is our "core" of converting Windows fonts to TBitmapFont or TOutlineFont. Unfortunately, this makes this unit Windows-only forever. In the future I plan to write some similiar unit, but portable. Probably using FreeType2 library.

Uses

Overview

Functions and Procedures

function Font2BitmapChar_HDc(dc: HDc; c: char): PBitmapChar;
function Font2OutlineChar_HDc(dc: HDc; c: char): POutlineChar;
function Font2BitmapFont_HDc(dc: HDc): TBitmapFont;
function Font2OutlineFont_HDc(dc: HDc): TOutlineFont;
function Font2BitmapChar(WinFont: HFont; c: char): PBitmapChar;
function Font2OutlineChar(WinFont: HFont; c: char): POutlineChar;
function Font2BitmapFont(WinFont: HFont): TBitmapFont;
function Font2OutlineFont(WinFont: HFont): TOutlineFont;
procedure FreeAndNilFont(var Font: TBitmapFont); overload;
procedure FreeAndNilFont(var Font: TOutlineFont); overload;

Description

Functions and Procedures

function Font2BitmapChar_HDc(dc: HDc; c: char): PBitmapChar;

Both functions grab character c from Windows font currently selected on device context dc. Remeber to free resulting pointer by FreeMem.

"Underline" and "strikeout" : I observed that it does not matter whether font is underline or strikeout (e.g. what values for fdwUnderline/StrikeOut you gave when calling CreateFont). Fonts converted by this function are always NOT underlined and not strikeout. On the other hand, "bold" (actually "weight") and "italic" matter, i.e. fonts created by this functions reflect the weight and italic state of the font. This is true both for Font2BitmapChar and Font2OutlineChar. This is an effect of how Windows.GetGlyphOutline works. However I didn't find any place documenting these details about GetGlyphOutline. This is not a result of the fact that TTF fonts are usually distributed with separate bold, italic, and bold+italic versions, because I checked this with fonts that are distributed without bold, italic, bold+italic versions (i.e. bold, italic, bold+italic versions must be automatically synthesized by Windows) and for such fonts it works the same : bold, italic, b+i versions can be constructed by Font2XxxChar versions below, and underline and strikeout properties of Windows font are ignored.

function Font2OutlineChar_HDc(dc: HDc; c: char): POutlineChar;
 
function Font2BitmapFont_HDc(dc: HDc): TBitmapFont;

Grab currently selected Windows font on device context dc. Remeber to free resulting font later by FreeAndNilFont.

function Font2OutlineFont_HDc(dc: HDc): TOutlineFont;
 
function Font2BitmapChar(WinFont: HFont; c: char): PBitmapChar;

Usually much more comfortable versions of Font2XxxFont_HDc and Font2XxxChar_HDc. They take HFont, not HDc. This way they avoid some strangeness of GetGlyphOutline function (that requires as an argument HDc with selected font, not HFont)

function Font2OutlineChar(WinFont: HFont; c: char): POutlineChar;
 
function Font2BitmapFont(WinFont: HFont): TBitmapFont;
 
function Font2OutlineFont(WinFont: HFont): TOutlineFont;
 
procedure FreeAndNilFont(var Font: TBitmapFont); overload;

Free and nil Font instance, freeing also all characters by FreeMem. Use this only on fonts with characters created by GetMem.

procedure FreeAndNilFont(var Font: TOutlineFont); overload;
 

Generated by PasDoc 0.12.1 on 2013-02-04 20:26:53