mostrar con say todos los caracteres

SplinterGU · February 11, 2013, 01:09:23 AM

es imposible que puedas escribir el € en formato cp437 ni iso8859-1...

no se como es que haces un write y te sale eso

master · February 11, 2013, 01:21:30 AM

me aparece lo mismo que a splinter si mi PRG tiene codificación utf-8 (adjunto 1).
Si uso la codificación CP1252 me aparece el adjunto 2
Supongo que es como tienes el charset de tu codigo PRG, y bennu busca el caracter en tu fuente fnt que tiene otro charset (que por coincidencia es el mismo).

DCelso · February 12, 2013, 07:03:45 PM

No hay nada como leer el código para saber qué hace algo.
libtext.c línea 695, de gr_text_put

Code Select


    switch ( f->charset ) 
        { 
            case CHARSET_ISO8859: 
                current_char = dos_to_win[*text]; 
                break; 
 
            case CHARSET_CP850: 
                current_char = *text; 
                break; 
 
            default: 
                current_char = 0; 
                break; 
        }

así es que mola mazo pero la verdad está aqui

NOTA: hay que decir que bennu (o el que hizo fenix) llama a cp850 (charset msdos) y a iso8859 (charset de windows)

*Si la fuente tiene activado el charset cp850, obtiene el índice que le pasaste a pelo, (es decir, pasa olímpicamente de convertir nada, lo que quiere decir que usará e índice de carácter con el que has codificado el fichero .prg)
Aquí está el truco de porqué el fnt que hay dentro de bennu por defecto pinta el cp437 tan perfectamente, y aparentemente las fuentes de master con cp437 simuladas en cp850 le van correctamente. Por tanto, si el fnx tiene puesto que es un charset cp850 quiere decir que descartará hacer alguna conversion y usará el charset con el que estuviera hecho el .prg para obtener el índice para buscar la imagen en el fnx. (dentro de la limitación de 8 bits por caracter, esto explica el por qué a splinter le pinta dos caracteres el €, su codifcacion es utf8, que usa dos bytes para identificar al euro, por lo que pasa dos chars al fnt de bennu y pinta dos chars correspondientes a los dos bytes :D )
También explica el por qué a mi me pintaba bien el euro :D

*Si la fuente tiene activado el charset iso8859 (aquí no diferencia entre el _1 y el _15, supongo que no existían antes dos o que es uno más genérico de estos) entonces hace una conversión curiosa dos_to_win, que lo que hace es convertir un índice cp850 en iso8859.

En xctype.c podemos ver las tablas de conversion ente cp850 e iso8859, y vivceversa

Code Select


unsigned char dos_to_win[256] = { 
  0,   1,   2,   3,   4,   5,   6,   7,   8,   9,  10,  11,  12,  13,  14,  15, 
 16,  17,  18,  19,  20,  21,  22,  23,  24,  25,  26,  27,  28,  29,  30,  31, 
 32,  33,  34,  35,  36,  37,  38,  39,  40,  41,  42,  43,  44,  45,  46,  47, 
 48,  49,  50,  51,  52,  53,  54,  55,  56,  57,  58,  59,  60,  61,  62,  63, 
 64,  65,  66,  67,  68,  69,  70,  71,  72,  73,  74,  75,  76,  77,  78,  79, 
 80,  81,  82,  83,  84,  85,  86,  87,  88,  89,  90,  91,  92,  93,  94,  95, 
 96,  97,  98,  99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 
112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 
199, 252, 233, 226, 228, 224, 229, 231, 234, 235, 232, 239, 238, 236, 196, 197, 
201, 230, 198, 244, 246, 242, 251, 249, 255, 214, 220, 248, 163, 216, 215, 131, 
225, 237, 243, 250, 241, 209, 170, 186, 191, 174, 172, 189, 188, 161, 171, 187, 
166, 166, 166, 166, 166, 193, 194, 192, 169, 166, 166,  43,  43, 162, 165,  43, 
 43,  45,  45,  43,  45,  43, 227, 195,  43,  43,  45,  45, 166,  45,  43, 164, 
240, 208, 202, 203, 200, 105, 205, 206, 207,  43,  43, 166,  95, 166, 204, 175, 
211, 223, 212, 210, 245, 213, 181, 254, 222, 218, 219, 217, 253, 221, 175, 180, 
173, 177,  61, 190, 182, 167, 247, 184, 176, 168, 183, 185, 179, 178, 166, 160 
} ; 
 
