WPF Font: Why are some characters missing?

问题:

I'm writing a WPF app and the font that I am using only has problems running in WPF - it works fine using it in anything else (notepad, wordpad, etc.). The problem with WPF is that it falls back to another font sometimes. By "sometimes" I mean that only characters [a-zA-Z] appear to render correctly - everything else appears to be rendered as the default TextBox font.

Does anyone know if WPF has some sort of limitation for the fonts that it supports? It almost seems to be bug in WPF - the font works fine everywhere else.

The font that I'm trying to use is the "Scramble" TTF font (http://famousfonts.smackbomb.com/fonts/scrabble.php).

Numbers and spaces should be seen as a blank Scrabble/Scramble tile, but instead the number itself appears in the textbox I'm using.

The code I'm using:

<TextBox Text="Testing testing testing" FontFamily="Fonts/#Scramble" />

Has anyone else experienced something similar?

Any suggestions would rock!

Thanks!

回答1:

From MSDN:

Font Fallback

Font fallback refers to the automatic substitution of a font other than the font that is selected by the client application. There are two primary reasons why font fallback is invoked:

• The font that is specified by the client application does not exist on the system.
• The font that is specified by the client application does not contain the glyphs that are required to render text.

In WPF, the font fallback mechanism uses the default fallback font family, "Global User Interface", as the substitute font. This font is defined as a composite font, whose file name is "GlobalUserInterface.CompositeFont". For more information about composite fonts, see the Composite Fonts section in this topic.

The WPF font fallback mechanism replaces previous Win32 font substitution technologies.

My guess would be that the font doesn't support Unicode - the font itself was created in 1996, and since it's intended to emulate Scrabble pieces, I'm not sure that the font author even considered localization.

EDIT According to the font documentation, the font supports the letters, and any number is supposed to render a blank tile. Spaces don't render a tile.

回答2:

The short answer is that Scramble doesn't use a blank scrabble piece for an em space in WPF or anything else. You'll need another font or something to edit the em/en space glyphs (something like Font Creator).

I got another font (x-grid) which i KNOW has a special glyph for spaces and used them as in the code below.

<Window x:Class="WpfApplication1.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Window1" Height="300" Width="500">
<Grid>
    <Grid.RowDefinitions>
        <RowDefinition/>
        <RowDefinition/>
    </Grid.RowDefinitions>
    <TextBlock Grid.Row="0" FontFamily="Scramble" TextAlignment="Center" HorizontalAlignment="Center" FontSize="24" Text="Example Text M M M"/>
    <TextBlock Grid.Row="1" FontFamily="x-grid"  TextAlignment="Center" HorizontalAlignment="Center" FontSize="24" Text="Example Text M M M"/>
</Grid>

The resulting window looked like this.

Nothing to do with font-fallback I'm afraid. Sorry, but I hope that helps.

**UPDATE:**Sorry, just noticed you mentioned numbers too. A quick test in Paint.Net shows that numbers don't appear in tiles either.

回答3:

Instead of setting FontFaily="Fonts/#Scrambe", just use the font name without "Fonts/#":

<TextBox Text="Testing testing testing" FontFamily="Scramble" />

This worked for me. I downloaded and installed the font you referred to, and it shows the font perfectly, both in design view in VS2008, and in runtime when I run the app.

回答4:

Typography in general and fonts in particular are a fairly complex topic I'm not really into. That said here's what I've figured from Typography in Windows Presentation Foundation and related MSDN documentation:

• Text is rendered by means of a text rendering pipeline (see link above for a diagram).
• WPF facilitates OpenType as an extension of the TrueType font format.
  • The Typography object exposes many of the advanced features of OpenType fonts.
• An important low level text rendering concept is the Glyphs element, see MSDN introduction.

If you look at the mentioned text rendering pipeline diagram you'll notice that while glyphs are the building blocks they may be acted upon in various ways (filtered/transformed/...) before finally getting displayed on a particular medium, e.g. a screen or a printer; one example would be applying ClearType for LCD screens. However, as usually with pipelining concepts, those transformations are more ore less optional in general.

Now, depending on your application requirements, this might already yield a solution. If you don't really need a TextBox you might as well just use Glyphs in itself like so:

<Page xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
      xmlns:sys="clr-namespace:System;assembly=mscorlib" 
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" >
  <Grid>
    <TextBox Text="TextBox: 1234567890" FontFamily="Scramble" FontSize="12" />
    <Glyphs UnicodeString="Glyphs: 1234567890" FontUri="C:\WINDOWS\Fonts\Scramble.TTF" 
            FontRenderingEmSize="12" Fill="Black" OriginX="5" OriginY="32"/>
  </Grid>
</Page>

The Glyphs element is rendering empty tiles for numbers as desired while the TextBox element does not. Please note that due to Glyphs being a low level element, several restrictions apply, especially FontUri/Fill/FontRenderingEmSize are all required, i.e. there are no defaults like for the related TextBox properties.

With all this in mind back to your original question: I wouldn't think of the problem at hand as a WPF limitation (or a bug even), rather of an effect regarding the text rendering requirements and defaults applied in the context of WPF UI layout. E.g. the composite (i.e. non low level) TextBox control is applying text formatting and typography settings to its content (glyphs), facilitating the various character mapping tables embedded in fonts (there are potentially lots of them...); special/simplistic fonts like Scramble might just not provide enough or correct information here, consequently the WPF rendering engine might be forced to apply font fallback as outlined by GalacticCowboy already.

If that's indeed the case, it might be possible to override the WPF default rendering algorithm somehow (see class TextFormatter, the WPF text engine), but likely one would need to dig pretty deep into the framework to figure out what's going on within a TextBox. It's probably much easier to 'debug' the eventually missing or incorrect character mappings within the Scramble font. This would be an entirely different endeavor though...

回答5:

I'm not into WPF, but i know that Microsoft handles in general latin an non-latin characters differently. I have seen that you can define a composite font, and map a specific unicode range to a font. You can try to force your font for the whole unicode range. link text