Mostrar/Ocultar TOC

Tabla de Contenidos del Libro
Prefacio
Capítulo 1: Introducción
Capítulo 2: Fundamentos
Capítulo 3: Mapas de Bits
Capítulo 4: Archivos Vectoriales
Capítulo 5: Metaarchivos
Capítulo 6: Dependencias de Plataforma
Capítulo 7: Conversión de Formatos
Capítulo 8: Trabajando con Archivos Gráficos  
Capítulo 9: Compresión
Capítulo 10: Multimedia
Formato: Adobe Illustrator
Formato: Adobe Photoshop
Formato: Atari ST
Formato: AutoCAD DXF
Formato: Autodesk 3D Studio
Formato: BDF
Formato: BRL-CAD
Formato: BUFR
Formato: CALS Raster
Formato: CGM
Formato: CMU
Formato: DKB
Formato: Dore Raster
Formato: DPX
Formato: Dr. Halo
Formato: DVM Movie
Formato: PostScript Encapsulado
Formato: FaceSaver
Formato: FAX
Formato: FITS
Formato: FLI
Formato: GEM Raster
Formato: GEM VDI
Formato: GIF
Texto en Inglés del Capítulo 4
Imagen del CD-ROM de la 2° Edición
Imagen del CD-ROM de la 1° Edición (Torrent y HTTPS)
Versión Hipertexto del CD-ROM de la 2° Edición (En Inglés)
Versión Hipertexto del CD-ROM de la 2° Edición (En Ruso)

Capítulo 4 — Archivos Vectoriales

Capítulo 4 — Archivos Vectoriales

En este capítulo, hablaremos sobre los archivos vectoriales. Ya que hemos ya introducido los archivos de mapa de bits en el Capítulo 3, Archivos de Mapa de Bits, contrastaremos características selectas de los archivos de mapa de bits con sus contrapartes de mapa de bits.



Archivos Vectoriales Versus Mapas de Bits

Un archivo de mapa de bits en un sentido contiene un mapeo exacto pixel a pixel de una imagen, la cual puede luego reconstruirse por una aplicación de renderización en la superficie de display de un dispositivo de salida. Las aplicaciones de renderización raramente tienen que tomar en cuenta algún elemento estructural que no sean pixeles, scan lines, tiras y azulejos — subdivisiones de la imagen que fueron realizadas sin referencia al contexto de la imagen.

En su lugar, los archivos vectoriales contienen descripciones matemáticas de uno o más elementos de imagen, los cuales son usados por la aplicación de renderización para construir una imagen final. De esta manera, se dice que los archivos vectoriales están conformados por descripciones de elementos de imagen u objetos, en lugar de valores de pixeles. Aunque el término objeto tiene un significado moderno, encontrarás especificaciones de formato de archivo vectorial que se apegan al uso antiguo.



¿Qué son los Datos Vectoriales?

Los vectores son segmentos de línea mínimamente definidos como un punto inicial, una dirección, y una longitud. Estos pueden, sin embargo, ser mucho más complejos y pueden incluir varios tipos de líneas, curvas y splines. Las líneas rectas y curvadas pueden usarse para definir figuras geométricas, tales como círculos, rectángulos y polígonos, las cuales pueden usarse luego para crear formas más complejas, tales como esferas, cubos y polihedros.

Los Archivos Vectoriales Vinieron Primero

Los formatos de archivo vectorial han estado presentes desde que las computadoras fueron usadas por primera vez para desplegar líneas en un dispositivo de salida. Los monitores CRT, por ejemplo, se usaron por primera vez como dispositivos de salida manejados por computadoras en los años 1950s. Las primeras pantallas CRT eran dispositivos de escaneo aleatorio similares a osciloscopios, capaces de producir imágenes de formas matemáticas y geométricas. Los dispositivos de pantalla vectoriales proporcionaban suficiente salida para las necesidades de los usuarios de computadoras por muchos años después de su introducción, debido al rango limitado de tareas para el que las computadoras eran usadas para realizar.

