WPF - Salvataggio del carattere su disco, quindi istanziazione di GlyphTypeface per l'eccezione di caratteri. Perché?

Question

Sto parlando di glifi e documenti WPF e ho riscontrato un'eccezione di riferimento null nel framework .Net 4.

Estrarre e salvare tipi di carattere true-type su disco come file .ttf, quindi provare a creare glifi in base ai caratteri. La prima volta che salvi un font su disco e istanzio un GlyphTypeface basato sul font dopo creando un GlyphTypeface da un altro font nella stessa cartella ottengo un'eccezione di riferimento null.

Dire che ho i caratteri A e B. B non è stato salvato su disco (A maggio o non può essere stato salvato su disco, che non sembra avere importanza):

1) salvare su disco B nella stessa cartella di A,
2) creare GlyphTypeface utilizzando il carattere A,
3) creare GlyphTypeface utilizzando il carattere B = eccezione.

Null reference exception at: 
at MS.Internal.FontCache.FontFaceLayoutInfo.IntMap.TryGetValue(Int32 key, UInt16& value) 
at MS.Internal.FontCache.FontFaceLayoutInfo..ctor(Font font) 
at System.Windows.Media.GlyphTypeface.Initialize(Uri typefaceSource, StyleSimulations styleSimulations) 
at System.Windows.Media.GlyphTypeface..ctor(Uri typefaceSource) 

Se riavvio l'app ed eseguo di nuovo (con il carattere B già presente sul disco), il passaggio 3 non genera un'eccezione.

Il codice per salvare un tipo di carattere su disco è semplicemente scrivendo una sezione da un flusso binario e lasciarsi andare del file:

if (!File.Exists(filename)) 
{ 
    using (FileStream fs = File.Create(filename, length)) 
    { 
     fs.Write(m_data, m_index, length); 
     fs.Close(); 
    } 
} 

Tutte le idee? Non voglio dover mettere ogni carattere nella sua cartella ...

Grazie per il vostro tempo.

Answer 1

Ho finito per utilizzare la soluzione alternativa di salvare ogni carattere nella propria cartella (utilizzando il nome del carattere per il nome della cartella). L'eccezione è andata via, quindi immagino che potremo dare un errore a .Net.

Answer 2

La mia soluzione alternativa era semplicemente sostituire i glifi <> con equosolidale < TextBlock> s. La differenza di coppia di pixel nel layout non era un problema nel mio caso.

Come hai notato per te, anche nel mio caso non era un problema in .Net 3.5, ma appariva in .Net 4.0.

Answer 3

I (e un collaboratore) abbiamo finalmente trovato il nostro problema specifico: non salvare i file dei font su %TEMP%. Per qualche ragione, avere i font salvati in un'altra cartella lo fa funzionare (per noi), e salvarlo in qualsiasi punto all'interno di %TEMP% si interrompe.

Answer 4

Questo errore mi sta facendo impazzire ma penso di avere una migliore comprensione di ciò che sta accadendo ora.

Per la prova ho usato il seguente XAML:

<Page 
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> 
    <Glyphs 
    FontUri="C:\Users\Public\Desktop\A.ttf" 
    FontRenderingEmSize="100" 
    Fill="Black" 
    UnicodeString="Test"/> 
</Page> 

Utilizzando l'applicazione XamlPadX che corre sul runtime .NET 2 potevo affidabile rendere il codice XAML, non importa dove ho messo il tipo di carattere.

Utilizzando l'applicazione Kaxaml che viene eseguita sul runtime .NET 4, XAML spesso non riesce a eseguire il rendering in base a dove ho inserito il carattere nel file system. Spostando il file del font e rinominandolo ho cercato di scoprire un pattern in ciò che era permesso. Tuttavia, è stato molto difficile vedere uno schema.

Per esempio memorizzare il carattere nel percorso seguito renderebbe glifi:

C:\Users\Public\Desktop\A.ttf - OK 

rinominandolo da A.ttf a B.ttf potrebbe generare l'eccezione:

C:\Users\Public\Desktop\B.ttf - throws exception 

Cambiando l'estensione sarebbe anche gettare il eccezione:

C:\Users\Public\Desktop\A.odttf - throws exception 

Rinominare parti del percorso a volte causerebbe il caos ma non sono riuscito a vedere alcun modello. Inizialmente ho usato il percorso temporaneo e ottenere delle eccezioni mi ha portato a questa domanda e alla risposta sul non utilizzare quel percorso. Tuttavia, in seguito sono stato in grado di utilizzare quel percorso fintanto che il nome del file è A.ttf e non B.ttf, quindi evitare il percorso temporaneo non è una soluzione sicura.

Ad un certo punto durante i miei test utilizzando la mia applicazione WPF il nome del file B.ttf ha iniziato improvvisamente a funzionare. Tuttavia, ho dovuto riavviare l'applicazione Kaxaml prima che accettasse il nome del file B.ttf. Inoltre, a quel punto il nome del file A.odttf stava ancora generando eccezioni.

Il mio suggerimento è di utilizzare un'applicazione come Kaxaml o di creare una piccola applicazione WPF per verificare quali nomi di file di font sono accettabili e quindi usarli. Tuttavia, temo che la natura di questo bug sia tale che un nome di file di font "buono" possa diventare "cattivo" in un momento successivo. Solo il tempo mostrerà.

Answer 5

Secondo XamlToys Doesn't work on framework 4.0???, il problema è nell'estensione del file per i caratteri parziali.

Quando ho rinominato i file .ofttf salvati in .ttf, tutto funziona di nuovo. Non ho la più pallida idea del perché sia ​​così. Sembra essere nuovo in .NET 4.0.