I am now converting a project's render engine from GDI to D2D. The GDI use "CreateFontIndirect" to assign font size "-13", font family "Segeo UI". The D2D use "CreateTextFormat" to assign font size "13", font family "Segeo UI". The effect is shown as follow picture:
In GDI case, the system didn't find chinese character in "Segeo UI", it will find in regedit "SystemLink" to locate the chinese font, on my machine is "YaHei". But In D2D case, the system didn't find "YaHei", Which chinese font it will choose to draw, How does it work?
It works according to DirectWrite layout logic. See IDWriteTextLayout2::SetFontFallback(), you'll be able to provide your own fallback implementation, if default configuration is not satisfactory.
Basically, layout object will call your custom fallback methods to map characters to fonts, you can then detect which characters you want to map to which font, potentially reusing system fallback implementation for cases you don't care about.
Related
There are proportional fonts (i.e. not monospaced) that nevertheless provide monospaced numbers. E.g. see this Excel screenshot using Arial:
Note how the numbers are nicely aligned. How can I find out programmatically (probably WinAPI) if a font supports this feature?
You won't find an API for that because there isn't any specific metadata value within the font file to indicate "the glyphs for digits in this font have fixed width". Some fonts may support both proportional and fixed-width ("lining") digits, in which case the font is likely to support the 'lnum' OpenType Layout feature. You should pick a font that supports this feature and then explicitly activate that feature when drawing the text.
FreeType has font metrics for the underline position, but I can't seem to find any metrics for the strikethrough position. How do text engines usually compute this value? Should I just put it at 1/3*ascent or whatever looks good? I suppose that for Latin at least this should be 1/2*height of "m" but I'm looking for a more general solution.
This information is not provided for all the various font formats supported by Freetype; so it is not exposed on the "main" interface.
In the (common but not universal) case of TrueType or OpenType fonts it can be retrieved in the TT_OS2 table, fields yStrikeoutSize and yStrikeoutPosition; you should be prepared for the table to be lacking, or yStrikeoutSize to be null or negative thus unusable.
I do not remember of an equivalent for plain Postscript fonts (.pfb/.pfa, even in .afm.)
The various bitmap formats might have the information available; an example is strike_out in Windows FNT; notice this is the position, while the size defaults to be the same as underlining. Basically every format is alone here.
I wrote a script which parses information from PDF files and outputs it to HTML. It's written in Python, using pdfminer.
On some text segments, the font style can have semantic significance. For instance: bold, italic and color should trigger different behavior. Pdfminer provides scripts with the font name, but not the color, and it has a number of other issues; so I'm working on a Swift version of that program, using Apple's PDFKit, to extract the same features.
I now find that I have the opposite problem. While PDFKit makes it easy to retrieve color, retrieving the original font name seems to be non-obvious. PDFSelection objects have an attributedString property, but for fonts that are not installed on my computer, the NSFont object is Helvetica. Of course, the fonts in question are fairly expensive, and acquiring a copy just for this purpose would be poor form.
Short of dropping to CGPDFContentStream (which is way too big of a hammer for what I want to get), is there a way of getting the original font name? I know in advance what the fonts are going to be, can I use that to my advantage?
PDFKit seems to use the standard font lookup system and then falls back on some default, so this can be resolved by spoofing the font to ensure that PDFKit doesn't need to fall back. Inspecting the document, I was able to identify that it uses the following fonts (referenced with their PostScript name):
"NeoSansIntel"
"NeoSansIntelMedium"
"NeoSansIntel,Italic"
I used a free font creation utility to create dummy fonts with these PostScript names, and I added them to my app bundle. I then used CTFontManagerRegisterFontsForURLs to load these fonts (in the .process scope), and now PDFKit uses these fonts for attributed strings that need them.
Of course, the fonts are bogus and this is useless for rendering. However, it works perfectly for the purpose of identifying text that uses these font.
The first parameter to the EnumFontFamiliesEx function, according to the MSDN documentation, is described as:
hdc [in]
A handle to the device context from which to enumerate the fonts.
What exactly does it mean?
What does device context mean?
Why should a device context be related to fonts?
Question (3) is a legitimately difficult thing to find an explanation for, but the reason is simple enough:
Some devices provide their own font support. For example, a PostScript printer will allow you to use PostScript fonts. But those same fonts won't be usable when rendering on-screen, or to another printer without PostScript support. Another example would be that a plotter (which is a motorized pen) requires vector fonts with a fixed stroke thickness, so raster fonts can't be used with such a device.
If you're interested in device-specific font support, you'll want to know about the GetDeviceCaps function.
The windows API uses the concept of handles extensively. A handle is an integer value that you can use as a token to access an API resource. You can think of it as a kind of "this" pointer, although it is definitely not a pointer.
A device context is an object within the windows API that represents a something that you can draw on or display graphics on. It might be a printer, a bitmap, or a screen, or some other context in which creating graphics makes sense. In Windows, fonts must be selected into device contexts before they can be used. In order to find out what fonts are currently available in any given device context, you can enumerate them. That's where EnumFontFamiliesEx comes in.
Microsoft has other articles on device context,
https://learn.microsoft.com/en-us/windows/win32/gdi/about-device-contexts
An application must inform GDI to load a particular device driver and,
once the driver is loaded, to prepare the device for drawing
operations (such as selecting a line color and width, a brush pattern
and color, a font typeface, a clipping region, and so on). These tasks
are accomplished by creating and maintaining a device context (DC). A
DC is a structure that defines a set of graphic objects and their
associated attributes, and the graphic modes that affect output. The
graphic objects include a pen for line drawing, a brush for painting
and filling, a bitmap for copying or scrolling parts of the screen, a
palette for defining the set of available colors, a region for
clipping and other operations, and a path for painting and drawing
operations. Unlike most of the structures, an application never has
direct access to the DC; instead, it operates on the structure
indirectly by calling various functions.
Obviously font is a kind of drawing.
Suppose you have a string with text in two or more scripts. When you use a GDI function like TextOut, (modern versions of) Windows will do "font-linking". That is, GDI will draw what it can with your selected font and draw the rest in an appropriate font that it chooses automagically. For example, if part of your text is in English (using the Roman alphabet), and part of it is Chinese (using CJK characters), and you have Arial selected, the English portion will be drawn in Arial, and the Chinese portion will be drawn in another font that has the CJK glyphs.
My question is, is there a way to determine which fonts TextOut will choose (or did choose) for the font linking?
I have to draw some text with the low-level Uniscribe API, which doesn't do automatic font-linking. I've implemented my own font-linking, but sometimes my algorithm chooses a different font than TextOut does for the same text. I'm trying to understand the Windows algorithm better, but I'm not real good at identifying fonts on sight (especially in unfamiliar scripts).
The font is selected by a registry entry. It is well described in this article. Quoting the relevant part:
If font linking is enabled on your
device, you can examine the registry
by enumerating the subkeys of the
registry key at
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\CurrentVersion\FontLink\SystemLink
to determine the mappings of linked
fonts to base fonts. You can add links
by using Regedit to create additional
subkeys.