Rendering Devanagari Ligatures (Unicode) in Java Swing JComponent su Mac OS X

Question

Sto cercando di ottenere le legature Devanagari (nelle stringhe Unicode) rese correttamente su Mac OS X 10.6.

Le stringhe sono disegnate su a JComponent e prendi RenderingHints per antialiasing. Le legature vengono visualizzate correttamente in Windows XP SP2 e 7 e Ubuntu, ma in Mac OS X, le legature vengono decomposti (o meglio, non unite correttamente), i diacritici vengono spostati dalle loro posizioni, ecc. (Cfr. Esempio di rendering corretto da Win XP SP2 a sinistra (con RenderingHints Chiave antialiasing ON), Esempio di rendering errato da Mac OS X 10.6.7 a destra (antializzazione DEFAULT = OFF).

Ho impostato il carattere come segue, quindi dovrebbe utilizzare un carattere predefinito su qualsiasi sistema:

new Font(null,Font.PLAIN,20);

Credo che tutto ciò potrebbe avere qualcosa a che fare con il fatto che il personaggio predefinito che codifica sui Mac sia MacRoman (non un sottoinsieme UTF-8) e che altri sistemi (come Windows) utilizzino un sottoinsieme UTF-8 (come WinLatin-1 ) o CP1252 o tale.

Anche con queste informazioni a portata di mano, sono al buio su come gestire questo problema. Quindi sarei molto grato se qualcuno fosse in grado di indicarmi nella giusta direzione.

Ho già provato una serie di cose:

• L'impostazione del carattere su Devanagari MT non ha risolto il problema
• TextAttribute LIGATURES_ON non ha risolto il problema

Sarei estremamente grato per qualsiasi suggerimento o frammenti di codice da parte di altri sviluppatori (preferibilmente con un background hindi che si sviluppa su Mac).

Answer 1

Usando il rendering al quarzo invece del rendering Java 2D.

Ciò fa una differenza sostanziale nella qualità del rendering glifo. Deve essere fatto per primo, come suggerito qui.

if (System.getProperty("os.name").startsWith("Mac OS X")) {
    System.setProperty("apple.awt.graphics.UseQuartz", "true");
}

Potresti anche guardare l'utilizzo TextLayout, come la FontRenderContext può applicare RenderingHints.KEY_FRACTIONALMETRICS.

Answer 2

Non sono un esperto me stesso, ma qui alcuni suggerimenti. Per quanto ho capito da Wikipedia, è molto probabile che il problema sia il tuo carattere. Mi scuso in anticipo per le lunghe citazioni, ma altrimenti avrei potuto solo collegare i 2 articoli di Wikipedia.

Qui una parte della sezione su legature dal Articolo Unicode:

Legature

Molti script, tra cui arabo e Devanagari, hanno regole ortografiche speciali che richiedono che determinate combinazioni di forme di lettere siano combinate in forme di legame speciali. Le regole che regolano la formazione della legatura possono essere piuttosto complesse, che richiedono tecnologie speciali di formazione degli script come ACE (motore calligrafico arabo per decotipo negli anni '80 e utilizzato per generare tutti gli esempi arabi nelle edizioni stampate dello standard Unicode), che è diventato la prova del concetto di OpenType (di Adobe e Microsoft), Grafite (di Sil International ), o AAT (di Apple).

Leggendo ulteriormente nel AAT (Apple Advanced Tipography) Articolo, rivela le seguenti informazioni. Consiglio di leggere l'intero articolo.

AAT e OpenType in Mac OS X

A partire da Mac OS X 10.5 Leopard, è disponibile un supporto parziale per OpenType. Il supporto è attualmente limitato agli script occidentali e all'arabo (a partire dal 2011). Se un carattere ha tabelle AAT, verranno utilizzati per la tipografia. Se il carattere non ha tabelle AAT ma ha tabelle Opentype, verranno utilizzate nella misura in cui il sistema le supporta.

Ciò significa che molti caratteri di OpenType per gli script occidentali o mediorientali possono essere utilizzati senza modifiche su Mac OS X 10.5, ma gli script dell'Asia meridionale come Thai e Devanagari non possono. Questi richiedono tabelle AAT per il layout adeguato.

E più tardi nella sezione sul layout dei caratteri:

Dal momento che AAT opera interamente con glifi e mai con personaggi, Tutte le informazioni di layout necessarie per produrre il display corretto risiede all'interno del carattere stesso. Ciò consente di aggiungere i caratteri per nuovi script senza richiedere un supporto specifico dal sistema operativo.

E ultimo:

AAT per gli script di Indic

Per gli script di Indic, le uniche caratteristiche necessarie sono il riordino e la sostituzione del glifo. AAT supporta entrambi. Come notato sopra, i caratteri Opentype per gli script indic richiedono l'aggiunta di tabelle AAT prima che funzionino correttamente su Mac OS X. Nota, tuttavia, che ciò vale solo per il software dipendente dal supporto del sistema di OpenType. I programmi che forniscono la propria implementazione di OpenType rendono indicativo correttamente i caratteri OpenType. (Possono, tuttavia, non rendere correttamente i caratteri indicati con le tabelle AAT.)

Mac OS X 10.5 Spesa con caratteri per Devanagari, Gurmukhi, Gujarati, Thai, Tibetan e Tamil. I caratteri per altri script indicati sono disponibili da terze parti.

Forse devi scegliere un carattere che supporta esplicitamente Devanagari.

Answer 3

Sto avendo lo stesso identico problema con un progetto su cui sto lavorando con la sceneggiatura di Gurmukhi. Ora ho provato entrambi i caratteri con tabelle AAT che arrivano fasci con Mac OS X (Gurmukhi MT, Gurmukhi MN) e caratteri con tabelle OpenType. Nessuno dei due funziona in Java su Mac OS X, ma i caratteri OpenType sono leggermente più leggibili. L'unico problema è che il personaggio "hant" non rende la mezza forma di personaggi come dovrebbe.

Penso che il problema sia con i caratteri che stiamo usando e la loro compatibilità con Java su Mac OS X.

Answer 4

Ho affrontato lo stesso problema quando ho provato http://jambula.sourceforge.net su Mac per la lingua tamil.

La soluzione alternativa che mi è venuta in mente è stata quella di usare il font.createfont per caricare un carattere esplicito.

Puoi vedere un programma di test su: Testrendering.java

java org.jambula.image.TestRendering text.png

rende il testo tamil erroneamente in text.png

Tuttavia

java org.jambula.image.TestRendering text.png "/Library/Fonts/Arial Unicode.ttf"

lo rende correttamente.

Potrebbe essere dovuto a https://bugs.openjdk.java.net/browse/jdk-7162125.