RE: [XaraXtreme-dev] Current/default font

[Martin Wuerthner <lists@xxxxxxxxxxxxxxx>]

In message <5056CBC646CB4047BB26120F4377DB71DC843E@xxxxxxxxxxxxxxxxxxx 
>
          "Phil Martin" <Phil@xxxxxxxx> wrote:

> As Gerry pointed out, a newly applied "Times New Roman" fontface
> attribute does not optimise out because it has a valid font handle but
> the default font face attribute doesn't have a valid font handle.
> 
> The default attribute is created in txtattr.cpp,
> TxtFontTypefaceAttribute::Init(), with a default value of 0, whereas
> attributes applied from the font dropdown are assigned handle values
> using this command,
>         TypeFaceAttrib->Value.HTypeface =
> FONTMANAGER->GetFontHandle(&InfoData.FontName, InfoData.FontType);
> in TextInfoBarOp::OnFieldChange. The first handle handed out is 1, for
> Arial.

Yes, for the first "current font" that is set, to be precise, which 
currently is Arial.

> There are no comments saying that the default 0 handle is used
> deliberately in the knowledge that GetFontHandle will never return 0 so
> it looks like a bug to me BUT it could be a very useful one...

No, this is by design, and 0 *is* a valid font handle, it is the 
handle of the default font. The font handles of fonts in the font 
cache start with 1. This is ensured because the first value handed out 
is FIRSTFONTHANDLE (which is the initial value of 
FontManager::UniqueHandle and defined to be 1).

The default font does not live in the font cache. 
FontManager::GetCachedFont returns a font for a handle. It accepts 0 
(in which case it returns the default font) or a higher number (in 
which case it returns the font from the cache).

What broke the whole idea is the fact that the font cache search 
routine FindCachedFont does not do the same thing - it only compares 
against the fonts actually present in the cache, not against the 
out-of-cache default font first.

Martin