En algún punto surgió la necesidad de almacenar datos vectoriales, y medios de almacenamiento portable tales como tarjetas perforadas o cinta de papel fueron puestos en uso. Previo al tiempo de renderización, una imagen era lógicamente subdividida en sus elementos más simples. En el tiempo de renderización, la imagen era producida y mantenida al dibujar cada uno de sus elementos repetidamente en un orden especificado. En tiempo de almacenamiento, los datos eran rápidamente transportados como una lista de operaciones de dibujado, y descripciones matemáticas de los elementos de imagen —su tamaño, forma y posición en la pantalla&mdaash; eran grabados al dispositivo de almacenamiento en el orden en que eran desplegados.





Archivos Vectoriales e Independencia de Dispositivo

Como se mencionó antes, las imágenes vectoriales son colecciones de descripciones matemáticas de formas gráficas independientes de un dispositivo.

Más aún que sus contrapartes de mapas de bits, varios formatos vectoriales difieren primariamente porque cada uno fue diseñado para un propósito diferente. Si bien las diferencias conceptuales entre los diseños de formatos que soportan datos de mapa de bits de 1 y 24 bits puede ser pequeña, las diferencias entre formatos vectoriales usados con aplicaciones CAD y aquellas usadas para el intercambio general de datos puede ser formidable. Así, es difícil generalizar sobre formatos de archivo vectorial de la misma manera que lo hicimos cuando discutimos formatos de mapa de bits.

Por otro lado, la mayoría de dispositivos de salida son direccionables mediante puntos, ofreciendo una malla de pixeles que pueden direccionarse individualmente, como si la superficie del dispositivo fuera papel milimetrado hecho de componentes discretos. Esto significa que una aplicación siempre puede encontrar una manera de dibujar los elementos de una imagen de formato vectorial en el dispositivo.



Fuentes de los Archivos de Formato Vectorial

Los formatos vectoriales más simples son aquellos usados por aplicaciones de hoja de cálculo. Estas normalmente contienen datos numéricos pensados para ser desplegados en una malla 2D en un dispositivo de salida. Algunas aplicaciones que no son de hoja de cálculo usan formatos de archivo de hoja de cálculo para almacenar datos que pueden ser interpretados alternativamente ya sea como datos de mapa de bits o datos vectoriales.

Ejemplos de formatos comunes de hoja de cálculo incluyen los asociados con el programa Lotus 1-2-3 (.WKS y .WK1), Excel (.XLS), y Quattro Pro. Aunque estos se originaron en PCs basadas en Intel, los vendedores respectivos ahora soportan múltiples plataformas. Varios formatos de hoja de cálculo han sido desarrollados explícitamente para soportar el intercambio portable de datos entre aplicaciones de hoja de cálculo diferentes; como resultado, estos se encuentran ahora en múltiples plataformas. Estos incluyen el Lotus DIF (Formato de Intercambio de Datos) y Microsoft SYLK (Formato de Enlace Simbólico).

La mayoría de formatos vectoriales, sin embargo, están diseñados para almacenar dibujos de línea creados por aplicaciones CAD. Los paquetes CAD se usan para crear dibujos mecánicos, eléctricos y arquitecturales, diseños electrónicos y esquemas, mapas y gráficos (charts), y dibujos artísticos. La complejidad de la información necesaria para soportar las necesidades de una aplicación CAD grande es considerablemente mayor de la que se necesita para soportar una hoja de cálculo y generalmente requiere un formato vectorial más complicado.

El CGM (Metaarchivo de Gráfico de Computadora) es un ejemplo de un formato general diseñado con el intercambio de datos en mente, un formato que está definido en un estándar publicado. Todos los elementos en un archivo de formato CGM están construidos a partir de objetos simples tales como líneas y polígonos, primitivas que se asume que están disponibles en toda aplicación de renderización. Objetos muy complejos se descomponen en las formas más simples posibles.

El formato Autocad DXF (Formato de Intercambio de Datos) de Autodesk también fue diseñado con el intercambio de datos en mente, pero está controlado por el fabricante y se originó como un formato que soporta una única aplicación. Además, el DXF fue adaptado específicamente para la información CAD útil en la construcción de dibujos mecánicos, eléctricos y arquitecturales. Por lo tanto, el DXF soporta no solo elementos vectoriales comunes tales como círculos y polígonos, sino también objetos complejos frecuentemente usados en renderizaciones CAD, tales como objetos 3D, etiquetas y hatching.



Cómo Están Organizados los Archivos Vectoriales

