• No se han encontrado resultados

TRABAJO PRACTICO Nº 1 Compilador de textos en imágenes

N/A
N/A
Protected

Academic year: 2021

Share "TRABAJO PRACTICO Nº 1 Compilador de textos en imágenes"

Copied!
7
0
0

Texto completo

(1)

TRABAJO PRACTICO Nº 1 – Compilador de textos en imágenes

1) Objetivo del T.P. :

El objetivo del presente trabajo consiste en la realización de una serie de aplicativos en modo consola, escritos en ANSI-C89, que conviertan un texto con entidades de caracteres ISO8859-1 en un gráfico de párrafos de formato PBM mediante pasos sucesivos utilizando estrategias de piping. Todos estos aplicativos recibirán los datos a procesar por el flujo stdin y devolverán su salida formateada por el flujo stdout.

Uno de los aplicativos debe permitir convertir un texto con juego de entidades ISO8859-1 a otro con juego de literales de caracteres de byte-simple ASCII (según ISO8859-1, Latin1). Otro aplicativo, dado un texto ASCII con párrafos separados mediante finales de línea, deberá recortar dichos párrafos a un ancho de línea determinado. El siguiente aplicativo recibirá un texto ASCII con líneas de ancho máximo fijo y deberá devolver el mismo texto justificado. El último aplicativo, recibirá un texto con líneas de ancho fijo y generará una imagen que represente su primera página en formato PBM mediante una tipografía de matriz de puntos.

2) Alcance del T.P.:

Mediante el presente TP se busca que el Estudiante adquiera y aplique conocimientos sobre los siguientes temas:

• Programas en modo consola. • Juego de caracteres ASCII. • Tipos enumerativos.

• Operadores de Bits y sistema de numeración hexadecimal. • Matrices estáticas.

• Cadenas de caracteres y arreglos de cadenas de caracteres. • Salida de datos con formato.

• Utilización de ciclos de control. • Directivas al preprocesador C.

• Compilación por medio de línea de comandos. 3) Desarrollo del T.P. :

Para el presente T.P. se deberán construir cuatro programas ejecutables invocables por línea de comandos: • Programa I - Traductor ISO8859-1→ ASCII : Convertirá un texto compuesto por entidades del alfabeto

ISO8859-1 a otro idéntico en contenido pero compuesto por símbolos (literales) del alfabeto ASCII (en su variante ISO8859-1).

Este programa deberá ser invocados de la siguiente forma:

type textoISO.txt | iso2ascii > textoASCII.txt (DOS) cat textoISO.txt | iso2ascii > textoASCII.txt (UNIX)

en donde "textoISO.txt" y "textoASCII.txt" son dos archivos de texto usados como ejemplo, conteniendo entidades del alfabeto ISO8859-1 y literales ASCII, respectivamente.

• Entidades   (optativo) : Eventualmente, las entidades   (non-breaking space) pueden ser traducidas a algún símbolo especial de manera que el ajustador de líneas pueda distinguirlas del carácter espacio (' ').

(2)

FIGURA: Transformaciones efectuadas por 4 posibles implementaciones de los programas desde el texto conformado por entidades ISO8859-1 hasta el fuente de la imagen PBM. El recuadro muestra la visualización en un visor de imágenes de dicho gráfico. (Por razones de diseño, la versión utilizada de los aplicativos generan un texto de 25x12 caracteres.) (Vale remarcar que diferentes estrategias de diseño pueden generar diferentes salidas igualmente válidas.)

• Programa II – Ajustador (wrapper) de líneas ASCII: Cortará todos los párrafos que midan más de 80 caracteres en varias líneas que ajusten óptimamente, y sin cortar palabras (salvo cuando no haya otra opción).

Se considerará a un párrafo como una sucesión de palabras, separadas entre sí por uno o más espacios; los párrafos se encontrarán finalizados por el carácter de fin de línea ('\n'). Dado que el ajuste de líneas será sobre el texto de párrafo y no sobre la entrada en crudo, cualquier sucesión de espacios consecutivos, o los espacios antes de un párrafo o al final de un párrafo, deberán ser ignorados.

Este programa deberá ser invocados de la siguiente forma:

(3)

type textoASCII.txt | wraplines > textocortado.txt (DOS) cat textoASCII.txt | wraplines > textocortado.txt (UNIX)

