Freigeben über

Benutzerdefinierte Schriftartensätze

  • Artikel

In diesem Thema werden verschiedene Möglichkeiten beschrieben, wie Sie benutzerdefinierte Schriftarten in Ihrer App verwenden können.

Einleitung

In den meisten Zeiten verwenden Apps die Schriftarten, die lokal auf dem System installiert sind. DirectWrite bietet Zugriff auf diese Schriftarten mithilfe der IDWriteFactory3::GetSystemFontSet- oder IDWriteFactory::GetSystemFontCollection Methoden. In einigen Fällen möchten Apps möglicherweise auch Schriftarten verwenden, die im Rahmen von Windows 10 enthalten sind, aber derzeit nicht auf dem aktuellen System installiert sind. Auf solche Schriftarten kann über den Windows-Schriftartdienst mithilfe der GetSystemFontSet--Methode oder durch Aufrufen IDWriteFactory3::GetSystemFontCollection mit includeDownloadableFonts auf TRUE festgelegt werden. 

In einigen Anwendungsszenarien müssen Apps jedoch Schriftarten verwenden, die nicht im System installiert sind und nicht vom Windows-Schriftartdienst bereitgestellt werden. Im Folgenden sind Beispiele für solche Szenarien aufgeführt:

  • Schriftarten werden als Ressourcen in eine App-Binärdatei eingebettet.
  • Schriftartdateien werden in einem App-Paket gebündelt und auf dem Datenträger unter dem Installationsordner der App gespeichert.
  • Die App ist ein Tool für die Schriftartentwicklung, das benutzerspezifische Schriftartdateien laden muss. 
  • Schriftarten sind in Dokumentdateien eingebettet, die in der App angezeigt oder bearbeitet werden können. 
  • Die App verwendet Schriftarten, die von einem öffentlichen Webdienst abgerufen werden. 
  • Die App verwendet Schriftartdaten, die über ein privates Netzwerkprotokoll gestreamt werden. 

DirectWrite stellt APIs zum Arbeiten mit benutzerdefinierten Schriftarten in diesen und anderen ähnlichen Szenarien bereit. Die benutzerdefinierten Schriftartdaten können aus Dateien im lokalen Dateisystem stammen. von Remote-, cloudbasierten Quellen, auf die über HTTP zugegriffen wird; oder aus beliebigen Quellen, nachdem sie in einen Speicherpuffer geladen wurden. 

Anmerkung

Während DirectWrite APIs für die Arbeit mit benutzerdefinierten Schriftarten seit Windows 7 bereitgestellt hat, wurden neuere APIs in Windows 10 und erneut im Windows 10 Creators Update (Vorschau build 15021 oder höher) hinzugefügt, die die Implementierung mehrerer der erwähnten Szenarien vereinfachen. In diesem Thema geht es um APIs, die in Windows 10 verfügbar sind. Anwendungen, die in früheren Windows-Versionen funktionieren müssen, finden Sie unter Benutzerdefinierte Schriftartsammlungen (Windows 7/8). 

 

Zusammenfassung der APIs

In diesem Thema geht es um funktionen, die von den folgenden APIs bereitgestellt werden:

 

Schlüsselkonzepte

Um die DirectWrite-APIs für die Arbeit mit benutzerdefinierten Schriftarten zu verstehen, kann es hilfreich sein, das konzeptionelle Modell zu verstehen, das diese APIs unterschreibt. Die wichtigsten Konzepte werden hier beschrieben. 

Wenn DirectWrite das tatsächliche Textlayout oder Rendering durchführt, muss auf tatsächliche Schriftartdaten zugegriffen werden. Ein Font Face-Objekt enthält tatsächliche Schriftartdaten, die im lokalen System vorhanden sein müssen. Für andere Vorgänge, z. B. die Überprüfung der Verfügbarkeit einer bestimmten Schriftart oder das Darstellen von Schriftartauswahlen für einen Benutzer, ist dies jedoch ein Verweis auf eine bestimmte Schriftart, nicht die tatsächlichen Schriftartdaten selbst. In DirectWrite enthält ein Font Face Reference-Objekt nur die Informationen, die zum Suchen und Instanziieren einer Schriftart erforderlich sind. Da der Schriftzeichenverweis keine tatsächlichen Daten enthält, kann DirectWrite mit Schriftart-Gesichtsbezügen umgehen, für die sich tatsächliche Daten an einem Remotenetzwerkstandort befinden und wann die tatsächlichen Daten lokal sind.

Bei einem Schriftsatz handelt es sich um einen Satz von Schriftzeichenbezügen, zusammen mit bestimmten grundlegenden Informationseigenschaften, die beim Verweisen auf die Schriftart oder beim Vergleichen mit anderen Schriftarten verwendet werden können, z. B. dem Familiennamen oder einem Wert mit der Schriftbreite. Die tatsächlichen Daten für die verschiedenen Schriftarten können lokal sein, oder es kann sich um eine Remote- oder eine Mischung sein.

Ein Schriftsatz kann verwendet werden, um ein entsprechendes Schriftartsammlungsobjekt abzurufen. Weitere Informationen finden Sie weiter unten unter Schriftartensätze und Schriftartsammlungen. 

Die IDWriteFontSet-Schnittstelle stellt Methoden bereit, die das Abfragen von Eigenschaftswerten wie Familiennamen oder Schriftbreite oder Schriftartenbeschriftungen ermöglichen, die bestimmten Eigenschaftswerten entsprechen. Nach dem Filtern nach einer bestimmten Auswahl kann eine Instanz der IDWriteFontFaceReference Schnittstelle abgerufen werden, mit Methoden zum Herunterladen (wenn die tatsächlichen Schriftartdaten derzeit remote sind) zum Abrufen der entsprechenden IDWriteFontFace3-Objekt, das zum Layout und Rendern verwendet werden kann. 

Die IDWriteFontFile-Schnittstelle unterlies den einzelnen Schriftarten- oder Schriftarten-Gesichtsbezügen. Dies stellt den Speicherort einer Schriftartdatei dar und verfügt über zwei Komponenten: ein Dateiladeprogramm für Schriftarten und einen Schriftartdateischlüssel. Das Laden der Schriftartdatei (IDWriteFontFileLoader) wird verwendet, um eine Datei bei Bedarf zu öffnen und gibt einen Datenstrom mit den Daten zurück (IDWriteFontFileStream). Je nach Ladeprogramm befinden sich die Daten möglicherweise in einem lokalen Dateipfad, einer Remote-URL oder in einem Speicherpuffer. Der Schlüssel ist ein ladeerdefinierter Wert, der die Datei innerhalb des Ladeprogrammkontexts eindeutig identifiziert, sodass das Ladeprogramm die Daten suchen und einen Datenstrom dafür erstellen kann. 