Aunque los archivos vectoriales, como lo archivos vectoriales, varían considerablemente en diseño, la mayoría contienen la misma estructura básica: una cabecera, una sección de datos, y un marcador de final de archivo. Se necesita algún tipo de estructura en el archivo para contener información global al archivo, y para interpretar correctamente los datos vectoriales en tiempo de renderización. Aunque la mayoría de archivos vectoriales colocan esta información en una cabecera, algunos dependen solamente de un pie para efectuar la misma tarea.

Los archivos vectoriales como un todo son estructuralmente más simples que la mayoría de archivos de mapa de bits, y tienden a estar organizados como flujos de datos. La mayoría del contenido de información del archivo se encuentra en los datos de imagen.

Los componentes básicos de un archivo vectorial simple son los siguientes:

Cabecera
Datos de Imagen

Si un archivo no contiene datos de imagen, solo una cabecera estará presente. Si se requiere información adicional que no cabe en la cabecera, puede que encuentres un pie adjunto al archivo, y una paleta también puede estar incluida:

Cabecera
Paleta
Datos de Imagen
Pie


Cabecera

La cabecera contiene información que es global al archivo vectorial y debe leerse antes de que el resto de información en el archivo pueda interpretarse. Tal información puede incluir un número de identificación de formato de archivo, un número de versión, e información de color.

Las cabeceras también pueden contener atributos predeterminados, los cuales aplicarán a cualesquiera elementos da datos vectoriales en el archivo, que carezcan de sus propios atributos. Si bien esto puede lograr alguna reducción en el tamaño del archivo, lo logra con el precio de introducir la necesidad de cachear la información de la cabecera a lo largo de la operación de renderización.

Las cabeceras y pies encontrados en archivos de formato vectorial, pueden no necesariamente tener un tamaño fijo. Por razones históricas mencionadas antes, no es raro encontrar formatos vectoriales que usan flujos de registros de longitud variable para almacenar todos los datos. Si este es el caso, entonces el archivo debe leerse secuencialmente y normalmente fallará en proveer información de offset necesaria para permitirle a la aplicación de renderización, submuestrear la imagen.

El tipo de información almacenada en la cabecera está gobernada por los tipos de datos almacenados en el archivo. La información básica de cabecera contiene la altura y la anchura de la imagen, la posición de la imagen en el dispositivo de salida, y posiblemente el número de capas en la imagen. Así, el tamaño de la cabecera puede variar entre un archivo y otro dentro del mismo formato.

Datos Vectoriales

El grueso de todos los archivos a excepción de los minúsculos consiste de datos de elementos vectoriales que contienen información sobre los objetos individuales que conforman la imagen. El tamaño de los datos usados para representar cada objeto, dependerá de la complejidad del objeto y de cuánto se meditó en reducir el tamaño del archivo cuando el formato fue diseñado.

Después de la cabecera usualmente están los datos de imagen. Los datos se componen de elementos, los cuales son partes más pequeñas que conforman la imagen total. Cada elemento o bien hereda información o se asocia explícitamente con la información por defecto que especifica su tamaño, forma, posición relativa a la imagen total, color, y posiblemente otra información de atributos. Un ejemplo de datos vectoriales en formato ASCII que contiene tres elementos (un círculo, una línea, y un rectángulo), puede aparecer como:

;CIRCLE,40,100,100,BLUE;LINE,200,50,136,227,BLACK;RECT,80,65,25,78,RED;

Aunque este es un ejemplo simple, ilustra el problema básico de descifrar datos vectoriales, que es la existencia de múltiples niveles de complejidad. Cuando se descifra un formato vectorial, no solo debes encontrar los datos, sino también entender las convenciones de formateo y las definiciones de los elementos individuales. Esto difícilmente es el caso en formatos de mapa de bits; los datos de pixeles de los mapas de bits son todos básicamente lo mismo.

En este ejemplo, los elementos están separados por punto y coma, y cada uno es nombrado, seguido por parámetros numéricos e información de color. Nota, sin embargo, que la consistencia de la sintaxis entre elementos de imagen nunca está garantizada. De forma igualmente fácil pudimos haber definido el formato en forma tal que hiciéramos que bloques sin nombre significaran líneas por defecto:

;CIRCLE,40,100,100,BLUE;200,50,136,227,BLACK;RECT,80,65,25,78,RED;

y el color por defecto fuera negro si no se especificaba:

