Ver la versión completa : TextReader 0.1
Wild[Kyo]
04/03/2006, 19:53
hermes PS2R, creador de GP2Xengine y GP2Xpectrum, ha lanzado un lector de archivos txt para GP2X.
Las características de la aplicación:
Version v0.1 creada en menos de 24H (asi que perdonad los posibles bugs )
Máximo 512 entradas por directorio.
Máximo de 65536 páginas de 40x14 carácteres por fichero (Mas de 36 Millones de carácteres )
Ajuste de frecuencia automático (200Mhz cuando carga el
fichero, 66 Mhz en el lector y selector de ficheros)
Detección automatica de ficheros en formato UNICODE
(obviamente, solo soporta el set español)
Juego de caracteres ANSI en español.
Código fuente, disponible en el futuro, que todavia le quiero poner algunas cosillas de mi cosecha
Recordad de pasaros por el hilo para comentarle posibles bugs, sugerencias o agradecimientos además de leer más información sobre la utilización de la aplicación.
Descarga: TextReader 0.1 (23.1 KB) (http://www.gp32spain.com/foros/downloads.php?do=file&id=494)
Hilo: [Utilidad] TextReader: Mi lector de textos (http://www.gp32spain.com/foros/showthread.php?t=28847)
hermes PS2R
05/03/2006, 01:29
Wenas,
Ya está subida la version 0.2B. Mas info en el mismo hilo ;)
joer!!! la verdad es que hacia falta un lector de textos ya y si esta hecho por hermes la calidad esta asegurada :P
lastima que aun no tenga una gp2x para probarlo, en la gp32 ya habia lectores de texto decentillos...aunke lo del pdf nunca se logró..
un saludo y gracias por tu esfuerzo, tqan solo en un dia!!
Te he dicho cuanto me molas?
No, en serio, me molas, tienes novia?
:)
hermes PS2R
05/03/2006, 05:46
jejeje, si llego a saber que estabais tan necesitados de un lector de txt me hubiera puesto antes!
Bueno he procurado poner las opciones justas para un uso cómodo, evitando al maximo el cansancio visual (por eso hago que el scroll sea de pantalla en pantalla, por ejemplo)
La opción de salto de marca ( lo de meter en un txt) creo que es una buena idea, no solo te permite saltar por capítulos si no que si estas leyendo algún tipo de apuntes, te permite localizarlos de forma rápida.
Cuando termine de leer la novela que estoy leyendo, a ver si miro la posibilidad de meter otros tipos de letra (hubo un menda que se curró una utilidad para capturar fuentes de letra y sacarlas en el formato que yo usaba en el PS2Reality Mediaplayer). De esa forma podría compatibilizar la utilidad con otros idiomas ;) (o poner un tipo de letra diferente)
jejeje, si llego a saber que estabais tan necesitados de un lector de txt me hubiera puesto antes!
Bueno he procurado poner las opciones justas para un uso cómodo, evitando al maximo el cansancio visual (por eso hago que el scroll sea de pantalla en pantalla, por ejemplo)
La opción de salto de marca ( lo de meter en un txt) creo que es una buena idea, no solo te permite saltar por capítulos si no que si estas leyendo algún tipo de apuntes, te permite localizarlos de forma rápida.
Cuando termine de leer la novela que estoy leyendo, a ver si miro la posibilidad de meter otros tipos de letra (hubo un menda que se curró una utilidad para capturar fuentes de letra y sacarlas en el formato que yo usaba en el PS2Reality Mediaplayer). De esa forma podría compatibilizar la utilidad con otros idiomas ;) (o poner un tipo de letra diferente)¡Tiene muy buena pinta! Un par de sugerencias que se me ocurren: Soporte para textos comprimidos (uno o varios txt dentro de un zip, bz2, o similar) Es algo que tiene el lector que usaba en la GP32 y se nota mucho el ahorro de espacio si son textos largos.
¿No sería interesante utilizar algo más asociado a un "estándar" para las marcas de capítulo, cambios de color, etc. en vez de inventar una convención nueva? Estaba pensando, por ejemplo, en elementos de html (anchors (http://www.w3.org/TR/1998/REC-html40-19980424/struct/links.html#h-12.2.3), colores (http://www.w3.org/TR/1998/REC-html40-19980424/types.html#h-6.5), etc.) , o comandos de RTF, o algo similar. Lo comento pensando en poder convertir de otros formatos (PDF, SXW, DOC, HTML...) en el futuro.
Por último, y para que acabes harto de peticiones ;), barriendo para casa, ¿costaría mucho añadir soporte para español (además de Win/Linux y UTF-16) en UTF-8 y Mac Roman? Así no tendría que convertir la mayoría de textos que tengo :D
Pero sobre todo, gracias por este programa,
kounch
Nota final: Acabo de observar que el selector de archivos que tiene no muestra bien los nombres de directorio o archivo con acentos, eñes, etc. Cambiarlo para que lo haga bien no debería costar mucho, ya que (imagino que lo harás en C estándar) el sistema te devuelve los datos en UTF-8 y es fácil de convertir a otra codificación como ISO-8859-1 o ISO-8859-15. Es algo que tengo implementado en las últimas versiones del selector y por eso me suena la situación (yo lo hago usando iconv) .
< - >
Por último, y para que acabes harto de peticionesY dos más: Varios tamaños (que no tipos) de letra
Desplazamiento línea a línea, además de página a página, por ejemplo, usando el stick
¿Fuentes con "subpixel rendering" como se comenta en otros sitios del foro? Creo que había alguien dispuesto a generarlas si hacía falta.
hermes PS2R
05/03/2006, 17:00
Mi querido kounch, creo que a estas alturas, ya deberías haber entendido que yo soy un programador bastante alejado de los patrones 'normales' de la scene y tengo una forma de pensar muy particular, que me hace seguir mi propio camino, evitando seguir caminos que realmente, no conducen nada (en mi opinión)
¡Tiene muy buena pinta! Un par de sugerencias que se me ocurren: Soporte para textos comprimidos (uno o varios txt dentro de un zip, bz2, o similar) Es algo que tiene el lector que usaba en la GP32 y se nota mucho el ahorro de espacio si son textos largos.
Si, como comprenderás, es algo que yo tambien había pensado añadir ¿por que no lo he hecho ya? Pues hombre, porque todo esto está bajo licencia GPL o similares y de momento prefiero centrarme en la parte del código que me pertenece, tampoco es que haya tenido mucho tiempo para implementarlo :D
¿No sería interesante utilizar algo más asociado a un "estándar" para las marcas de capítulo, cambios de color, etc. en vez de inventar una convención nueva? Estaba pensando, por ejemplo, en elementos de html
Una de las cosas por las que me gusta programar, es porque puedo elegir mi propio camino, explorar cosas nuevas y experimetar con nuevas ideas.
Poner una marca de capitulo o remarcar con un color, realmente, no se aleja mucho del estandar que utilizamos en este mismo foro.
Poner una linea de texto en color Azul, usa el mismo comando que este foro para escribir en negrita, porque al fin y al cabo, es exactamente el uso que le quiero dar.
La marca de capítulo la pongo así porque entiendo que en un editor de texto normal, no desentonaría demasiado esa marca, es facil de recordar y facil de introducir a mano (recuerda que esto soporta TXT solo y por tanto, necesita de cierta manipulación en los textos).
Por supuesto: evito DELIBERADAMENTE el html.
(anchors (http://www.w3.org/TR/1998/REC-html40-19980424/struct/links.html#h-12.2.3), colores (http://www.w3.org/TR/1998/REC-html40-19980424/types.html#h-6.5), etc.) , o comandos de RTF, o algo similar. Lo comento pensando en poder convertir de otros formatos (PDF, SXW, DOC, HTML...) en el futuro.
¿ves? yo nunca cometería ese ERROR: no me interesa PDF, ni HTML, ni el resto de formatos en una pantalla de 320x240
¿por que? Bueno, independientemente del uso personal que le diera.... lo cierto es que necesitas incluir una serie de fuentes procedentes de complejos programas, que cuesta mucho tiempo de adaptar y luego ¿para que? ¿para ver una ventana distorsionada porque NO CABE la imagen en pantalla? ¿para ir desplazando una ventana por un area de pantalla virtual e ir leyendo porciones de texto y viendo porciones de fotografias? :loco:
Además serían necesarias varias fuentes true type y eso por sí solo, ya es desaconsejable.
El uso que yo le daría es nulo y creo que muy poca gente encontraría util eso.
Por último, y para que acabes harto de peticiones ;), barriendo para casa, ¿costaría mucho añadir soporte para español (además de Win/Linux y UTF-16) en UTF-8 y Mac Roman? Así no tendría que convertir la mayoría de textos que tengo :D
El programa es capaz de leer texto plano tratando de forma automatica texto unicode (no tiene mucho truco, pues unicode antepone un \0 al código de caracter) y el tratamiento que le he dado, hace que trabaje automaticamente con textos que usen LF+CR, CR o LF como salto de linea.
Así que supongo que el problema que tu tendras es para con los simbolos.
El programa utiliza un formato BITMAP de letras, que contiene los
simbolos desde el 32 al 255 inclusive. Dicho bitmap utiliza color de 1 bit y unas dimensiones de 16x16 pixeles.
Se podría decir que un caracter se compone de 16 WORDs (16 bits)
donde el bit mas significativo (el 15) es el pixel de la izquierda y el menos significativo el de la derecha.
El editor de texto debido a que la pantalla es de solo 320 pixeles, convierte esa fuente a 8x16 (de otra forma resultaría un texto poco legible)
Nota final: Acabo de observar que el selector de archivos que tiene no muestra bien los nombres de directorio o archivo con acentos, eñes, etc.
Eso es debido a que el programa utiliza DOS fuentes de letra: una de 8x8 que no contiene los códigos apropiados (es la misma letra que empleo en todos mis proyectos de GP2X), Se puede solucionar utilizando la fuente de letra de los textos.
Y dos más: Varios tamaños (que no tipos) de letra
Desplazamiento línea a línea, además de página a página, por ejemplo, usando el stick
¿Fuentes con "subpixel rendering" como se comenta en otros sitios del foro? Creo que había alguien dispuesto a generarlas si hacía falta.
Ufff, como se nota la diferencia entre quien sugiere y quien se enfrenta con los problemas :D
¿varios tamaños de letra? Veamos, como te digo arriba, el programa tiene una fuente de letra de 16x16 que tengo que reducir a 8x16 para que el texto sea legible (pues presentar 20x14 caracteres que es lo que cabe en la pantalla de 320x240 , es MUY poco). Lo minimo que se debería presentar son 40 caracteres, lo que da un tamaño de 8x16 de letra (la que uso)
Así pues, utilizar una letra mayor, solo tendria sentido en los títulos y cosas así ¿para que hacemos eso? para destacarlos del resto ¿no? pues para eso tenemos los comandos de color y no hay que complicar el asunto tanto :p
Hacer que el programa admita diferentes tamaño de letra no va a ayudar a la legibilidad y si a la complejidad del programa y que necesite más CPU para trabajar.
¿subpixel rendering? Esa si que es buena: veamos, el programa utiliza un metodo de subpixel rendering, aunque tu no lo aprecies ;)
Digamos que tengo una fuente de letra de 16x16 que se visualiza en un area de 8x16. El truco consiste en que solo escribo los pixeles a '1' y tomo los pixeles de dos en dos y si alguno está a 1, lo escribo.
Si te refieres a que haga un 'difuminado' de color, lo unico que iba a conseguir así es que las letras se vieran BORROSAS. Eso solo funciona bien cuando se trata de crear una fuente de letra mayor partiendo de una letra menor (y el tamaño de pantalla de GP2X es demasiado estrecho para hacer eso viable).
Sobre avanzar linea a linea, se puede implementar. Al principio el programa utilizaba ese método pero lo cambíe cuando modifiqué el indexado para que trabajara con un total de 65536 paginas en vez de 65536 lineas. Sin embargo no es dificil implementar eso y puede resultar util cuando la division de paginas que hace el programa, no resulte cómoda.
NOTA:
La idea de este proyecto es de hacer un lector de texto sencillo, no crear una utilidad que abra formatos mas complejos que requieran de fuentes externas que no se pueden incluir (caso de las fuentes de Windows) o que tengan un tratamiento lento, se visualicen mal en la pantalla o que la pantalla solo visualice una porción del texto. Eso es tarea de otros (si ellos quieren), aunque por mi parte, eso tiene baja utilidad (reitero lo de la pantalla)
Por ejemplo, en PSP si se puede trabajar el texto de una forma mejor, ya que su pantalla de 16:9, permite meter muchos mas caracteres por línea, pero en una pantalla de 320 puntos de ancho... je, menuda pérdida de tiempo si lo que quieres es leer una novela de una forma cómoda, sin dejarte los ojos o que te duela la cabeza por que tienes que desplazar la pantalla a cada palabra :rolleyes:
caesaris
05/03/2006, 18:06
Estupendo el lector , como casi todos los proyectos que haces Hermes , sencillo por su funcionamiento no por su complejidad en implementarlo , y comodo de usar.
Sin que sea tomado como una exigencia , algo que a mi personalmente me gustaba mucho del lector del Windups de la GP32 era el diccionario de inglés , ¿sería muy dificil añadirlo al lector? .
Muchas gracias Hermes por este y todos tus trabajos anteriores , de lo mejor para la GP2X.
La idea de este proyecto es de hacer un lector de texto sencillo, no crear una utilidad que abra formatos mas complejos que requieran de fuentes externas que no se pueden incluir (caso de las fuentes de Windows) o que tengan un tratamiento lento, se visualicen mal en la pantalla o que la pantalla solo visualice una porción del texto. Eso es tarea de otros (si ellos quieren), aunque por mi parte, eso tiene baja utilidad (reitero lo de la pantalla)Mi querido Hermes
igual no me he explicado bien, trataré de resumir mejor lo que a mí me gustaría poder hacer con un lector de texto sencillo de forma resumida: Que se lea bien,por eso varios tamaños (lo del subpixel rendering es opcional, pero muy útil para ver textos pequeños en LCD o TFT, hay otro post en el foro donde lo explica mejor alguien que sabe del tema).
Si soporta marcas u otros cambios en el texto, que utilice algo ya existente, para, así podre yo convertir de otros formatos (HTML, PDF,RTF, DOC, SWX...) a texto plano con las marcas correspondientes, sin tener que hacerme mi propio conversor. Si hay que hacerlo se hace, pero da algo de pereza.
Economía de espacio en la SD (esto para cualquier programa), por eso hablaba de la compresión.
A parte de ello, sobre UTF-8 UTF-16, etc. lo que he hecho es usar la batería sencilla de textos (básicamente áéíóúÁÉÍÓÚüïÜÏñÑçÇ) que utilizo cada vez que GPH actualiza su lector. Como en estos hilos de noticias no se puede adjuntar archivos, te dejo aquí (http://80.35.206.140/Textos.zip) un zip con los distintos textos. Como verás, el soporte es UTF-16, pero no UTF-8.
De nuevo, gracias por el programa, es realmente muy útil con lo que ya tiene
kounch
hermes PS2R
05/03/2006, 20:13
Mi querido Hermes
igual no me he explicado bien, trataré de resumir mejor lo que a mí me gustaría poder hacer con un lector de texto sencillo de forma resumida: Que se lea bien,por eso varios tamaños (lo del subpixel rendering es opcional, pero muy útil para ver textos pequeños en LCD o TFT, hay otro post en el foro donde lo explica mejor alguien que sabe del tema).
Si soporta marcas u otros cambios en el texto, que utilice algo ya existente, para, así podre yo convertir de otros formatos (HTML, PDF,RTF, DOC, SWX...) a texto plano con las marcas correspondientes, sin tener que hacerme mi propio conversor. Si hay que hacerlo se hace, pero da algo de pereza.
Economía de espacio en la SD (esto para cualquier programa), por eso hablaba de la compresión.
A parte de ello, sobre UTF-8 UTF-16, etc. lo que he hecho es usar la batería sencilla de textos (básicamente áéíóúÁÉÍÓÚüïÜÏñÑçÇ) que utilizo cada vez que GPH actualiza su lector. Como en estos hilos de noticias no se puede adjuntar archivos, te dejo aquí (http://80.35.206.140/Textos.zip) un zip con los distintos textos. Como verás, el soporte es UTF-16, pero no UTF-8.
De nuevo, gracias por el programa, es realmente muy útil con lo que ya tiene
kounch
Bueno, ya tengo implementado el poder moverse linea a linea y he adaptado el salto de página y de marca para quer funcionen como debe de ser. creo que os gustará bastante :)
Lo de la compresión ya te lo he dicho: queda pendiente, es una de las mejoras que pienso incluir.
Lo de los formatos, es algo mas complicado de lo que parece: podria hacerse que el programa entendiera una serie de marcas procedente de un html e hiciera la traducción a su formato propio, que duda cabe, pero un html es en realidad, un archivo MUY MUY complejo, ya que cotiene multitud de comandos, se relaciona con diversos lenguajes de programacion, dispositivos multimedia, tiene texto, imagenes... en fin, que cuesta mucho menos hacr la exportacion desde otro programa.
Otro problema a resolver es que las pagina html se diseñan para una determinada resolución. En realidad, todos los formatos de texto modernos tratan de crear archivos que luegon pueden ser imprimidos en papel y se adaptan a un determinado formato que
es muy dificil de representar en una pantalla de 320x240.
Por ejemplo, imaginate un fichero word que usa varias fuentes true type, de diversos tamaños, colores, justificaciones de texto, pensado para imprimirse en un formato A4 ¿que pasaría si trato de visualizar eso en nuestra pequeña pantalla? Que no se puede o tengo que recurrir al truco de la ventanita.
Sobre lo de utf8, ese formato es un poco tramposo ;). Estoy viendo que trabaja con caracteres de 8 bit, pero que utiliza un caracter especial (0xC3) para formar códigos de caracter que ocupan 16 bits. Si sólo usa ese caracter, me será relativamente facil adaptarlo, al menos, con los símbolos esepciales de los ejemplos que me has mandado
utf16 es UNICODE tal y como yo lo conozco: antepone 0x00 a todo carácter de los que nosotros utilizamos.
< - >
Bueno kounch, ya tengo implementado soporte automatico para codificación UTF-8, aparte de filtrar los codigos del inicio del documento, donde se especifica el formato, etc.
Donde no te puedo ayudar (de momento) es con la codificación del MAC, pues necesitaría conocer la relación entre todos los caracteres especiales, de windows y de mac.
Por supuesto, es posible hacerlo comparando, así que si no supone mucha molestia para tí, cuelgame dos ficheros uno con la codificacion bajo windows y otro con la de mac, de todos los caracteres que quieras que represente para que la cosa quede lo mejor posible. Supongo que podría poner una opción en el programa para diferenciar entre MAC y Windows ;)
Hola otra vez
lo primero ¡muchas gracias por tomarte las molestias de ir añadiendo cositas!
[/QUOTE]
Bueno, ya tengo implementado el poder moverse linea a linea y he adaptado el salto de página y de marca para quer funcionen como debe de ser. creo que os gustará bastante :)Sí sí sñi :)
Lo de los formatos, es algo mas complicado de lo que parece: podria hacerse que el programa entendiera una serie de marcas procedente de un html e hiciera la traducción a su formato propio, que duda cabe, pero un html es en realidad, un archivo MUY MUY complejo(...)Esta claro que hoy no es mi día explicándome. Lo que yo tenía en la cabeza (no me hagas caso si desbarro demasiado), sería lo siguiente. HTML utiliza etiquetas del tipo
<algo> </algo> para indicar toda la implementación. La opción sería ignorar todas las etiquetas que no se soporten, y no mostrarlas en pantalla. De esa manera, por ejemplo, si se encuentra una etiqueta
<a id="lo que sea" > se cambiaría por la marca de capítulo, mientras que una tel tipo
<div> simplemente no se vería. Ya te digo que es un desbarre, y creo que ya empiezo de todas maneras a tener en la cabeza como hacerme un conversor ;), así que al final igual me animo
Donde no te puedo ayudar (de momento) es con la codificación del MAC, pues necesitaría conocer la relación entre todos los caracteres especiales, de windows y de mac.
Por supuesto, es posible hacerlo comparando, así que si no supone mucha molestia para tí, cuelgame dos ficheros uno con la codificacion bajo windows y otro con la de mac, de todos los caracteres que quieras que represente para que la cosa quede lo mejor posible. Supongo que podría poner una opción en el programa para diferenciar entre MAC y Windows ;)¿Qué tal te viene una tabla como esta (http://en.wikipedia.org/wiki/Mac-roman)? Aún así, ¿no te sería más facil utilizar iconv() (http://www.gnu.org/software/libiconv/documentation/libiconv/iconv.3.html), que viene de serie en el linux de la GP2X? Yo lo utilizo en el código del nuevo selector para pasar de UTF a ISO-8859-1 y es bastante sencillo.
hermes PS2R
05/03/2006, 23:11
Lo del conversor de formatos, te lo dejo para ti :D
La funcion iconv() no la conocía. Parece bastante util, pero tambien hay que tener en cuenta otros detalles de representación.
Como ahora está funciona bastante bien el programa: no creo que de muchos problemas, pero ahora mismo estoy ultimando lo que será la versión 1.0, posiblemente, la última por mi parte y eso significa que vais a tener el código fuente en breve.
Le he puesto soporte de ficheros .txt comprimidos en formato .zip.
Al igual que en GP2Xpectrum, busca el primer fichero que tenga extension .txt o .TXT dentro del fichero .zip
Me apetece descansar un rato (y terminar la novela [wei5]) así que mañana subo el nuevo binario y los fuentes ;)
< - >
Por cierto kounch ¿no sería mas logico editar el fichero .htm .doc o lo que sea, ir al capitulo correspondiente y poner delante antes de convertir?
Lo mismo se puede hacer con los de color.
Después la cosa puede ser tan sencilla como un copy & paste del texto y salvarlo como .txt
< - >
Bueno, pues al final me he animado y lo he empaquetado todo y ya está subida la version 1.0, junto con el código fuente, en el hilo correspondiente. Digamos que Límite 48 Horas para crear la aplicación es un buen cierre :brindis:
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.