en donde "textoASCII.txt" y "textocortado.txt" son dos archivos de texto usados como ejemplo, conteniendo texto ASCII en líneas de longitud indefinida y cortadas a 80 caracteres, respectivamente.

• Final de párrafos: Dado que una vez cortadas las líneas sería imposible poder distinguir el final de cada párrafo, los mismos deben ser señalados por un delimitador especial (por ejemplo '§'). Si última línea de un párrafo midiera exactamente 80 caracteres, entonces se permite que la misma mida más que el máximo y dicho delimitador ocupará la posición 81. Para simplificar el diseño puede asumirse que dicho carácter no forma parte del texto (si bien esto sólo preocuparía si una línea luego de ser cortada termina en él).

• Casos límite: Es importante realizar un análisis razonable, documentar y justificar todas las posibilidades de casos límite que plantea este problema y las estrategias que se adoptaron (por ejemplo, que un párrafo estuviera vacío, puede cambiar las cosas -este no es el único caso límite y se insta a que se analicen los mismos a conciencia-).

• Implementacion sobre un buffer: Como sugerencia de diseño se recomienda generar un buffer de datos el cual pueda almacenar el contenido de una línea de ancho máximo. Dicho buffer puede ser llenado leyendo de a un carácter por vez de la entrada standard y almacenándolo dependiendo de que el mismo no deba ser ignorado por su contexto. Una vez llenado el buffer, puede buscarse el mejor lugar para cortar la línea, descargarse dicho contenido por la salida standard, y desplazar el final del buffer al comienzo del mismo, para continuar su llenado.

• Programa III – Justificador de párrafos ASCII: Justificará todas las líneas (que no superarán nunca los 80 caracteres de largo) a un ancho fijo de 80 caracteres; con excepción de la última línea de cada párrafo, las cuales no deberán ser justificadas.

Dado que después de la pasada de este programa el texto ya queda finalmente formateado, todos aquellos centinelas que se introdujeron (carácter de fin de párrafo, de non-breaking space, etc.) deben ser retirados o reemplazados por su traducción correspondiente.

Este programa deberá ser invocados de la siguiente forma:

type textocortado.txt | justify > textojustificado.txt (DOS) cat textocortado.txt | justify > textojustificado.txt (UNIX) en donde "textocortado.txt" y "textojustificado.txt" son dos archivos de texto usados como ejemplo, conteniendo texto ASCII en líneas de 80 caracteres máximo y justificadas a 80 caracteres, respectivamente. • Casos límite: Es importante realizar un análisis razonable, documentar y justificar todas las posibilidades de casos límite que plantea este problema y las estrategias que se adoptaron.

• Sugerencia de diseño: Dado que se sabe que las líneas deben medir como máximo 81 caracteres

(¿cuándo?), es recomendable implementar la lectura de datos sobre llamadas sucesivas a fgets(). Vale hacer la aclaración que el hecho que se asuma que la entrada deba ser menor al ancho fijado no implica que esto vaya a ocurrir siempre, y el programa debe ser capaz de responder en caso de que la entrada no cumpla con estas pautas mínimas que se le piden.

Para justificar un texto que contenga n espacios, es conveniente repartir el espacio que falta para llenar la línea equitativamente entre ellos. Dado que la división es entera, analizar cómo repartir el resto entre ellos en función de la cantidad de espacios.

• Programa IV – Traductor ASCII→ Dot-Matrix PBM : Convertirá las primeras 24 líneas de un texto compuesto por símbolos del alfabeto ASCII (literales) a un gráfico PBM idéntico en contenidos pero compuesto por símbolos de matriz de puntos 5 x 7.

Este programa deberá ser invocado de la siguiente forma:

(4)

type textojustificado.txt | ascii2dmpbm > texto_dm.pbm (DOS) cat textojustificado.txt | ascii2dmpbm > texto_dm.pbm (UNIX) en donde "texto_dm.pbm" y "textojustificado.txt" son dos archivos de texto usados como ejemplo, conteniendo un gráfico PBM en alfabeto de matriz de puntos 5 x 7 y texto justificado a 80 caracteres, respectivamente.

• El formato PBM:

El formato PBM (Portable Bit Map) de Netpbm en su variante plain es un formato de gráficos ASCII que está soportado por la mayor parte de los editores de imágenes, siendo suficientemente sencillo y fácil de manipular como para ser generado en línea de comandos en una terminal no binaria.