/* Tabla de conversión de caracteres Windows a MS-DOS */ 
 
unsigned char win_to_dos[256] = 
{ 
   0,   1,   2,   3,   4,   5,   6,   7,   8,   9,  10,  11,  12,  13,  14,  15, 
  16,  17,  18,  19,  20,  21,  22,  23,  24,  25,  26,  27,  28,  29,  30,  31, 
  32,  33,  34,  35,  36,  37,  38,  39,  40,  41,  42,  43,  44,  45,  46,  47, 
  48,  49,  50,  51,  52,  53,  54,  55,  56,  57,  58,  59,  60,  61,  62,  63, 
  64,  65,  66,  67,  68,  69,  70,  71,  72,  73,  74,  75,  76,  77,  78,  79, 
  80,  81,  82,  83,  84,  85,  86,  87,  88,  89,  90,  91,  92,  93,  94,  95, 
  96,  97,  98,  99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 
 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 
 128, 129, 130, 159, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 
 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 
 255, 173, 189, 156, 207, 190, 254, 245, 249, 184, 166, 174, 170, 240, 169, 238, 
 248, 241, 253, 252, 239, 230, 244, 250, 247, 251, 167, 175, 172, 171, 243, 168, 
 183, 181, 182, 199, 142, 143, 146, 128, 212, 144, 210, 211, 222, 214, 215, 216, 
 209, 165, 227, 224, 226, 229, 153, 158, 157, 235, 233, 234, 154, 237, 232, 225, 
 133, 160, 131, 198, 132, 134, 145, 135, 138, 130, 136, 137, 141, 161, 140, 139, 
 208, 164, 149, 162, 147, 228, 148, 246, 155, 151, 163, 150, 129, 236, 231, 152 
} ;

Así que como conclusión, podemos sacar que actualmente como está el sistema, simular cualquier charencoding con codificación cp850 en los fnx, te permite usar esa codificación en tu .prg y así hacer coincidir lo que escribes en los textos con lo que representará tu fnx simulado.

Y activar el iso8859 en fnx solo funciona si codificas tu fichero en cp850 tu .prg, en cualquier otro caso lo que hace es liarla parda :D, porque bennu se cree que está codificado en cp850 y aplica la tabla de transformación de arriba cruzando aún más lo que esperas obtener con lo que realmente obtienes de tu fuente :D. Como los primero 127 caracteres suelen ser muy similares o iguales en todas las codifiaciones (son los realmetne llamados ASCII) nunca habíamos detectado este problema :D.

Soluciones a este lío.

* La más directa es no llamar nunca mas a los fnx con codificación cp850 así, sino llamarlos fnx con codificación directa ( es decir, igual a la codificación del .prg del que viene :D ). Y nunca más usar codificaciones iso8859, porque pueden liar los resultados al aplicar una tabla de transformación fija de cp850 a iso8859

* la mejor solución sería hacer que libtext.c detectara de alguna forma la codificación del .prg y la convirtiera en una codifiación universal (osea válida para cualquier signo, tipo unicode o utf8) para luego buscar en el fnx la codifiación que usa (actualmente solo soporta 2) y convertirla de la universal a la del fnx y así poder encontrar el índice correcto en el fnx.
Esto haría transparente al usuario el charset que empleara en el .prg y sabría que su programa usaría el charset que tuviera el fnx

*Una solución de compromiso, y rapida de adaptar a lo actual, podría ser que al write se le pudiera pasar un parámetro más indicando el charset del .prg ( de algunos posibles) y que en base a éste, a una tabla de transformación y al charset que leyera en el fnx (recordemos que son 2) sacara el índice adecuado para buscar en el fnx.