Benutzerdefinierte Schriftarten können einfach zu einem benutzerdefinierten Schriftsatz hinzugefügt werden, der wiederum zum Filtern oder Organisieren von Schriftartinformationen für Zwecke wie das Erstellen einer Benutzeroberfläche für die Schriftartauswahl verwendet werden kann. Der Schriftartsatz kann auch verwendet werden, um eine Schriftartsammlung für die Verwendung in APIs höherer Ebene wie IDWriteTextFormat und IDWriteTextLayoutzu erstellen. Die IDWriteFontSetBuilder Schnittstelle kann verwendet werden, um einen benutzerdefinierten Schriftartsatz zu erstellen, der mehrere benutzerdefinierte Schriftarten enthält. Es kann auch verwendet werden, um einen benutzerdefinierten Schriftartsatz zu erstellen, der benutzerdefinierte Schriftarten und vom System bereitgestellte Schriftarten kombiniert. oder das Schriftarten mit verschiedenen Quellen für die tatsächlichen Daten kombiniert – lokaler Speicher, Remote-URLs und Arbeitsspeicher. 

Wie bereits erwähnt, kann ein Schriftzeichenverweis auf Schriftartdaten in einer Remotequelle verweisen, die Daten müssen jedoch lokal sein, um ein Schriftart-Face-Objekt abzurufen, das für das Layout und rendering verwendet werden kann. Das Herunterladen von Remotedaten wird von einer Downloadwarteschlange für Schriftarten behandelt. Apps können die IDWriteFontDownloadQueue Schnittstelle verwenden, um Remoteschriftarten herunterzuladen, um den Downloadvorgang zu initiieren, und einen IDWriteFontDownloadListener Objekt zu registrieren, um Maßnahmen zu ergreifen, wenn der Downloadvorgang abgeschlossen ist. 

Für die meisten hier beschriebenen Schnittstellen stellt DirectWrite Systemimplementierungen bereit. Die einzige Ausnahme ist die IDWriteFontDownloadListener Schnittstelle, die eine App implementiert, um appspezifische Aktionen auszuführen, wenn Remoteschriftarten lokal heruntergeladen wurden. Apps haben möglicherweise Grund, ihre eigenen benutzerdefinierten Implementierungen für bestimmte andere Schnittstellen bereitzustellen, obwohl dies nur in bestimmten, komplexeren Szenarien erforderlich wäre. Beispielsweise muss eine App eine benutzerdefinierte Implementierung des IDWriteFontFileLoader Schnittstelle bereitstellen, um Schriftartdateien im lokalen Speicher zu verarbeiten, die das WOFF2-Containerformat verwenden. Weitere Details finden Sie unten. 

Schriftarten und Schriftartdateiformate

Ein weiteres wichtiges Konzept, das hilfreich ist, ist die Beziehung zwischen einzelnen Schriftarten und Schriftartdateien, die sie enthalten. Die Idee einer OpenType-Schriftartdatei (.ttf oder .otf), die eine einzelne Schriftart enthält, ist vertraut. Das OpenType-Schriftartformat ermöglicht jedoch auch eine OpenType Font Collection (.ttc oder .otc), bei der es sich um eine einzelne Datei handelt, die mehrere Schriftarten enthält. OpenType-Sammlungsdateien werden häufig für große Schriftarten verwendet, die eng miteinander verknüpft sind und identische Werte für bestimmte Schriftartdaten aufweisen: Durch die Kombination der Schriftarten in einer einzelnen Datei können die allgemeinen Daten dedupliziert werden. Aus diesem Grund muss ein Schrift- oder Schriftzeichenbezug nicht nur auf eine Schriftartdatei (oder eine gleichwertige Datenquelle) verweisen, sondern auch einen Schriftartindex innerhalb dieser Datei angeben, für den allgemeinen Fall, in dem die Datei eine Sammlungsdatei sein kann. 

Bei Schriftarten, die im Web verwendet werden, werden Schriftartdaten häufig in bestimmte Containerformate, WOFF oder WOFF2 verpackt, die eine Komprimierung der Schriftartdaten und ein gewisses Maß an Schutz vor Piraterie und Verletzung von Schriftlizenzen bieten. Funktionell entspricht eine WOFF- oder WOFF2-Datei einer OpenType-Schriftart oder Schriftartsammlungsdatei, aber die Daten werden in einem anderen Format codiert, das entpackt werden muss, bevor sie verwendet werden kann. 

Bestimmte DirectWrite-APIs behandeln möglicherweise einzelne Schriftarten, während andere APIs Dateien verarbeiten können, die OpenType-Auflistungsdateien enthalten, die mehrere Gesichter enthalten. Ebenso behandeln bestimmte APIs nur unformatierte OpenType-Formatdaten, während andere APIs die gepackten, WOFF- und WOFF2-Containerformate verarbeiten können. Diese Details finden Sie in der nachstehenden Diskussion. 

Schriftartensätze und Schriftartsammlungen

Einige Anwendungen können zum Arbeiten mit Schriftarten mithilfe der IDWriteFontCollection Schnittstelle implementiert werden. Es gibt eine direkte Korrespondenz zwischen einer Schriftartsammlung und einem Schriftsatz. Jede kann dieselben Schriftarten enthalten, aber sie präsentieren sie mit einer anderen Organisation. Aus einer beliebigen Schriftartsammlung kann ein entsprechender Schriftsatz abgerufen und umgekehrt werden.

Wenn Sie mit einer Reihe von benutzerdefinierten Schriftarten arbeiten, ist es am einfachsten, eine Schriftartsatz-Generator-Schnittstelle zum Erstellen eines benutzerdefinierten Schriftsatzes zu verwenden und dann eine Schriftartsammlung abzurufen, nachdem der Schriftartensatz erstellt wurde. Der Prozess zum Erstellen eines benutzerdefinierten Schriftsatzes wird unten ausführlich beschrieben. Um eine IDWriteFontCollection1 Schnittstelle aus einem Schriftartensatz abzurufen, wird die IDWriteFactory3::CreateFontCollectionFromFontSet-Methode verwendet.

Wenn die App über ein Auflistungsobjekt verfügt und einen entsprechenden Schriftsatz abrufen muss, kann dies mithilfe der IDWriteFontCollection1::GetFontSet-Methode erfolgen. 

Häufige Szenarien

In diesem Abschnitt werden einige der am häufigsten verwendeten Szenarien mit benutzerdefinierten Schriftartensätzen beschrieben:

  • Erstellen eines benutzerdefinierten Schriftartensatzes mithilfe beliebiger Schriftarten bei Pfaden im lokalen Dateisystem.
  • Erstellen eines benutzerdefinierten Schriftartensatzes mithilfe bekannter Schriftarten (möglicherweise gebündelt mit der App), die im lokalen Dateisystem gespeichert sind.
  • Erstellen eines benutzerdefinierten Schriftartsatzes mithilfe bekannter Remoteschriftarten im Web.
  • Erstellen eines benutzerdefinierten Schriftsatzes mithilfe von in den Arbeitsspeicher geladenen Schriftartdaten.