;CIRCLE,40,100,100,BLUE;200,50,136,227;RECT,80,65,25,78,RED;

Muchos formatos permiten abreviaciones:

;C,40,100,100,BL;200,50,136,227;R,80,65,25,78,R;

Nota que la R de Recta y R de Rojo se distinguen por el contexto. Encontrarás que muchos formatos han optado por reducir el tamaño de los datos a costa de la simplicidad conceptual. Eres libre de considerar esto como un razonamiento incorrecto por parte del diseñador del formato. La razón original para escoger ASCII fue por la simplicidad de la lectura y el análisis. Desafortunadamente, usar ASCII puede hacer que los datos sean demasiado voluminosos. La solución: reducir el tamaño de datos a través de reglas implícitas y convenciones, y permitir la abreviación (haciendo el formato ilegible en el proceso). Habría sido mejor para el diseñador del formato usar un formato binario en primer lugar.

Después de los datos de imagen usualmente hay un marcador de final de sección y final de archivo. Esto puede ser tan simple como la cadena EOF al final del archivo. Por las mismas razones discutidas en el Capítulo 3, Archivos de Mapa de Bits, algunos formatos vectoriales también adjuntan un pie al archivo. La información almacenada en un pie típicamente no es necesaria para la interpretación correcta de la renderización y puede ser información incidental tal como la hora y fecha en que el archivo fue creado, el nombre de la aplicación usada para crear el archivo, y el número de objetos contenidos en los datos de imagen.

Paletas e Información de Color

Como con los archivos de mapa de bits, los archivos vectoriales pueden contener paletas. (Para una discusión completa sobre paletas, mira la discusión en el Capítulo 3.) Ya que el objeto más pequeño definido en archivos de formato vectorial son los elementos de datos, estas son las características más pequeñas para las que el color puede especificarse. Naturalmente, entonces, una aplicación de renderización debe buscar definiciones de color en el archivo de paleta antes de renderizar la imagen. Nuestro ejemplo anterior, para ser correcto, necesitaría entonces incluir las definiciones de color, las cuales toman la forma de una paleta con nombres ASCII asociados:

RED,255,0,0,
BLACK,0,0,0,
BLUE,0,0,255
;C,40,100,100,BL;200,50,136,227;R,80,65,25,78,R;


Algunos archivos vectoriales permiten la definición de áreas encerradas, las cuales se consideran esbozos de los datos de los elementos vectoriales en cuestión. Dichos esbozos pueden dibujarse con variaciones en el grosor o usando lo que se conoce como diferentes estilos de pluma, los cuales son típicamente combinaciones de puntos y guiones y los cuales pueden ser familiares en dibujos técnicos y CAD. Los elementos de información no relacionados con el color, necesarios para la reproducción de la imagen por la aplicación de renderización son llamados atributos del elemento.

Rellenos y atributos de color

Los elementos encerrados pueden estar diseñados para ser llenados con color por la aplicación de renderización. Usualmente se permite que el relleno esté coloreado independientemente del contorno del elemento. Así, cada elemento puede tener dos o más colores asociados con él, uno para el contorno y uno para el relleno. Los colores de relleno pueden ser transparentes, por ejemplo, y algunos formatos definen lo que es llamado atributos de color. Además de rellenarse con colores sólidos, los elementos vectoriales encerrados pueden contener hatching o sombreado, los que a su vez son llamados atributos de relleno. En algunos casos, los atributos de relleno y de color se empaquetan juntos, ya sea conceptualmente en el diseño del formato, o físicamente en el archivo.

Los formatos que no soportan patrones de relleno deben simularlos al dibujar partes de los patrones (líneas, círculos, puntos, etc.) como elementos separados. Esto no solo introduce una calidad no uniforme al relleno, sino que también aumenta dramáticamente el número de objetos en el archivo y, consecuentemente, el tamaño del archivo.

Rellenos de gradiente

Un elemento vectorial encerrado puede también rellenarse con más de un color. La manera más fácil es con lo que es llamado un relleno de gradiente, el cual aparece como una transición suave entre dos colores ubicados en diferentes partes del área de relleno del elemento. Los rellenos de gradientes típicamente se almacenan como un color inicial, un color final, y la dirección y tipo del relleno. Por lo tanto, se espera que una aplicación de renderización construya el objeto con relleno, usualmente a la máxima resolución posible. El CGM es un ejemplo de un formato que soporta rellenos de gradiente horizontales, verticales y circulares. La Figura 4-1 ilustra un relleno de gradiente.