SplinterGU · February 12, 2013, 07:12:17 PM

ya lo he dicho que bennugd/fenix convierte segun el tipo de codificacion... por otro lado, tienes el parametro en el compilador para indicar cuando trabajas con "formato dos", solo DOS

-c File uses the MS-DOS character set

a mi me parece que como primera medida hay que cambiar las constantes y nombres en los fuentes CP_850 por CP_437... correcto?

SplinterGU · February 12, 2013, 07:15:32 PM

igualmente sigo no entendiendo como puedes pintar bien el €, que codificacion tienes? yo he intentando con el sublimetext y siempre que intento guardar el archivo, me dice que hay caracteres que no pueden ser salvados en un archivo cp850, ni cp437, solo en utf8.

podrias dar mas detalles?

edit: por demas esta decir que el simbolo € no esta en el font del sistema.

DCelso · February 12, 2013, 07:24:00 PM

actualmente la constante CP850 en bennu hace que no transforme nada, deja el valor que le llega, así que podríamos decir que es algo como default_charset o parent_charset, mas que cp850

El problematico es iso8859 que actualmente mete una tabla de transformación fija (aqui ya no se si de cp850-a iso8859 o de cp437 a iso8859 (como creemos que podria suceder)), luego te digo que tabla de transformación exactamente es, tengo un programilla en lazarus que nos podría servir.

lo del euro, en el otro hilo te expliqué mi fallo. Codificaba 8859_15 y engañaba al fnx diciendo que era cp850

lo de el -c, habrá que estudiar que hace, porque si convierte la entrada a cp850, empeora las cosas, que haría con esos caracteres raros ?, si lo que hace es convertirlo a iso8859_15 podría valer para algo ( al menos para nosotros los latinos :D )

SplinterGU · February 12, 2013, 08:43:17 PM

en realidad, no...

cp_850 (cp_437 en realidad) es lo que bennugd toma como base... y hace conversion de 850 a iso8859 (supongo que iso8859-1) y tambien es la base para dibujar el font del sistema... o sea, no es directo, es que el sistema trabaja en cp850, entonces, obviamente no tiene que hacer conversiones... que tu hagas un fake para pasar un font sin conversion diciendole que es cp850, eso es otra cosa.

NOTA: cuando digo cp850 quiero decir cp437, pero como todo esta nominado cp850, hablamos de eso.

una de las cuestiones es ver que iso8859 es el de la tabla de conversiones y si dicha tabla es cp437<->iso8859-X o es cp850<->iso8859-X.

luego quedaria darle soporte a otros, aunque si armas un "cp850" fake con tus caracteres especiales, ya no tienes problemas para dibujar los fonts que necesites.

DCelso · February 12, 2013, 10:30:37 PM

Siento disentir. Esto convencido, y casi podría afirmar que bennugd no trabaja con cp437 (ni con ninguna codificación específica), simplemente que el fnt por defecto interno que trae está con esos caracteres.

He probado que si codificas un archivo en iso8859_15 y creas un fnx con los caracteres iso8859_15 (y le pones en la cabecera charset =1) funciona de maravilla. Y casi puedo afirmar a ciencia cierta que pasará lo mismo con cualquier otro charset de 8 bits (de longitud fija) con el que hagas las pruebas. Está claro que si usas utf8 (longitud dinámica, posibilitando mas de 256 caracteres) no funcionará porque fnx no tiene soporte para mas de 256 caracteres ni longitud dinámica.

He extraído las tablas de conversión y veo que son conversoras entre cp850 e iso8859_1, pero están muy curradas, porque para los casos en los que no hay conversión directa se ha buscado el caracter más parecido o uno que de la pega como sustituto :D, que tío más bueno el que lo hizo :D.

DCelso · February 12, 2013, 10:33:27 PM

Este es el programilla con las tablas metidas ya.
http://code.google.com/p/fpg-editor/downloads/detail?name=project1.7z&can=2&q=

DCelso · February 12, 2013, 10:38:07 PM

Como conclusión, yo dejaría bennu tal cual.