Vollständige Implementierungen für diese Szenarien werden im Beispiel für benutzerdefinierte DirectWrite-Schriftartensätzebereitgestellt. In diesem Beispiel wird auch ein komplexeres Szenario für die Behandlung von Schriftartdaten veranschaulicht, die in WOFF- oder WOFF2-Containerformaten verpackt sind, die unten erläutert werden. 

Erstellen eines Schriftartsatzes mit beliebigen Schriftarten im lokalen Dateisystem

Beim Umgang mit einem beliebigen Satz von Schriftartdateien im lokalen Speicher ist die IDWriteFontSetBuilder1::AddFontFile Methode praktisch, da es in einem einzigen Aufruf alle Schriftarten in einer OpenType Font Collection-Datei sowie alle Instanzen für eine OpenType-Variable-Schriftart verarbeiten kann. Dies ist im Windows 10 Creators Update (Vorschaubuild 15021 oder höher) verfügbar und wird immer dann empfohlen, wenn verfügbar. 

Um diese Methode zu verwenden, verwenden Sie den folgenden Prozess.

1. Erstellen Sie zunächst die IDWriteFactory5 Schnittstelle: 
IDWriteFactory5* pDWriteFactory; 
HRESULT hr = DWriteCreateFactory( 
  DWRITE_FACTORY_TYPE_SHARED, 
  __uuidof(IDWriteFactory5), 
  reinterpret_cast<IUnknown**>(&pDWriteFactory) 
); 

 
2. Verwenden Sie die Factory, um die IDWriteFontSetBuilder1 Schnittstelle abzurufen: 

IDWriteFontSetBuilder1* pFontSetBuilder; 
if (SUCCEEDED(hr)) 
{ 
  hr = pDWriteFactory->CreateFontSetBuilder(&pFontSetBuilder); 
}  
  1. Erstellen Sie für jede Schriftartdatei im lokalen Dateisystem eine IDWriteFontFile-, die darauf verweist: 
IDWriteFontFile* pFontFile; 
if (SUCCEEDED(hr)) 
{ 
  hr = pDWriteFactory->CreateFontFileReference(pFilePath, /* lastWriteTime*/ nullptr, &pFontFile); 
} 

 
4. Fügen Sie das IDWriteFontFile-Objekt mithilfe der AddFontFile--Methode zum Schriftartsatz-Generator hinzu: 

hr = pFontSetBuilder->AddFontFile(pFontFile); 

Wenn der im Aufruf von CreateFontFileReference angegebene Dateipfad auf eine andere Datei als eine unterstützte OpenType-Datei verweist, gibt der Aufruf von AddFontFile- einen Fehler zurück, DWRITE_E_FILEFORMAT.

  1. Nachdem alle Dateien dem Schriftartensatz-Generator hinzugefügt wurden, kann der benutzerdefinierte Schriftartsatz erstellt werden: 
IDWriteFontSet* pFontSet; 
hr = pFontSetBuilder->CreateFontSet(&pFontSet); 

 

Wenn die App unter Windows 10-Versionen vor dem Windows 10 Creators Update ausgeführt werden muss, ist die AddFontFile-Methode nicht verfügbar. Verfügbarkeit kann durch Erstellen einer IDWriteFactory3--Schnittstelle erkannt werden und anschließend mithilfe von QueryInterface versucht werden, eine IDWriteFactory5--Schnittstelle abzurufen: Wenn dies erfolgreich ist, ist auch die IDWriteFontSetBuilder1 Schnittstelle und AddFontFile Methode verfügbar.

Wenn die AddFontFile-Methode nicht verfügbar ist, muss die IDWriteFontSetBuilder::AddFontFaceReference Methode verwendet werden, um einzelne Schriftartenzeichen hinzuzufügen. Um OpenType Font Collection-Dateien zuzulassen, die mehrere Gesichter enthalten, kann die IDWriteFontFile::Analyze-Methode verwendet werden, um die Anzahl der in der Datei enthaltenen Gesichter zu bestimmen. Der Prozess lautet wie folgt.

1. Erstellen Sie zunächst die IDWriteFactory3 Schnittstelle: 
IDWriteFactory3* pDWriteFactory; 
HRESULT hr = DWriteCreateFactory( 
DWRITE_FACTORY_TYPE_SHARED, 
  __uuidof(IDWriteFactory5), 
  reinterpret_cast<IUnknown**>(&pDWriteFactory) 
); 
  1. Verwenden Sie die Factory, um die IDWriteFontSetBuilder Schnittstelle abzurufen: 
IDWriteFontSetBuilder* pFontSetBuilder; 
if (SUCCEEDED(hr)) 
{ 
  hr = pDWriteFactory->CreateFontSetBuilder(&pFontSetBuilder); 
} 
  1. Erstellen Sie für jede Schriftartdatei wie oben eine IDWriteFontFile-: 
IDWriteFontFile* pFontFile; 
if (SUCCEEDED(hr)) 
{ 
  hr = pDWriteFactory->CreateFontFileReference(pFilePath, /* lastWriteTime*/ nullptr, &pFontFile); 
} 

Anstatt die Datei direkt zum Schriftartensatz-Generator hinzuzufügen, müssen wir die Anzahl der Gesichter bestimmen und einzelne IDWriteFontFaceReference Objekte erstellen. 
4. Verwenden Sie die methode Analyze, um die Anzahl der Gesichter in der Datei abzurufen. 

BOOL isSupported; 
DWRITE_FONT_FILE_TYPE fileType; 
UINT32 numberOfFonts; 
hr = pFontFile->Analyze(&isSupported, &fileType, /* face type */ nullptr, &numberOfFonts); 

Die Analyze-Methode legt auch Werte für die Parameter isSupported und fileType fest. Wenn die Datei kein unterstütztes Format ist, ist "isSupported" FALSCH, und die entsprechende Aktion, z. B. das Ignorieren der Datei, kann ausgeführt werden. 
5. Durchlaufen Sie die Anzahl der Schriftarten, die im Parameter numberOfFonts festgelegt sind. Erstellen Sie in der Schleife eine IDWriteFontFaceReference- für jedes Datei-/Indexpaar, und fügen Sie dies dem Schriftartensatz-Generator hinzu. 

for (uint32_t fontIndex = 0; fontIndex < numberOfFonts; fontIndex++) 
{ 
  IDWriteFontFaceReference* pFontFaceReference;
  hr = pDWriteFactory->CreateFontFaceReference(pFontFile, fontIndex, DWRITE_FONT_SIMULATIONS_NONE, &pFontFaceReference);

  if (SUCCEEDED(hr))
  {
    hr = pFontSetBuilder->AddFontFaceReference(pFontFaceReference);
  }
} 
  1. Nachdem alle Gesichter dem Schriftartensatz-Generator hinzugefügt wurden, erstellen Sie den benutzerdefinierten Schriftsatz, wie oben gezeigt.