El mismo consta de tres secciones: un encabezado que señala qué formato de los soportados por Netpbm se codifica, las dimensiones de la imagen (ancho <espacio> alto), y una sucesión de valores que representan los diferentes pixeles ordenados por columnas y filas.

Para el formato PBM plain el identificador del formato es la cadena “P1”. Dado que por ser monocromo sólo se representan pixeles blancos y negro, los mismos sólo contienen los valores 0 y 1 para representar el color blanco y negro respectivamente. Los pixeles se separan por caracteres blancos (espacios, retornos de carro, etc.). Pueden agregarse comentarios a la imagen precediendo la línea en cuestión con el carácter numeral.

Por ejemplo, un archivo con el siguiente contenido: P1

# Dimensiones (ancho alto): 5 7 # Pixeles: 0 0 1 0 0 0 1 0 1 0 1 0 0 0 1 1 0 0 0 1 1 1 1 1 1 1 0 0 0 1 1 0 0 0 1

describe una imagen de 5 pixels de ancho por 7 de alto representando una letra A color negro sobre fondo blanco.

• Utilización de buffer de salida / Matriz de impresión:

A los fines de este TP, el contenido de salida de cada línea de la imagen debe ser generado sí o sí ser sobre una matriz estática temporal de caracteres, la cual, al ser barrida de manera conveniente, volcará su contenido a stdout.

Los caracteres convertidos a tipografía de matriz de puntos deben ser almacenados en una matriz temporal de caracteres de:

IMAGE_WIDTH x LINE_HEIGHT

pixeles (por ejemplo 479 x 5, donde 479 es 80*6-1). La matriz, una vez completa, debe ser volcada sobre stdout.

La implementación de este buffer temporal (matriz de caracteres) es obligatorio para la aprobación del TP

• Juego de caracteres para matriz de puntos:

El juego de caracteres soportado por el presente software debe ser el conformado por los símbolos:

(5)

C = { ‘A’..’Z’ + ‘0’..’9’ + ‘ ‘ + ‘.’ + ‘:’ + ‘;’+ ‘-’ + ‘(’ + ‘)’+ ‘!’ + ‘?’}

Dado que la entrada será cualquier carácter ASCII de la tabla ISO8859-1, todos los caracteres deberán ser mapeados sobre dicho juego. De esta manera, por ejemplo, los caracteres ‘a’, ‘A’, ‘á’, ‘Ã’, ‘á’, etc. deberán ser representados por el tipo ‘A’.

Pueden añadirse símbolos no contemplados en este juego de caracteres de considerarse conveniente. • Tipografía:

Cada carácter debe tener un ancho de 5 pixeles y una altura de 7 pixeles.

Debe definirse un tipo de letra para graficar cada símbolo del alfabeto. Sólo a modo de ejemplo se presenta la siguiente tipografía:

Símbolo: ‘A’ (0X7C, 0X12,0X11,0X12,0X7C)

Símbolo: ‘B’ (0X7F,0X49,0X49,0X4E,0X70)

Símbolo: ‘C’ (0X3E,0X41,0X41,0X41,0X22)

NOTA: Estos caracteres deben estar definidos dentro de un Diccionario, es decir, no pueden estar diseminados a lo largo del código fuente.

4) Restricciones:

La realización de estos cuatro programas está sujeta a las siguientes restricciones:

(6)

• No está permitido almacenar en memoria la totalidad de los caracteres leídos de stdin (además, tampoco hace falta).

• No está permitida la utilización de memoria dinámica.

• No está permitida la utilización de funciones específicas para manejo de archivos (de texto). Como funciones de E/S sólo pueden ser utilizadas las funciones de biblioteca fgetc(), getchar(), scanf(), printf(), fprintf() ,putc(), fputc(), puts(), fputs() o similares.

• Puede asumirse, de acuerdo a la tabla del juego de entidades ISO8859-1, que cualquier símbolo de su alfabeto no contiene más de 10 caracteres. Además, dichas entidades siempre comienzan con el carácter ampersand ('&') y finalizan con punto y coma (';'). Ejemplo: &aacute; (á), &ntilde; (ñ). • Dado que hay determinadas constantes que son comunes a todos (o varios de) los aplicativos, es

obligatorio tener un archivo de encabezados (.h) común a ellos; no pueden definirse las mismas constantes en cada lado individualmente siendo que si una de ellas se modificara deberían modificarse las demás. Por otro lado, notar que el extremo tampoco es razonable, el aplicativo que realiza la justificación no tiene por qué conocer el tamaño de la matriz del aplicativo que convierte a PBM.