Va perfecto para trabajar con cualquier charencoding de 8 bits, ( y es lo que más usamos con windows ;) ).

Solo hay que tener en cuenta esto: crear tu .prg con un charset de (8bits) y crear tu fnx con el mismo charset poniendo en su cabecera como valor de charset un 1. (que es el valor que bennu usa para no aplicar tabla de transformación)

SplinterGU · February 13, 2013, 01:39:53 AM

Quote from: DCelso on February 12, 2013, 10:30:37 PM
Siento disentir. Esto convencido, y casi podría afirmar que bennugd no trabaja con cp437 (ni con ninguna codificación específica), simplemente que el fnt por defecto interno que trae está con esos caracteres.

He probado que si codificas un archivo en iso8859_15 y creas un fnx con los caracteres iso8859_15 (y le pones en la cabecera charset =1) funciona de maravilla. Y casi puedo afirmar a ciencia cierta que pasará lo mismo con cualquier otro charset de 8 bits (de longitud fija) con el que hagas las pruebas. Está claro que si usas utf8 (longitud dinámica, posibilitando mas de 256 caracteres) no funcionará porque fnx no tiene soporte para mas de 256 caracteres ni longitud dinámica.

He extraído las tablas de conversión y veo que son conversoras entre cp850 e iso8859_1, pero están muy curradas, porque para los casos en los que no hay conversión directa se ha buscado el caracter más parecido o uno que de la pega como sustituto :D, que tío más bueno el que lo hizo :D.

es un chiste? charset 1 sabes bien que no hace conversion... yo creo que entiendes lo que pasa, por favor, no me hagas explicar algo que ya sabes...

bennugd trabaja con una base, esa base es la definida en el font del sistema, tienes que tener codificacion de tus prg con esa misma codificacion...

ahora si quieres aprovechar esto, para usar cualquier encoding, puedes usar el enconding 1 que es el que hace 1 a 1 y usas cualquier encoding mientras tenga coherencia con tu prg y todos los caracteres sean de 8bits...

el problema que tenemos aca, es que si bien la tabla es correcta conversion cp850 a iso8859-1 (no es ni *-15 ni ningun otro, es *-1!) el font del sistema es cp437... y algo de los 2 hay que corregir.

SplinterGU · February 13, 2013, 01:55:57 AM

edit: tambien veo que el font del sistema necesitaria una retocada... algunos caracteres estan muy empastados cuando hay lugar para dejarlos bien, ademas de los que son para hacer dibujos no se unen... no se si es el espaciado o el font.

edit2: maldito espaciado, si lo quito los fonts de letras quedan pegados.

DCelso · February 13, 2013, 06:58:59 AM

:o. Tienes mucha razón en todo. Ya se que no está programado así a posta. Pero el efecto colateral nos sirve para poder usar cualquier codificación. Y eso mola ;D

en cuanto a lo del espaciado. Se lo quitaste a todas las font? O sólo a la del sistema.
Eso de unir chars serviría para simular aplicaciones de msdos ;)

SplinterGU · February 13, 2013, 12:16:42 PM

no quite el espaciado entre caracteres porque va a dar problemas con la parte ASCII, tendria que rehacer el font... ya veremos... eso del espaciado creo que yo cometi el error en fenix... la verdad que no recuerdo, si recuerdo que antes iban desparejas las funciones write y las funciones para saber el ancho de un texto.

en fin, nuevo item en la lista de pendientes... :(

DCelso · February 13, 2013, 01:31:50 PM

Quote from: SplinterGU on February 13, 2013, 12:16:42 PM
no quite el espaciado entre caracteres porque va a dar problemas con la parte ASCII, tendria que rehacer el font... ya veremos... eso del espaciado creo que yo cometi el error en fenix... la verdad que no recuerdo, si recuerdo que antes iban desparejas las funciones write y las funciones para saber el ancho de un texto.

en fin, nuevo item en la lista de pendientes... :(

Ah, Oh, bueno, no importa, actualmente va bastante bien para lo que necesitamos. :D.