Caratteri giapponesi simili a quelli cinesi su Android

Question

PREAMBOLO: dall'API 17 (Android 4.2), esiste un metodo TextView.setTextLocale() che risolve esplicitamente questo problema per TextViews e classi derivate. Assegnare un locale giapponese (Locale.JAPAN) e i caratteri Unihan appariranno in giapponese.

---

Ho un'applicazione su Android che visualizza testo in giapponese in WebViews e TextViews. Ci sono alcuni caratteri cinesi (kanji) che appaiono, per convenzione, in modo diverso in Cina e in Giappone, ma condividono lo stesso codice Unicode. Normalmente, il browser farebbe affidamento sul tag lang per scegliere il glifo corretto. Su Android, tutti si basano automaticamente sulle loro forme cinesi e io voglio forme giapponesi.

Il problema è ben spiegato in this article. Questo articolo serve anche come perfetta illustrazione del problema: se guardato su Android (fino a 2,2), i caratteri negli "Esempi di caratteri dipendenti dalla lingua" sembrano tutti uguali e cinesi.

L'utilizzo dell'attributo lang="ja" non è di aiuto. Anche l'impostazione dell'intero sistema locale in giapponese non è di aiuto.

Mi chiedo dei telefoni Android venduti in Giappone. Anche personaggi come 直, 今, 化 sembrano in stile cinese? Sto assumendo no.

Quindi le domande sono: ci sono immagini localizzate ufficiali di Android là fuori? Posso averne uno per funzionare sull'emulatore? Il font DroidSansFallback è ancora l'unico font abilitato CJK su quelli? E se lo è, è lo stesso del vanilla USA Android?

Sto sperando che i glifi giapponesi siano nascosti da qualche parte nel font (area privata Unicode o qualcosa del genere). In tal caso, potrei sfruttarli ...

EDIT: trova DroidSansJapanese.ttf, installato sull'emulatore copiandolo in/system/fonts, riavviato. Non ha fatto differenza sull'aspetto dell'articolo di Unihan. Anche l'area di suggerimento dell'input di testo giapponese (che dovrebbe essere meglio conosciuto) viene visualizzata come se fosse cinese.

Come faccio a sapere il nome di carattere del DroidSansJapanese.ttf? Ho la sensazione che sia ancora Droid Sans, come nel font DroidSansFallback integrato. Ma se contengono lo stesso carattere tipografico, cosa governa quale dovrebbe avere la precedenza? Si potrebbe pensare - sistema locale, ma apparentemente no. I caratteri in Android sono installati semplicemente copiando, giusto?

Answer 1

Ci sono caratteri con supporto giapponese completo. Ho sentito alcune persone parlare di DroidSansJapanese.tff e TakaoPGothic.

Answer 2

Trovato una soluzione un po 'clou.

Il font DroidSansJapanese.ttf esiste ed è disponibile per il download, ad esempio here. L'ho scaricato, rinominato in DroidSansJapanese.mp3 per evitare il limite di asset compresso di 1 MB e posizionato sotto assets/web. Ho poi presentato la seguente dichiarazione CSS:

@font-face 
{ 
font-family: "DroidJP"; 
src:url('DroidSansJapanese.mp3') 
} 

poi ho aggiunto 'DroidJP' al font-family di ogni stile CSS rilevanti. Il modo in cui carico il mio HTML, la cartella assets/web è già designata come base per il caricamento del contenuto collegato.

Dopo un attento esame, ho trovato diversi posti nell'app in cui il giapponese era in TextView s.Per quelli, ho caricato il carattere in questo modo:

Typeface s_JFont = 
    Typeface.createFromAsset(Ctxt.getAssets(), "web/DroidSansJapanese.mp3"); 

e chiamai setTypeface() su ogni TextView rilevante. Adesso per PROFIT!

Questo ha ampliato il mio APK di circa 1 MB. C'era un modo alternativo, in cui avrei archiviato il font nelle risorse in forma compressa - che mi avrebbe risparmiato circa 500 KB di dimensione APK, ma poi avrei dovuto espanderlo alla memoria del telefono al primo avvio, sul percorso della cartella dati e perdi la compatibilità con Android 1.5.

Alcuni di credito è dovuto: here e here. Non funziona su Android 2.1 (le WebViews, non le TextView): è uno known bug.

Ora, la domanda rimane: come identificare i dispositivi in ​​cui il carattere predefinito contiene già le forme giapponesi?

EDIT re: l'mp3 hack. Ho implementato la soluzione Chunked in un primo momento, ma poi ho deciso di utilizzare il carattere nelle risorse. L'approccio chunked ha una testa - più piccolo formato APK - e le seguenti aspetti negativi:

• Occupa più memoria del telefono cellulare - si finisce per immagazzinare sia di carattere compresso in attività e non compresso nella directory dei dati
• non è compatibile con Android 1.5 sul lato TextView - metodo Typeface.createFromFile() è stato introdotto nel livello API 4
• generazione complica HTML - CSS con la dichiarazione @ font-face deve essere parametrizzata, poiché il percorso di dati è una variabile
• rallenta la prima applicazione startup - passi il tempo a combinare i pezzi

La memorizzazione del font come asset compresso non è un'opzione: il font non viene visualizzato in WebView e si può vedere chiaramente in LogCat il messaggio "Data supera UNCOMPRESS_DATA_MAX".