Eine App kann so entworfen werden, dass sie die bevorzugte AddFontFile--Methode verwendet, wenn sie auf dem Windows 10 Creators Update ausgeführt wird, aber auf die verwendung der AddFontFaceReference--Methode zurückgreifen, wenn sie unter früheren Windows 10-Versionen ausgeführt wird. Testen Sie die Verfügbarkeit der IDWriteFactory5 Schnittstelle, wie oben beschrieben, und verzweigen Sie dann entsprechend. Dieser Ansatz wird im Beispiel für benutzerdefinierte DirectWrite-Schriftartensätzeveranschaulicht. 

Erstellen eines Schriftartsatzes mithilfe bekannter Schriftarten im lokalen Dateisystem

Wie bereits erwähnt, wird jeder Schriftzeichenbezug in einem Schriftsatz bestimmten Informationseigenschaften zugeordnet, z. B. Familienname und Schriftbreite. Wenn einem Schriftartensatz-Generator mithilfe der oben aufgeführten API-Aufrufe benutzerdefinierte Schriftarten hinzugefügt werden, werden diese Informationseigenschaften direkt aus den tatsächlichen Schriftartdaten abgerufen, die gelesen werden, wenn die Schriftart hinzugefügt wird. Wenn eine App jedoch in einigen Fällen eine andere Informationsquelle für eine Schriftart enthält, möchten Sie möglicherweise eigene benutzerdefinierte Werte für diese Eigenschaften bereitstellen. 

Angenommen, eine App bündelt einige Schriftarten, die zum Darstellen bestimmter Benutzeroberflächenelemente innerhalb der App verwendet werden, als Beispiel für die Verwendung dieser Vorgehensweise. Manchmal müssen die spezifischen Schriftarten, die die App für diese Elemente verwendet, z. B. mit einer neuen App-Version ändern. Wenn die App Verweise auf die spezifischen Schriftarten codiert hat, muss durch den Ersatz einer Schriftart durch eine andere jede dieser Verweise geändert werden. Wenn die App stattdessen benutzerdefinierte Eigenschaften verwendet, um funktionale Aliase basierend auf dem Typ des gerenderten Elements oder Texts zuzuweisen, ordnet jeder Alias einer bestimmten Schriftart an einer zentralen Stelle zu und verwendet dann die Aliase in allen Kontexten, in denen Schriftarten erstellt und bearbeitet werden, und das Ersetzen einer Schriftart durch eine andere erfordert nur das Ändern der stelle, an der der Alias einer bestimmten Schriftart zugeordnet ist. 

Benutzerdefinierte Werte für Informationseigenschaften können zugewiesen werden, wenn die IDWriteFontSetBuilder::AddFontFaceReference-Methode aufgerufen wird. Die Vorgehensweise hierfür lautet wie folgt; dies kann auf jeder beliebigen Windows 10-Version verwendet werden. 

Wie oben gezeigt, rufen Sie zunächst die IDWriteFactory3- und IDWriteFontSet--Schnittstellen ab. Erstellen Sie für jede benutzerdefinierte Schriftart, die hinzugefügt werden soll, eine IDWriteFontFaceReference, wie oben dargestellt. Bevor dies dem Schriftartensatz-Generator hinzugefügt wird (in Schritt 5, siehe oben), definiert die App jedoch die zu verwendenden benutzerdefinierten Eigenschaftswerte. 

Ein Satz benutzerdefinierter Eigenschaftswerte wird mithilfe eines Arrays von DWRITE_FONT_PROPERTY Strukturen definiert. Jede dieser Eigenschaften identifiziert eine bestimmte Eigenschaft aus der DWRITE_FONT_PROPERTY_ID Enumeration und den entsprechenden Eigenschaftswert, der verwendet werden soll.  

Beachten Sie, dass alle Eigenschaftswerte als Zeichenfolgen zugewiesen werden. Wenn diese später benutzern angezeigt werden können, können alternative Werte für eine bestimmte Eigenschaft für verschiedene Sprachen festgelegt werden, dies ist jedoch nicht erforderlich. Beachten Sie außerdem, dass, wenn benutzerdefinierte Eigenschaftswerte von der App festgelegt werden, nur die werte, die angegeben werden, innerhalb des Schriftsatzes verwendet werden. DirectWrite leitet keine Werte direkt von der Schriftart für Informationseigenschaften ab, die in einem Schriftsatz verwendet werden. 

Im folgenden Beispiel werden benutzerdefinierte Werte für drei Informationseigenschaften definiert: Familienname, vollständiger Name und Schriftbreite. 

DWRITE_FONT_PROPERTY props[] = 
{ 
  { DWRITE_FONT_PROPERTY_ID_FAMILY_NAME, L"My Icon Font", L"en-US" }, 
  { DWRITE_FONT_PROPERTY_ID_FULL_NAME, L"My Icon Font", L"en-US" }, 
  { DWRITE_FONT_PROPERTY_ID_WEIGHT, L"400", nullptr } 
}; 
               

Nachdem Sie das gewünschte Array von Eigenschaftswerten für eine Schriftart definiert haben, rufen Sie AddFontFaceRefence auf, und übergeben Sie das Eigenschaftenarray sowie den Schriftzeichenverweis. 

hr = pFontSetBuilder->AddFontFaceReference(pFontFaceReference, props, ARRAYSIZE(props)); 

 

Nachdem alle benutzerdefinierten Schriftarten dem Schriftartensatz-Generator hinzugefügt wurden, erstellen Sie zusammen mit ihren benutzerdefinierten Eigenschaften den benutzerdefinierten Schriftartsatz, wie oben gezeigt. 

Erstellen eines benutzerdefinierten Schriftsatzes mithilfe bekannter Remoteschriftarten im Web

Benutzerdefinierte Eigenschaften sind wichtig für das Arbeiten mit Remoteschriftarten. Jeder Schriftzeichenverweis muss einige Informationseigenschaften aufweisen, um die Schriftart zu charakterisieren und von anderen Schriftarten zu unterscheiden. Da die Schriftartdaten für Remoteschriftarten nicht lokal sind, kann DirectWrite eigenschaften nicht direkt von den Schriftartdaten ableiten. Daher müssen Eigenschaften explizit bereitgestellt werden, wenn dem Schriftartensatz-Generator eine Remoteschriftart hinzugefügt wird.

Die Sequenz der API-Aufrufe zum Hinzufügen von Remoteschriftarten zu einem Schriftartensatz ähnelt der Sequenz, die für das vorherige Szenario beschrieben wird. Da die Schriftartdaten jedoch remote sind, unterscheiden sich die Vorgänge zum Lesen der tatsächlichen Schriftartdaten vom Arbeiten mit Dateien im lokalen Speicher. In diesem Fall wurde im Windows 10 Creators Update eine neue Schnittstelle auf niedrigerer Ebene IDWriteRemoteFontFileLoaderhinzugefügt. 

Damit das Remoteschriftdateiladeprogramm verwendet werden kann, muss sie zuerst mit einer DirectWrite-Factory registriert werden. Das Ladeprogramm muss von der App solange aufbewahrt werden, wie die damit verbundenen Schriftarten verwendet werden. Sobald die Schriftarten nicht mehr verwendet werden und irgendwann bevor die Factory zerstört wird, muss das Ladeprogramm nicht mehr registriert werden. Dies kann im Destruktor für die Klasse erfolgen, die das Ladeprogrammobjekt besitzt. Diese Schritte werden unten angezeigt. 

