Pregunta

Saludos,

Estoy escribiendo una aplicación Flash que tiene soporte multilingüe. Mi elección inicial de fuente para esto fue Tahoma, por su soporte Unicode. El cliente prefiere una fuente no estándar, como Lucida Handwriting. Lucida Handwriting no tiene el mismo, por ejemplo, soporte cirílico que Tahoma, lo que plantea un problema que hay algunas formas de resolver, y me gustaría pedirle su consejo sobre cuál es preferible:

Por lo que entiendo, podría:

  • Entregue al cliente una lista de fuentes totalmente compatibles con Unicode (cirílico, hebreo, árabe, chino tradicional, asiático oriental, etc.) para elegir. (No tengo idea de dónde obtener esa lista; mi búsqueda en la web solo ha resultado en listas de fuentes parcialmente compatibles con Unicode. Pruebe http://look.fo/list-of-unicode-compliant-fonts como un buen punto de partida para ver dónde busqué).
  • Dependiendo de la ubicación del cliente (que ya tenemos), renderice en Lucida Handwriting para usuarios de habla inglesa y en Tahoma para usuarios internacionales. Esto puede ser algo de dolor de cabeza; ¿Alguien ha tenido alguna experiencia con este enfoque?
  • Cree una nueva fuente (IE, AlexeyMK Bold) que use la escritura a mano de Lucida para inglés y Tahoma para todo lo demás. Esto anuncia algo así como 500k al peso del archivo Flash, pero debería (si lo entiendo correctamente) solo cargarse la primera vez.

¿Qué aconsejas? ¿Cuáles de estas son soluciones razonables y cuáles están completamente disponibles? ¿Hay alguna forma en la que no estoy pensando?

Muchas gracias! Alexey

EDITAR: Un buen artículo sobre el tema: http://www.itworld.com/print/ 58558

¿Fue útil?

Solución

Bueno, en última instancia, solo tiene dos opciones reales: incrustar una fuente en su SWF, garantizando el aspecto de sus fuentes, o no, y usar las fuentes del dispositivo. (O una combinación de los dos, utilizando fuentes incrustadas o de dispositivo según la región).

Si no incrusta ninguna fuente, la fuente que defina para su texto es, en última instancia, una sugerencia: lo que verá el usuario son las fuentes del dispositivo, representadas por su propia máquina (usando las fuentes en esa máquina). Entonces puedes & Quot; sugerir & Quot; Tahoma, pero lo que ve el usuario dependerá de si tiene esa fuente (y puede variar para, por ejemplo, las versiones de Mac de la fuente frente a las versiones de PC). Naturalmente, esto también depende del apoyo; si no tienen fuentes asiáticas, entonces no verán ningún chino, por ejemplo. (Nota: también puede elegir una fuente como & Quot; _sans & Quot ;, que simplemente le dice al cliente que use su fuente sans-serif estándar. Supongo que en la práctica esto terminará siendo la misma fuente eso hubiera sido elegido si hubieras definido & "; Tahoma &"; pero YMMV.)

Si incrusta sus fuentes, entonces el usuario verá exactamente lo que espera que vean, porque la fuente está representada por Flash y no por el sistema operativo. Pero si incrusta completamente para todas las regiones, incluidos los glifos necesarios para el chino, creo que encontrará que agrega considerablemente más de 500K ... más como 2-5MB en mi experiencia. Pero tal vez hay algunos detalles que me faltan. De todos modos, para que el contenido se entregue a través de la web, generalmente supongo que, como mínimo, las fuentes asiáticas deben ser fuentes de dispositivo.

Para agregar una palabra sobre una solución mixta, he hecho esto y es factible. Es decir, suponiendo que puede agregar la lógica a su SWF, podría (por ejemplo) hacer dos de cada campo de texto, uno usando & Quot; Lucida lo que sea & Quot; y el otro usando " _sans " ;, y luego en tiempo de ejecución, haga que uno de ellos sea invisible y coloque texto en el otro, dependiendo de la región que esté mostrando. (Lo hice creando un solo componente LocalizedTextfield y haciéndolo leer la configuración regional de una propiedad estática cuando se inicializó). Luego, simplemente tiene que decidir, para cada configuración regional, si vale la pena mostrar el tamaño del archivo para ese conjunto en particular de glifos.

La última palabra es que no necesariamente puede suponer que el tamaño de archivo incurrido por sus fuentes solo se cargará una vez. Si hace que su contenido sea sencillo e incruste fuentes en sus campos de texto, la información de la fuente será parte de su SWF y, por lo tanto, se cargará cada vez que pase lo que pase. Para externalizarlo, puede hacer que el componente Label sea un archivo separado, y luego la decisión de cargarlo o no depende de la configuración de almacenamiento en caché del navegador. También puede externalizar el recurso de fuente en sí mismo y usarlo como un recurso compartido, pero en AS2 es un poco complicado comenzar a trabajar. Escuché que es más fácil en AS3 pero no lo hice yo mismo.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top