by Michael S. Kaplan, published on 2007/12/16 10:16 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2007/12/16/6780417.aspx
Another recent mail coming to me via the Contact link:
Suppose i create my LOGFONT structure with a fontname(say 'Arial') with style Italic/Bold set.In this case,i do have "Arial Bold Italic(True Type)" in my window's font's folder so i should effectively be using this font rather than arial font with bold/italic behaviour synthesized to render my text as it would have been in most cases(say MS Mincho,no corresponding MS Mincho Italic font) when there is no corresponding font present with style.
As an input i have glyphs(ExtTextOut call in emf file),my logfont structure(which I get from CreateFontIndirect call in emf) and I want to know whether I should use "Arial Bold Italic" OR "Arial" font with bold/italic behaviour synthesis. I would like to do synthesis only when the corresponding italic/bold font is not present.Is there any way to correctly know which font to use exactly?
Further,i was also having some issues using some glyphs like \uFE97\uFE99,when i pass Arial in my LOGFONT structure,it fails and returns Arial Unicode MS as the linked font though the glyph is present in Arial.GlyphIndices corresponding to both the fonts are different hence leading to change in glyphs.
Thanks in advance.
You actually don't have a whole lot choice here, actually. Any GDI or GDI+ or WPF call to create a font is a request based on the attributes you send.
So while one could theorize about the differences between:
LOGFONT.lfFaceName = "Arial Bold Italic"
and
LOGFONT.lfFaceName = "Arial"
LOGFONT.Weight = FW_BOLD
LOGFONT.fItalic == TRUE
when the font exists are really nil, other than poor and variable localizability story on the former, which makes the latter probably be better choice.
When the font does not exist, it is definitely better to use the latter method because the name doesn't exist.
But either way, synthesis always happens -- as the font mapper to map all of these attributes to a font, from size to precision and so on. Font objects are always "synthesized" in that sense, and the system always prefer to not "fake" attributes when there is a file containing the actual request. All of that will happen automatically if you allow it....
For that last point about
ﺗ
(U+fe97, aka ARABIC LETTER TEH INITIAL FORM) and
ﺙ
(U+fe99, aka ARABIC LETTER THEH ISOLATED FORM), the glyphs won't ever come from Arial Unicode MS just because Arial was the font you started with -- because Arial Unicode MS doesn't ship with the Windows, and Uniscribe does not use it for font fallback (and this is font fallback through Uniscribe, not font linking through GDI).
And that kind of font switching behavior will tend to happen by default when the technology for rendering that you use (Uniscribe, GDI+, WPF) has such a capability, unless you go to extreme lengths to disallow it
A good example of the disallowing is something I talked about in Don't change the font, dammit!.
Though of course by using Arabic script from the compatibility zone the lines of how much extra work is done in the way of complex scripts is not as well documented, there is still some work that happens irregardless given issues like directionality.
The question then started talking about Arial.GlyphIndices which made this sound like it might be more of a WPF-like question but not exactly, or some other technology, that was not specified. Which doesn't change the general answer but could in theory change the specifics.
Can you imagine a situation where you weren't specifically working with the compatibility zone but you ended up with those code points anyway?
Well, when you think about the technologies that deal in glyph indices such as PDF (and the person asking as from Adobe so its safe bet that we may be talking about something PDF-esque), the very real question about minimizing font shifts is an interesting one to say the least.
So moving concentrically outward to what might have been one of the real questions all along, if one wants to know whether a font natively supports a particular character, this is something I covered a bit in WYSIWYG font dropdowns and Working beyond the BMP is going off script (according to GDI).
There is one missing piece in that last part and those two posts, and it is to do with complex scripts. Anyone care to make a guess as to what that might be? It might make a nice post here at some point!
This post brought to you by ﺙ (U+fe99, aka ARABIC LETTER THEH ISOLATED FORM)question
referenced by