Die Methode zum Erstellen eines benutzerdefinierten Schriftsatzes mithilfe von Remoteschriftarten lautet wie folgt: Dies erfordert das Windows 10 Creators Update.  

1. Erstellen Sie eine IDWriteFactory5-Schnittstelle, wie oben gezeigt.  2. Erstellen Sie eine IDWriteFontSetBuilder Schnittstelle, wie oben gezeigt.  3. Verwenden Sie die Factory, um eine IDWriteRemoteFontFileLoaderzu erhalten.  
IDWriteRemoteFontFileLoader* pRemoteFontFileLoader; 
if (SUCCEEDED(hr)) 
{ 
    hr = pDWriteFactory->CreateHttpFontFileLoader( 
        /* referrerURL */ nullptr, 
        /* extraHeaders */ nullptr, 
        &pRemoteFontFileLoader 
    ); 
} 

Dies gibt eine vom System bereitgestellte Implementierung der Remoteschriftdateiladeschnittstelle zurück, die HTTP-Interaktionen zum Herunterladen von Schriftartdaten im Auftrag der App verarbeiten kann. Eine Verweiser-URL oder zusätzliche Header können angegeben werden, wenn dies vom Schriftartdienst oder diensten erforderlich ist, die die Quelle für die Schriftarten sind.  

Wichtig

Sicherheitshinweis: Wenn versucht wird, eine Remoteschriftart abzurufen, ist das Potenzial für einen Angreifer vorhanden, den beabsichtigten Server zu spoofen, der aufgerufen wird. In diesem Fall würden die Ziel- und Verweiser-URLs und Headerdetails dem Angreifer offengelegt. App-Entwickler sind dafür verantwortlich, dieses Risiko zu verringern. Die Verwendung des HTTPS-Protokolls anstelle von HTTP wird empfohlen. 

 

Ein einzelnes Dateiladeprogramm für Remoteschriftarten kann für mehrere Schriftarten verwendet werden, obwohl unterschiedliche Ladeprogramme verwendet werden können, wenn Schriftarten aus mehreren Diensten abgerufen werden, die unterschiedliche Anforderungen für Referrer-URL oder zusätzliche Header aufweisen. 
4. Registrieren Sie das Remoteschriftartdateiladeprogramm bei der Factory. 

 if (SUCCEEDED(hr)) 
 { 
     hr = pDWriteFactory->RegisterFontFileLoader(pRemoteFontFileLoader); 
 } 

Ab diesem Zeitpunkt ähneln die Schritte zum Erstellen des benutzerdefinierten Schriftartensatzes denen, die für bekannte lokale Schriftartdateien mit zwei wichtigen Ausnahmen beschrieben werden. Zunächst wird das IDWriteFontFile-Objekt mithilfe der Remoteschriftdateiladeschnittstelle erstellt, anstatt die Factory zu verwenden. Zweitens kann die Analyze-Methode nicht verwendet werden, da die Schriftartdaten nicht lokal sind. Stattdessen muss die App wissen, ob es sich bei der Remoteschriftartdatei um eine OpenType Font Collection-Datei handelt, und wenn ja, muss sie wissen, welche der Schriftarten in der Auflistung verwendet wird, und den Index für jeden. Daher sind die verbleibenden Schritte wie folgt. 
5. Verwenden Sie für jede Remoteschriftartdatei die Remoteschriftdateiladeschnittstelle, um eine IDWriteFontFile-zu erstellen, wobei die URL angegeben wird, die für den Zugriff auf die Schriftartdatei erforderlich ist. 

 IDWriteFontFile* pFontFile; 
 hr = pRemoteFontFileLoader->CreateFontFileReferenceFromUrl( 
     pDWriteFactory, 
     /* baseUrl */ L"https://github.com/", 
     /* fontFileUrl */ L"winjs/winjs/blob/master/src/fonts/Symbols.ttf?raw=true", 
     &pFontFile 
 ); 

Beachten Sie, dass die vollständige URL im fontFileUrl-Parameter angegeben werden kann, oder sie kann in Basis- und relative Teile aufgeteilt werden. Wenn eine Basis-URL angegeben wird, muss die Verkettung der baseUrl- und fontFileUrl-Werte die vollständige URL bereitstellen. DirectWrite stellt kein zusätzliches Trennzeichen bereit.

Wichtig

Sicherheits-/Leistungshinweis: Wenn versucht wird, eine Remoteschriftart abzurufen, besteht keine Garantie dafür, dass Windows eine Antwort vom Server erhält. In einigen Fällen antwortet ein Server möglicherweise mit einem Nicht gefundenen Fehler für eine ungültige relative URL, reagiert aber nicht mehr, wenn er mehrere ungültige Anforderungen empfängt. Wenn der Server nicht reagiert, wird Windows irgendwann einen Timeout ausführen, dies kann jedoch mehrere Minuten dauern, wenn mehrere Abrufe initiiert werden. Sie sollten sicherstellen, dass URLs gültig sind, wenn Aufrufe getätigt werden. 

 

Beachten Sie außerdem, dass die URL auf eine unformatierte OpenType-Schriftartdatei (.ttf, .otf, .ttc, .otc) verweisen kann, aber sie kann auch auf Schriftarten in einer WOFF- oder WOFF2-Containerdatei verweisen. Wenn auf eine WOFF- oder WOFF2-Datei verwiesen wird, entpackt die DirectWrite-Implementierung des Remoteschriftdateiladeprogramm automatisch die Schriftartdaten aus der Containerdatei. 
6. Erstellen Sie für jeden Schriftartenindex in der zu verwendenden Remoteschriftartdatei ein IDWriteFontFaceReference-. 

 IDWriteFontFaceReference* pFontFaceReference; 
 hr = pDWriteFactory->CreateFontFaceReference(pFontFile, /* faceIndex */ 0, DWRITE_FONT_SIMULATIONS_NONE, &pFontFaceReference);
  1. Definieren Sie benutzerdefinierte Eigenschaften für das Schriftartenzeichen, wie oben gezeigt. 
  2. Fügen Sie den Schriftzeichenverweis zusammen mit benutzerdefinierten Eigenschaften zum Schriftartensatz-Generator hinzu, wie oben gezeigt. 
  3. Nachdem alle Schriftarten dem Schriftartensatz-Generator hinzugefügt wurden, erstellen Sie den Schriftsatz, wie oben gezeigt. 
  4. Wenn die Remoteschriftarten nicht mehr verwendet werden, heben Sie die Registrierung des Remoteschriftdateiladeprogramms auf. 
hr = pDWriteFactory->UnregisterFontFileLoader(pRemoteFontFileLoader); 