Figura 4-1: Relleno de gradiente
FIGURA 4-1: Relleno de gradiente

Pie

Un pie puede contener información que puede escribirse al archivo solo después de que se escriben todos los datos de los objetos, tales como el número de objetos en la imagen. El pie en la mayoría de formatos vectoriales, sin embargo, se usa simplemente para marcar el final de los datos de los objetos.



Problemas de Tamaño de Archivos Vectoriales

Sin contar la información de paleta y de atributos, el tamaño de un archivo vectorial es directamente proporcional al número de objetos que este contiene. Contrasta esto con un archivo de mapa de bits complejo, el cual se mantiene del mismo tamaño sin importar cuán compleja sea la imagen que describe. El único impacto que la complejidad tiene en los archivos de mapa de bits está en el grado de compresión disponible al creador del archivo.

Así, los archivos vectoriales pueden variar grandemente en tamaño. Un formato puede almacenar imágenes eficientemente al usar alguna forma de notación abreviada para permitir la definición compacta de elementos complejos. Un formato vectorial rico en objetos puede ser capaz de representar un único elemento complejo usando una curva Bezier, por ejemplo. Otro formato que no soporta curvas Bezier necesitaría representar la misma curva de forma ineficiente, tal vez usando una serie de líneas. Cada línea, en este caso, sería un elemento separado, produciendo un archivo mucho más grande que el que soporta directamente las curvas Bezier.

Un creador de formato estaba probablemente tratando con el problema del tamaño de archivo cuando él o ella decidió soportar la creación y nombrado de elementos complejos. Se produce un gran ahorro en tamaño cuando los elementos se repiten en la imagen; todo lo que necesita ser almacenado después de la definición del elemento original es un puntero a esa definición, así como información de atributo y posición específica a cada elemento individual repetido.

También se logra un ahorro de espacio por la manera en la que un formato almacena la información. Diferentes formatos pueden soportar información idéntica en maneras ampliamente variadas. Por ejemplo, en el formato CGM, un patrón hatch se representa como un único objeto. En los formatos PIC y Autodesk DXF, sin embargo, cada línea en el patrón hatch se almacena como un elemento separado.

Ya que los datos vectoriales se almacenan como números, estos pueden escalarse, rotarse, y de otra manera manipularse fácil y rápidamente, al menos comparado a los datos de mapa de bits. También, ya que el escalado es tan simple, los archivos vectoriales no están sujetos a limitaciones de tamaño de imagen de la misma manera que los archivos de mapa de bits.

Los formatos vectoriales normalmente no soportan compresión de datos como sí lo hacen la mayoría de formatos de mapa de bits. Algunos formatos, sin embargo, soportan un método de codificación alterno que produce archivos de datos más pequeños, pero que contienen la misma información. Los CGM, por ejemplo, normalmente almacenan información vectorial en formato ASCII de texto plano que es humanamente legible, como lo hace el ejemplo que presentamos antes en este capítulo. También permite almacenar información en formato binario, sin embargo, lo que resulta en archivos más pequeños con el costo de la legibilidad y portabilidad entre plataformas. El formato DXF también tiene un análogo llamado DXB (Binario de Intercambio de Datos) que no solo es más pequeño, sino también más rápido de cargar en su aplicación padre (AutoCAD). Sin embargo, no es portable a otras aplicaciones.



Escalando Archivos Vectoriales

Un elemento vectorial puede escalarse a cualquier tamaño. Sin embargo, pueden ocurrir problemas de precisión, de desborde (overflow) y de underflow, si los datos vectoriales se escalan a un tamaño muy grande o muy pequeño, y "grande" y "pequeño" son relativos a los tamaños de datos intrínsecos de la plataforma de hardware y software que soporta la aplicación de renderización. Aunque estos problemas son bien conocidos en el análisis numérico, no son generalmente reconocidos por la mayoría de programadores, y es útil tenerlos en mente.