• No está permitido en absoluto tener hard-codings del estilo: ...

if (!strcmp(s, “&aacute;”) putchar('á'); /* hard-coded!!!*/ else if(!strcmp(s, “&ntilde;”) putchar('ñ'); /* hard-coded!!!*/ ...

sino que debe recurrirse a la implementación, aunque sea poco sofisticada, de un pequeño diccionario de datos compuesto de los símbolos del alfabeto, a partir de los conocimientos adquiridos hasta el momento.

Literal ASCII Entidad ISO8859-1

Á &aacute; ... ... ñ &ntilde; ... ... ¿ &iquest; ... ...

• Hay otras cuestiones que no han sido especificadas intencionalmente en este Requerimiento, para darle al Desarrollador la libertad de elegir implementaciones que, según su criterio, resulten más convenientes en determinadas situaciones. Por lo tanto, se debe explicitar cada una de las decisiones adoptadas, y el o los fundamentos considerados para las mismas.

5) Entrega del Trabajo Práctico:

1) Deberá presentarse la correspondiente Documentación de desarrollo del TP impresa y encarpetada, siguiendo la numeración siguiente, incluyendo:

1) Carátula del TP. Incluir una dirección de correo electrónico. 2) Enunciado del TP.

3) Estructura lógica de los programas desarrollados (diagramas de flujo). 4) Estructura funcional de los programas desarrollados (si se utilizó Funciones). 5) Explicación de cada una de las alternativas consideradas y las estrategias adoptadas. 6) Resultados de la ejecución (corridas) de los programas, captura de las pantallas, bajo

condiciones normales e inesperadas de entrada.

7) Reseña sobre los problemas encontrados en el desarrollo de los programas y las 6

(7)

soluciones implementadas para subsanarlos.

NOTA: El Informe deberá ser redactado en correcto idioma castellano, con tipografía Times New Roman, Arial, o Verdana, de tamaño 11 para los párrafos, y 13 ó 14 para los títulos.

2) Deberá entregarse una impresión de los códigos fuentes (implementación y headers) de los programas desarrollados. NO entregar archivos de códigos objeto y/o ejecutables.

3) Deberá entregarse un archivo script de compilación (archivo BAT[DOS] o SH/KSH[UNIX]) que indique cómo deben ser compilados los códigos fuentes mediante el compilador C

GCC/DJGPP.

4) Deberán entregarse por correo electrónico a la casilla algo7502entregas@gmail.com, todos los archivos fuentes y scripts necesarios para compilar el trabajo práctico, además del informe en formato electrónico. Dicho correo deberá contener en su cuerpo el nombre, apellido y padrón de los integrantes del grupo.

De no hacerse la entrega digital en tiempo y forma, el TP no será corregido.

SI NO SE PRESENTA CADA UNO DE ESTOS ITEMS, SERA RECHAZADO EL TP.

6) Bibliografía:

Debe incluirse la referencia a toda bibliografía consultada para la realización del presente TP: libros, artículos, URLs, etc., citando:

• Denominación completa del material (Título, Autores, Edición, Volumen, etc.). • Código ISBN del libro (opcional: código interbibliotecario).

• URL del sitio consultado.

Referencias

Documento similar

El quincenario de los frailes de Filipinas, condena para el Archipiélago los propósitos de nivelación jurídica que para todo territorio español, peninsular o ultramarino, se

Las manifestaciones musicales y su organización institucional a lo largo de los siglos XVI al XVIII son aspectos poco conocidos de la cultura alicantina. Analizar el alcance y

Esta fiesta de los jóvenes, tan relacionada con el ritual del matrimonio prehispánico, ha ido cambiando con el tiempo; incluso los objetos anteriores, que aún subsisten, han

Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:

por unidad de tiempo (throughput) en estado estacionario de las transiciones.. de una red de Petri

Por lo tanto, en base a su perfil de eficacia y seguridad, ofatumumab debe considerarse una alternativa de tratamiento para pacientes con EMRR o EMSP con enfermedad activa

The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,

o Si dispone en su establecimiento de alguna silla de ruedas Jazz S50 o 708D cuyo nº de serie figura en el anexo 1 de esta nota informativa, consulte la nota de aviso de la