Sobald ein benutzerdefinierter Schriftartsatz mit benutzerdefinierten Remoteschriftarten erstellt wurde, enthält der Schriftartsatz Verweise und Informationseigenschaften für die Remoteschriftarten, aber die tatsächlichen Daten sind weiterhin remote. Die DirectWrite-Unterstützung für Remoteschriftarten ermöglicht es, dass ein Schriftzeichenverweis im Schriftartensatz beibehalten wird, und dass eine Schriftart zur Verwendung im Layout und Rendering ausgewählt wird, die tatsächlichen Daten jedoch erst heruntergeladen werden, wenn sie tatsächlich verwendet werden müssen, z. B. wann das Textlayout ausgeführt wird.  

Eine App kann vorab vorgehen, indem Sie anfordern, dass DirectWrite die Schriftartdaten herunterladen und dann auf die Bestätigung eines erfolgreichen Downloads wartet, bevor die Verarbeitung mit der Schriftart begonnen wird. Ein Netzwerkdownload impliziert jedoch eine gewisse Latenz von unvorhersehbarer Dauer, und der Erfolg ist auch unsicher. Aus diesem Grund ist es in der Regel besser, einen anderen Ansatz zu verfolgen, sodass Layout und Rendering anfänglich alternative oder Fallbackschriftarten verwendet werden können, die bereits lokal sind, während sie den Download der gewünschten Remoteschriftart parallel anfordern und dann die Ergebnisse aktualisieren, sobald die gewünschte Schriftart heruntergeladen wurde. 

Um anzufordern, dass die gesamte Schriftart heruntergeladen wird, bevor sie verwendet wird, kann die IDWriteFontFaceReference::EnqueueFontDownloadRequestrequest-Methode verwendet werden. Wenn die Schriftart sehr groß ist, kann nur ein Teil der Daten für die Verarbeitung bestimmter Zeichenfolgen benötigt werden. DirectWrite stellt zusätzliche Methoden bereit, die verwendet werden können, um Teile der schriftartendaten anzufordern, die für bestimmte Inhalte erforderlich sind, EnqueueCharacterDownloadRequest und EnqueueGlyphDownloadRequest.  

Angenommen, der Ansatz in der App besteht darin, die Verarbeitung zunächst mithilfe lokaler, alternativer oder Fallbackschriftarten zu ermöglichen. Die IDWriteFontFallback::MapCharacters- Methode kann verwendet werden, um lokale Fallbackschriftarten zu identifizieren. Außerdem wird automatisch eine Anforderung zum Herunterladen der bevorzugten Schriftart angefordert. Wenn IDWriteTextLayout verwendet wird und einige oder alle Text im Layout mit einem Remoteschriftverweis formatiert sind, verwendet DirectWrite automatisch die MapCharacters- Methode, um lokale Fallbackschriftarten abzurufen und eine Anforderung zum Herunterladen der Remoteschriftdaten anzufordern. 

DirectWrite verwaltet für jede Factory eine Downloadwarteschlange für Schriftarten, und die Anforderungen, die mit den oben genannten Methoden vorgenommen wurden, werden dieser Warteschlange hinzugefügt. Die Downloadwarteschlange der Schriftart kann mit der IDWriteFactory3::GetFontDownloadQueue-Methode abgerufen werden. 

Wenn eine Downloadanforderung gestellt wird, aber die Schriftartdaten bereits lokal sind, führt dies zu einer no-op: Der Downloadwarteschlange wird nichts hinzugefügt. Eine App kann überprüfen, ob die Warteschlange leer ist oder ausstehende Downloadanforderungen vorhanden sind, indem Sie die IDWriteFontDownloadQueue::IsEmpty-Methode aufrufen. 

Nachdem der Warteschlange Remoteschriftartenanforderungen hinzugefügt wurden, muss der Downloadvorgang initiiert werden. Wenn Remoteschriftarten in IDWriteTextLayoutverwendet werden, wird der Download automatisch initiiert, wenn die App IDWriteTextLayout Methoden aufruft, die Layout- oder Renderingvorgänge erzwingen, z. B. getLineMetrics oder Draw-Methoden. In anderen Szenarien muss die App den Download direkt initiieren, indem IDWriteFontDownloadQueue::BeginDownloadaufgerufen wird.  

Wenn ein Download abgeschlossen ist, muss die App geeignete Aktionen ausführen – mit ausstehenden Vorgängen fortfahren oder wiederholte Vorgänge, die anfänglich mit Fallbackschriftarten durchgeführt wurden. (Wenn das Textlayout von DirectWrite verwendet wird, können IDWriteTextLayout3::InvalidateLayout verwendet werden, um die temporären Ergebnisse zu löschen, die mit Fallbackschriftarten berechnet werden.) Damit die App benachrichtigt werden kann, wenn der Downloadvorgang abgeschlossen ist und geeignete Aktionen ausgeführt werden kann, muss die App eine Implementierung der IDWriteFontDownloadListener--Schnittstelle bereitstellen und diese an den BeginDownload-Aufruf übergeben. 

Wichtig

Sicherheits-/Leistungshinweis: Wenn versucht wird, eine Remoteschriftart abzurufen, besteht keine Garantie dafür, dass Windows eine Antwort vom Server erhält. Wenn der Server nicht antwortet, wird Windows irgendwann einen Timeout ausführen. Dies kann jedoch mehrere Minuten dauern, wenn mehrere Remoteschriftarten abgerufen werden, aber fehlschlagen. Der BeginDownload-Aufruf wird sofort zurückgegeben. Apps sollten die Benutzeroberfläche nicht blockieren, während sie auf IDWriteFontDownloadListener::D ownloadCompleted- aufgerufen wird. 

 

Beispielimplementierungen dieser Interaktionen mit der Downloadwarteschlange für Schriftarten von DirectWrite und der IDWriteFontDownloadListener- Schnittstelle können im Beispiel DirectWrite Custom Font Setsund auch im Beispiel DirectWrite Downloadable Fontsangezeigt werden. 

Erstellen eines benutzerdefinierten Schriftartsatzes mithilfe von Schriftartdaten, die in den Arbeitsspeicher geladen wurden

Ebenso wie die Vorgänge auf niedriger Ebene zum Lesen von Daten aus einer Schriftartdatei für Dateien auf einem lokalen Datenträger und Remotedateien im Web unterschiedlich sind, gilt das gleiche auch für Schriftartdaten, die in einen Speicherpuffer geladen wurden. Im Windows 10 Creators Update IDWriteInMemoryFontFileLoaderwurde eine neue Low-Level-Schnittstelle für die Verarbeitung von In-Memory-Schriftartdaten hinzugefügt. 

Wie bei einem Dateiladeprogramm für Remoteschriftarten muss zunächst ein Dateiladeprogramm für arbeitsspeicherinterne Schriftarten bei einer DirectWrite-Factory registriert werden. Das Ladeprogramm muss von der App solange aufbewahrt werden, wie die damit verbundenen Schriftarten verwendet werden. Sobald die Schriftarten nicht mehr verwendet werden und irgendwann bevor die Factory zerstört wird, muss das Ladeprogramm nicht mehr registriert werden. Dies kann im Destruktor für die Klasse erfolgen, die das Ladeprogrammobjekt besitzt. Diese Schritte werden unten angezeigt. 