Otro problema común ocurre cuando elementos aparentemente cerrados se aumentan y luego se renderizan. Dos líneas pensadas para estar unidas pueden tener puntos finales ligeramente desalineados, y esta desalineación puede aparecer como una ranura cuando el elemento se aumenta o rota. Cuando una aplicación de renderización intenta desplegar el elemento en un dispositivo de salida, los colores de relleno pueden "derramarse" inexplicablemente. Muchas aplicaciones que permiten la creación de archivos vectoriales tienen herramientas para prevenir esto, pero pueden no aplicarse automáticamente antes de guardar el archivo.



Texto en Archivos Vectoriales

Los formatos vectoriales que permiten el almacenamiento de cadenas de texto lo hacen en una de dos maneras. El enfoque más simple es almacenar el texto como un literal de cadena ASCII junto con la información de fuente, posición, color y atributo. Aunque el texto se provee de forma compacta, este esquema requiere que la aplicación de renderización tenga conocimiento de la fuente a ser usada, lo cual siempre es problemático. Ya que los nombres de fuentes en su mayoría son controlados por los vendedores, a veces es difícil incluso especificar la fuente a dibujar. El formato CGM trata este problema a través del uso de un registro internacional de nombres de fuente y datos descriptivos asociados. Cualquier aplicación de renderización que soporte el CGM debe tener acceso a estos datos, o debe usar los datos de métrica de fuente suministrados en la cabecera del archivo CGM. El texto, sin embargo, ya que se almacena en formato humanamente legible, puede editarse.

El segundo enfoque, y por mucho el más flexible, es almacenar los caracteres que conforman la cadena de texto como contornos construidos a partir de una serie de elmentos de datos primitivos. Bajo este esquema cada aplicación creadora debe tener acceso a los datos de contorno de la fuente; ya que está almacenado como cualquier otro dato vectorial, los datos de contorno de fuente pueden escalarse a voluntad, rotados, y de otra manera, manipulados. Hasta hace poco, el acceso a los datos de contorno ha sido un problema, pero los vendedores se han dado cuenta de la importancia de soportar fuentes de contorno, y ahora están suministrando esta capacidad rutinariamente a nivel del sistema operativo.

Ya que toda la industria gráfica y la industria de fuente han crecido en paralelo, y solo últimamente han comenzado a fusionarse, naturalmente hay algunas incompatibilidades entre modelos de almacenamiento de datos. La mayoría de fuentes, por ejemplo, se almacenan como una serie de splines unidas de un extremo a otro, y un tipo particular de spline puede no ser soportado por el formato de archivo en uso. En este caso, la aplicación creadora puede elegir convertir los splines a arcos o líneas, y almacenarlos a estos en su lugar. Esto puede o puede no tener un efecto en la apariencia del texto.

Las aplicaciones creadoras incluso pueden incorporar fuentes vectoriales o de trazos (strokes), los cuales usualmente son conjuntos de contornos de caracteres con una apariencia angular o mecánica, diseñada para ser dibujada con un mínimo de escándalo. Si bien muchos vendedores han elegido crear sus propias, un origen ampliamente disponible son las fuentes Hershey. Los datos Hershey están disponibles comercialmente, pero ya no se consideran adecuados para uso general.

El uso de fuentes vectoriales, de trazos o de contorno, usualmente incrementa dramáticamente el tamaño de un archivo, pero esto puede ser superado por un icremento en la calidad visual en el caso de fuentes de contorno basadas en splines. Si bien hay un número de formatos de fuente más antiguos aún en uso, los datos de contorno de fuente basados en splines en los formatos TrueType y Adobe Tipo 1 están disponibles fácilmente en todas las plataformas principales. Raramente hay necesidad de usar fuentes de trazos (strokes) ahora. Desafortunadamente, la reconstrucción de los caracteres a partir de datos de contorno de splines no es una tarea trivial, y la calidad superior ganada por la amplia disponibilidad de fuentes TrueType y Adobe Tipo 1, tiene un precio en el tiempo de renderización y los costos de desarrollo de los programas.



Pros y Contras de los Archivos Vectoriales

Las ventajas de los archivos vectoriales incluyen lo siguiente:

Algunas limitaciones de los archivos vectoriales incluyen lo siguiente:

 n0HCo(-JT' &N5i5詗7c'wOưQ|c!@|%A"@[0d1̖Y'zb,5͔Ow( 2+FcI`Fqlzv(7LX rfYvNzzYOA#.E-94Zn!S 52@K9my;.}U݀r&jn2WWHJ`Q}u_tro {rWL;=_ؼ