Wenn die App separate Informationen zu den durch die Daten dargestellten Schriftartensichten enthält, kann sie einem Schriftartensatz-Generator einzelne Schriftartenbezüge mit angegebenen benutzerdefinierten Eigenschaften hinzufügen. Da sich die Schriftartdaten jedoch im lokalen Speicher befinden, ist dies nicht erforderlich; DirectWrite kann die Daten direkt lesen, um die Eigenschaftswerte abzuleiten. 

DirectWrite geht davon aus, dass sich die Schriftartdaten im Unformat, OpenType-Format befinden und einer OpenType-Datei (.ttf, .otf, .ttc, .otc) entsprechen, sondern im Arbeitsspeicher und nicht auf dem Datenträger. Die Daten können nicht in einem WOFF- oder WOFF2-Containerformat vorliegen. Die Daten können eine OpenType Font Collection darstellen. Wenn keine benutzerdefinierten Eigenschaften verwendet werden, kann die IDWriteFontSetBuilder1::AddFontFile Methode verwendet werden, um alle Schriftarten in den Daten in einem einzigen Aufruf hinzuzufügen. 

Ein wichtiger Aspekt für das In-Memory-Szenario ist die Lebensdauer der Daten. Wenn ein Zeiger auf den Puffer für DirectWrite bereitgestellt wird, ohne dass ein Besitzer vorhanden ist, macht DirectWrite eine Kopie der Daten in einen neuen Speicherpuffer, den er besitzt. Um das Kopieren von Daten und zusätzlichen Speicherzuweisungen zu vermeiden, kann die App ein Datenbesitzerobjekt übergeben, das IUnknown implementiert, und das besitzt den Speicherpuffer, der die Schriftartdaten enthält. Durch die Implementierung dieser Schnittstelle kann DirectWrite der Referenzanzahl des Objekts hinzufügen und so die Lebensdauer der eigenen Daten sicherstellen. 

Die Methode zum Erstellen eines benutzerdefinierten Schriftsatzes mithilfe von In-Memory-Schriftartdaten lautet wie folgt: Dies erfordert das Windows 10 Creators Update. Dabei wird davon ausgegangen, dass ein von der App implementiertes Datenbesitzerobjekt implementiert wird, das IUnknown implementiert und außerdem Methoden enthält, die einen Zeiger auf den Speicherpuffer und die Größe des Puffers zurückgeben. 

1. Erstellen Sie eine IDWriteFactory5-Schnittstelle, wie oben gezeigt. 2. Erstellen Sie eine [**IDWriteFontSetBuilder1**](/windows/win32/api/dwrite_3/nn-dwrite_3-idwritefontsetbuilder1)-Schnittstelle, wie oben gezeigt. 3. Verwenden Sie die Factory, um einen IDWriteInMemoryFontFileLoader abzurufen.  
 IDWriteInMemoryFontFileLoader* pInMemoryFontFileLoader; 
if (SUCCEEDED(hr)) 
{ 
    hr = pDWriteFactory->CreateInMemoryFontFileLoader(&pInMemoryFontFileLoader); 
}

Dies gibt eine vom System bereitgestellte Implementierung der Dateiladeschnittstelle für speicherinterne Schriftarten zurück. 
4. Registrieren Sie das Dateiladeprogramm im Arbeitsspeicher bei der Factory. 

if (SUCCEEDED(hr)) 
{ 
    hr = pDWriteFactory->RegisterFontFileLoader(pInMemoryFontFileLoader); 
}

 
5. Verwenden Sie für jede In-Memory-Schriftartdatei das Speicherdateiladeprogramm, um ein IDWriteFontFile-zu erstellen. 

IDWriteFontFile* pFontFile; 
hr = pInMemoryFontFileLoader->CreateInMemoryFontFileReference( 
    pDWriteFactory, 
    pFontDataOwner->fontData /* returns void* */, 
    pFontDataOwner->fontDataSize /* returns UINT32 */, 
    pFontDataOwner /* ownerObject, owns the memory with font data and implements IUnknown */, 
    &pFontFile 
); 

 
6. Fügen Sie das IDWriteFontFile-Objekt mithilfe der AddFontFile--Methode dem Schriftartensatz-Generator hinzu, wie oben gezeigt.  Wenn dies erforderlich ist, kann die App stattdessen einzelne IDWriteFontFaceReference Objekte basierend auf dem IDWriteFontFileerstellen, optional benutzerdefinierte Eigenschaften für jeden Schriftzeichenverweis definieren und dann den Schriftart-Gesichtsverweis mit benutzerdefinierten Eigenschaften mithilfe der AddFontFaceReference--Methode hinzufügen, wie oben gezeigt. 
7. Nachdem alle Schriftarten dem Schriftartensatz-Generator hinzugefügt wurden, erstellen Sie den benutzerdefinierten Schriftsatz, wie oben gezeigt. 
8. Wenn die In-Memory-Schriftarten nicht mehr verwendet werden, heben Sie die Registrierung des Speicherdateiladeprogramms auf. 

hr = pDWriteFactory->UnregisterFontFileLoader(pInMemoryFontFileLoader);

 

Erweiterte Szenarien

Einige Apps haben möglicherweise spezielle Anforderungen, die eine erweiterte Verarbeitung erfordern, als oben beschrieben. 

Kombinieren von Schriftsätzen

Einige Apps müssen möglicherweise einen Schriftsatz erstellen, der eine Kombination aus Elementen aus anderen Schriftartsätzen umfasst. Beispielsweise kann eine App einen Schriftartsatz erstellen, der alle auf dem System installierten Schriftarten mit einer Auswahl von benutzerdefinierten Schriftarten kombiniert oder installierte Schriftarten kombiniert, die bestimmten Kriterien mit anderen Schriftarten entsprechen. DirectWrite verfügt über APIs zur Unterstützung der Manipulation und Kombination von Schriftartsätzen. 

Um zwei oder mehr Schriftartsätze zu kombinieren, fügt die IDWriteFontSetBuilder::AddFontSet Methode alle Schriftarten in bestimmten Schriftartensatz hinzu, die einem Schriftartsatz-Generator in einem einzigen Aufruf hinzugefügt werden sollen. Wenn nur bestimmte Schriftarten aus einem vorhandenen Schriftartensatz im neuen Schriftartensatz gewünscht werden, kann die IDWriteFontSet::GetMatchingFonts-Methode verwendet werden, um ein neues Schriftartsatzobjekt abzuleiten, das gefiltert wurde, um nur Schriftarten einzuschließen, die bestimmte Eigenschaften entsprechen. Diese Methoden bieten eine einfache Möglichkeit, einen benutzerdefinierten Schriftartsatz zu erstellen, der Schriftarten aus zwei oder mehr vorhandenen Schriftartsätzen kombiniert

Verwenden lokaler WOFF- oder WOFF2-Schriftartdaten

Wenn eine App Über Schriftartdateien im lokalen Dateisystem oder in einem Speicherpuffer verfügt, sie aber die WOFF- oder WOFF2-Containerformate verwenden, stellt DirectWrite (Windows 10 Creator Update oder höher) eine Methode zum Entpacken des Containerformats bereit, IDWriteFactory5::UnpackFontFile, die ein IDWriteFontFileStreamzurückgibt. 

Die App benötigt jedoch eine Möglichkeit zum Abrufen des IDWriteFontFileStream- in ein Schriftartdateiladeobjekt. Eine Möglichkeit hierzu ist das Erstellen einer benutzerdefinierten IDWriteFontFileLoader Implementierung, die den Datenstrom umschließt. Wie bei anderen Schriftartendateiladeern muss dies vor der Verwendung registriert und die Registrierung aufgehoben werden, bevor die Factory den Gültigkeitsbereich überschreitet.  

Wenn das benutzerdefinierte Ladeprogramm auch mit unformatierten (nicht gepackten) Schriftartdateien verwendet wird, muss die App auch eine benutzerdefinierte Implementierung der IDWriteFontFileStream Schnittstelle für die Verarbeitung dieser Dateien bereitstellen. Es gibt jedoch einfachere Möglichkeiten, apIs zu verwenden, die oben für die Verarbeitung von Rohschriftdateien beschrieben werden. Die Notwendigkeit einer benutzerdefinierten Streamimplementierung könnte vermieden werden, indem separate Codepfade für gepackte Schriftartdateien und unformatierte Schriftartdateien verwendet werden. 

Nachdem ein benutzerdefiniertes Dateiladeprogrammobjekt erstellt wurde, werden die gepackten Schriftartdateidaten dem Ladeprogramm mithilfe von appspezifischen Mitteln hinzugefügt. Das Ladeprogramm kann mehrere Schriftartdateien verarbeiten, von denen jeder mithilfe eines app-definierten Schlüssels identifiziert wird, der für DirectWrite undurchsichtig ist. Nachdem dem Ladeprogramm eine gepackte Schriftartdatei hinzugefügt wurde, wird die IDWriteFactory::CreateCustomFontFileReference--Methode verwendet, um eine IDWriteFontFile- basierend auf diesem Ladeprogramm für die von einem bestimmten Schlüssel identifizierten Schriftartdaten abzurufen.  

Die eigentliche Entpackung der Schriftartdaten kann erfolgen, wenn dem Ladeprogramm Schriftarten hinzugefügt werden, aber auch im IDWriteFontFileLoader::CreateStreamFromKey-Methode behandelt werden, die DirectWrite aufruft, wenn die Schriftartdaten zuerst gelesen werden müssen. 

Nachdem ein IDWriteFontFile-Objekt erstellt wurde, werden die verbleibenden Schritte zum Hinzufügen der Schriftarten zu einem benutzerdefinierten Schriftartsatz wie oben beschrieben beschrieben. 

Eine Implementierung mit diesem Ansatz wird im Beispiel für benutzerdefinierte DirectWrite-Schriftartensätzeveranschaulicht. 

Verwenden von DirectWrite-Remoteschriftartenmechanismen mit benutzerdefinierter Netzwerkimplementierung auf niedriger Ebene

Die DirectWrite-Mechanismen für die Behandlung von Remoteschriftarten können in Mechanismen auf höherer Ebene unterteilt werden– mit Schriftartsätzen, die Schriftartenbeschriftungsverweise für Remoteschriftarten enthalten, die Lokalität der Schriftartdaten überprüfen und die Warteschlange für Schriftdownloadanforderungen verwalten – und die Mechanismen auf niedrigerer Ebene, die den tatsächlichen Download behandeln. Einige Apps möchten möglicherweise die Mechanismen für Remoteschriftarten auf höherer Ebene verwenden, erfordern aber auch benutzerdefinierte Netzwerkinteraktionen, z. B. die Kommunikation mit Servern mit anderen Protokollen als HTTP. 

In diesem Fall muss eine App eine benutzerdefinierte Implementierung des IDWriteRemoteFontFileLoader Schnittstelle erstellen, die mit anderen Schnittstellen auf niedrigerer Ebene interagiert. Die App muss außerdem benutzerdefinierte Implementierungen dieser Schnittstellen auf niedrigerer Ebene bereitstellen: IDWriteRemoteFontFileStreamund IDWriteAsyncResult. Diese drei Schnittstellen verfügen über Rückrufmethoden, die DirectWrite während downloadvorgängen aufruft. 

Wenn IDWriteFontDownloadQueue::BeginDownload aufgerufen wird, sendet DirectWrite Abfragen an das Remoteschriftdateiladeprogramm zur Lokalität der Daten und fordert den Remotedatenstrom an. Wenn Daten nicht lokal sind, wird die BeginDownload-Methode des Datenstroms aufgerufen. Die Streamimplementierung sollte diesen Aufruf nicht blockieren, sondern sofort zurückgeben und ein IDWriteAsyncResult--Objekt zurückgeben, das das Wait-Handle DirectWrite bereitstellt, verwendet, um auf den asynchronen Downloadvorgang zu warten. Die benutzerdefinierte Streamimplementierung ist für die Verarbeitung der Remotekommunikation verantwortlich. Wenn das Abschlussereignis aufgetreten ist, ruft DirectWrite IDWriteAsyncResult::GetResult auf, um das Ergebnis des Vorgangs zu bestimmen. Wenn das Ergebnis erfolgreich ist, wird erwartet, dass nachfolgende ReadFragment-Aufrufe an den Datenstrom für die heruntergeladenen Bereiche erfolgreich sind. 

Wichtig

Sicherheits-/Leistungshinweis: Wenn versucht wird, eine Remoteschriftart abzurufen, besteht das Potenzial für einen Angreifer im Allgemeinen, den beabsichtigten Server zu spoofen, der aufgerufen wird, oder dass der Server möglicherweise nicht reagiert. Wenn Sie benutzerdefinierte Netzwerkinteraktionen implementieren, haben Sie möglicherweise mehr Kontrolle über Gegenmaßnahmen als beim Umgang mit Servern von Drittanbietern. Es liegt jedoch an Ihnen, geeignete Gegenmaßnahmen zu berücksichtigen, um die Offenlegung von Informationen oder denial of Service zu vermeiden. Sichere Protokolle wie HTTPS werden empfohlen. Außerdem sollten Sie ein Timeout erstellen, damit das ereignishandle, das an DirectWrite zurückgegeben wird, schließlich festgelegt wird. 

 

Unterstützen von Szenarien für frühere Windows-Versionen

Die beschriebenen Szenarien können in DirectWrite in früheren Versionen von Windows unterstützt werden, erfordern jedoch eine wesentlich benutzerdefiniertere Implementierung auf dem Teil der App mithilfe der eingeschränkteren APIs, die vor Windows 10 verfügbar waren. Weitere Informationen finden Sie unter benutzerdefinierten Schriftartsammlungen (Windows 7/8).