AnálisedoPerﬁlde Jobs paraaAceleração ...€¦ · Pontifícia Universidade Católica do Rio...

Pontifícia Universidade Católica do Rio Grande do Sul

Faculdade de Informática

Programa de Pós-Graduação em Ciência da Computação

Análise do Perfil de Jobs para a Aceleraçãodo Processo de Renderização de Documentosem Ambientes de Impressão Distribuídos

Thiago Tasca Nunes

Orientador: Prof. Dr. Luiz Gustavo Leão Fernandes

Trabalho individual I

Porto Alegre, maio de 2008

Sumário

LISTA DE FIGURAS 3

LISTA DE TABELAS 4

LISTA DE SÍMBOLOS E ABREVIATURAS 5

Capítulo 1: Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Capítulo 2: Documentos Personalizáveis 42.1 VDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 VDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 W3C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 Estrutura e Características do XML . . . . . . . . . . . . . . . . . . 72.4.2 XML Parsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 XSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5.1 XPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5.2 XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.5.3 XSL-FO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.5.4 Processadores XSL . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6 PODi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.7 PPML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.8 PPMLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.9 PDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262.10 SVG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

1

SUMÁRIO 2

Capítulo 3: Abordagem Proposta 293.1 Estrutura dos Arquivos de Entrada e Saída . . . . . . . . . . . . . . . . . . 293.2 Composition Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Métrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4 Solução Paralela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

Capítulo 4: Resultados Experimentais 344.1 Ambiente de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.1.1 Descrição do Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . 344.1.2 Casos de Teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Análise dos Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.1 Validação da Métrica . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.2 Execução Paralela . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Capítulo 5: Conclusão e Trabalhos Futuros 44

REFERÊNCIAS BIBLIOGRÁFICAS 46

Lista de Figuras

2.1 Flexibilidade oferecida pelo VDP . . . . . . . . . . . . . . . . . . . . . . . 52.2 Pretty-printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Fluxo de trabalho VDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.4 Documento XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.5 Documento XML que descreve alunos de uma turma . . . . . . . . . . . . 92.6 Documento XML versus árvore XML . . . . . . . . . . . . . . . . . . . . . 122.7 Árvore XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.8 Estrutura modular do XSLT . . . . . . . . . . . . . . . . . . . . . . . . . . 172.9 XSLT Apply-templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.10 Componentes de um documento XSL-FO . . . . . . . . . . . . . . . . . . . 192.11 Exemplo de disposição das regiões XSL-FO em uma página . . . . . . . . . 192.12 Estrutura inicial de um documento PPML . . . . . . . . . . . . . . . . . . 232.13 Estrutura final de um PPML . . . . . . . . . . . . . . . . . . . . . . . . . . 242.14 Records de um PPMLT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.15 Impressão de dados com e sem o uso de PDL . . . . . . . . . . . . . . . . . 262.16 SVG versus bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.1 Primeira fase do processamento da CTool . . . . . . . . . . . . . . . . . . . 313.2 Segunda fase do processamento da CTool . . . . . . . . . . . . . . . . . . . 313.3 Nova abordagem paralela . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.1 Três documentos dos casos de teste Signage . . . . . . . . . . . . . . . . . 354.2 Um documento dos casos de teste Letter . . . . . . . . . . . . . . . . . . . 364.3 Um documento dos casos de teste Postcard . . . . . . . . . . . . . . . . . . 364.4 Algumas páginas de um documento dos casos de teste Brochure . . . . . . 374.5 Tempo de execução - Signage10000 e Signage20000 . . . . . . . . . . . . . 394.6 Tempo de execução - Letter10000 e Letter20000 . . . . . . . . . . . . . . . 404.7 Tempo de execução - Postcard10000 e Postcard20000 . . . . . . . . . . . . 404.8 Tempo de execução - Brochure10000 e Brochure20000 . . . . . . . . . . . . 414.9 Speedup referente aos 8 casos de teste descritos . . . . . . . . . . . . . . . . 42

5.1 Escalonador para jobs da fila . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3

Lista de Tabelas

2.1 Comandos XPath da sintaxe expandida . . . . . . . . . . . . . . . . . . . . 142.2 Comandos XPath da sintaxe abreviada . . . . . . . . . . . . . . . . . . . . 152.3 Comparativo do tamanho de um arquivo PPMLT e um PPML . . . . . . . 26

3.1 Tempo gasto na primeira fase versus tempo de execução total . . . . . . . 32

4.1 Características dos casos de teste . . . . . . . . . . . . . . . . . . . . . . . 354.2 Tempo de execução seqüencial . . . . . . . . . . . . . . . . . . . . . . . . . 384.3 Tempo de execução em 4 cores versus em 4 nodos . . . . . . . . . . . . . . 39

4

Lista de Símbolos e Abreviaturas

VDP Variable Data Printing 4

VIP Variable Information Printing 4

VDT Variable Data Templates 6

W3C World Wide Web Consortium 7

HTML HyperText Markup Language 7

XHTML Extensible HyperText Markup Language 7

CSS Cascading Style Sheets 7

XML Extensible Markup Language 7

SGML Standard Generalized Markup Language 7

DTD Document Type Definition 9

SAX Simple API for XML 10

DOM Document Object Model 10

API Application Programming Interface 10

VB Visual Basic 11

XSL Extensible Stylesheet Language 11

DSSSL Document Style Semantics and Specification Language 11

XPath XML Path Language 11

XPointer XML Pointer Language 11

XQuery XML Query 11

XSLT Extensible Stylesheet Language Transformation 15

WML Wireless Markup Language 15

XSL-FO Extensible Stylesheet Language Fomatting Objects 18

RGB Red, Green and Blue 20

CMYK Cyan, Magenta, Yellow and Key 20

5

LISTA DE SÍMBOLOS E ABREVIATURAS 6

PODi Print On Demand initiative 22

HP Hewlett Packard 22

PPML Personalized Print Markup Language 22

PPMLT Personalized Print Markup Language-Template 25

PDL Page Description Language 26

PCL Printer Control Language 26

PDF Portable Document Format 27

PS PostScript 27

SVG Scalable Vector Graphics 27

GIF Graphics Interchange Format 27

JPEG Joint Photographics Experts Group 27

PNG Portable Network Graphics 27

CSVG Constraint SVG 28

CTool Composition Tool 30

FOP Formatting Objects Processor 30

MPICH MPI Chameleon 34

MPI Message Passing Interface 34

Abstract

Personalized documents creation has become a common practice on digital printing area.This need required languages to add more flexibility to the documents creation in anuncomposed format. However, in order to print these documents, there is a need for arendering step that may compromise the system overall performance. This way, the useof high performance approaches have become an interesting alternative to overcome thisissue. In previous works, it has been shown high performance strategies that used severalFOP (Formatting Objects Processor) rendering engines to accelerate the pre-processingof a single document. However, print shops have a queue containing several jobs andaccelerating each one of them separately does not necessarily represent the best strategyto gain performance over the whole queue.

This work presents two inicial steps to allow the construction of a smart parallelsolution, capable of scheduling the jobs of the queue in a way that the best performancepossible is achieved. First, an analysis of the jobs profile is described, searching for aconsistent metric to predict the effort spent on the computation of each one of them,providing a valuable information to better organize the processing of the jobs. Secondly,a new parallel approach that surpasses the previous achievements is discussed, to be usedby the scheduler.

Resumo

A criação de documentos personalizados se tornou uma prática comum na área de impres-são digital de documentos. Esta necessidade provocou o uso de linguagens para flexibilizara criação de um documento em um formato não composto. Entretanto, a fim de imprimirestes documentos, surge a necessidade de uma fase de renderização que pode comprometero desempenho do processo como um todo. Assim, o uso de técnicas de alto desempenhose mostrou como uma alternativa interessante para superar este problema. Em trabalhospassados foram apresentadas estratégias paralelas que utilizavam várias engines de ren-derização FOP (Formatting Objects Processor) para acelerar o pré-processamento de umúnico job na fila. No entanto, print shops dispõem de uma fila contendo diversos jobs ea aceleração de cada um deles separadamente não necessariamente representa a melhorestratégia para ganhar desempenho no âmbito da fila inteira.

Este trabalho apresenta dois passos iniciais para futuramente permitir a construçãode uma solução paralela inteligente, capaz de escalonar os jobs da fila de maneira queo melhor desempenho possível seja atingido. Primeiramente, se descreve uma análisesobre o perfil dos jobs, buscando uma métrica consistente para prever o esforço gastona computação de cada um deles, fornecendo assim uma informação valiosa para melhororganizar o processamento dos jobs. Em um segundo momento, se discute uma novaabordagem paralela que supera os resultados obtidos com as versões anteriores, a serutilizada pelo escalonador.

1 Introdução

Devido ao surgimento de dispositivos capazes de imprimir uma grande quantidade dedocumentos em alta qualidade de forma eficiente, o processo de impressão digital tornou-se mais rápido, deixando de ser um empecilho para as empresas. Entretanto, surge anecessidade de personalização de documentos, com o objetivo especificar mensagens paracada tipo de cliente. Com isso, o custo para a descrição destes passa a ser muito alto,prejudicando o processo de impressão como um todo.

Neste sentido, procedimentos automatizados para a criação e transformação de docu-mentos se tornaram necessários, com a finalidade de suprir a demanda existente. Diversasferramentas foram desenvolvidas para auxiliar o designer a criar um template, do qual se-rão geradas diferentes instâncias de documentos. Tornou-se possível, então, definir áreasvazias (de tamanho fixo) no template, que serão preenchidas com o conteúdo variável,personalizado para cada instância do template em questão. Desta forma, o mesmo layouté aplicado sobre diversas informações, gerando um job constituído por um conjunto dedocumentos personalizados (variáveis). Neste âmbito, linguagens capazes de apresentaro grau de flexibilidade necessário foram desenvolvidas, permitindo a definição de áreasestáticas e dinâmicas de um documento, assim como a formatação de seus respectivosconteúdos.

No cenário atual, a maioria das impressoras não são capazes de interpretar estaslinguagens, portanto se tornam necessários diversos processos para possibilitar a impressãode forma correta dos documentos. Um destes trata-se da renderização, feito por umaaplicação denominada engine. Esta ferramenta realiza a composição de um documento, ouseja, aplica as diretivas de formatação especificadas por uma determinada linguagem nãointerpretável pela impressora, ao conteúdo. O documento resultante possuirá parágrafos,margens, fontes, cores, entre outros aspectos já definidos corretamente dentro do escopode cada página, estando assim apto a ser enviado para a impressora.

1.1 Motivação

Empresas especializadas na publicação digital de documentos (print shops) possuemuma fila de jobs, contendo diversos conjuntos de documentos a serem impressos. Assim,é comum a adoção de uma impressora com uma alta capacidade de processamento, em

1

1. Introdução 2

alguns casos sendo capaz de imprimir até 1 página por segundo. Neste cenário, todasas atividades relacionadas a preparação de um documento devem ser finalizadas em umespaço de tempo limitado, para que não ocorra a subutilização da impressora disponível.O processo de renderização trata-se de um dos procedimentos principais nesta fase e aolidar com jobs contendo milhares de instâncias de documentos, ele acaba sendo muitocustoso, representando um gargalo do processo de impressão.

Além disso, print shops geralmente utilizam impressoras em paralelo para aumentaro consumo dos documentos pertinentes a um dado job. Desta maneira, o desempenho daengine de renderização deve aumentar proporcionalmente para mantê-las continuamentetrabalhando. Entretanto, a fase de renderização normalmente é centralizada em uma únicaunidade de processamento, fazendo com que a engine acabe por não conseguir alimentaras impressoras associadas.

Em trabalhos passados [1, 2] foram apresentadas estratégias para elevar a vazão doprocesso de renderização realizado pela engine, através da aplicação de técnicas de altodesempenho. Similar ao conceito de utilizar impressoras em paralelo para consumir ojob de entrada rapidamente, se propôs o uso de engines de renderização em paralelo.Contudo, o ganho obtido com estas soluções estagnava-se a partir de um número relati-vamente baixo de engines. Além disso, estas se preocupavam em ganhar desempenho noâmbito da renderização de um único job por vez, através da alocação de todos os recursospara a mesma. Assim, a estratégia proposta não necessariamente se refletia na melhormaneira para ganhar desempenho na computação da fila como um todo. Para tanto, serianecessário avaliar o custo computacional de cada um destes jobs, possibilitando a escolhada melhor configuração de alocação dos recursos disponíveis. Com isso, poderia-se cederrecursos para diversos jobs da fila, realizando a computação de vários deles em paralelo.

1.2 Objetivos

O trabalho realizado trata-se de um primeiro passo para o desenvolvimento de umescalonador inteligente. Este utilizaria diversas instâncias de uma aplicação paralela parao processamento de vários jobs da fila. A fim de descobrir a melhor distribuição dosrecursos entre os jobs, esta ferramenta tomaria como base uma determinada informaçãoque indicaria o custo computacional associado a cada um deles.

Neste estudo objetiva-se identificar uma métrica consistente para analisar o esforçoque será gasto no processamento de um job. Além disso, introduz-se uma solução paralelasimples, que resolve os problemas encontrados nas estratégias previamente definidas, parafuturamente ser incorporada ao escalonador. Neste sentido, realiza-se uma análise sobreo possível ganho de desempenho que poderia ser obtido através do uso deste escalonadorinteligente a partir dos resultados apresentados neste trabalho.

1. Introdução 3

1.3 Estrutura do trabalho

Este volume organiza-se como segue: o Capítulo 2 descreve algumas tecnologias etécnicas ligadas a construção de documentos personalizáveis; o Capítulo 3 apresenta asabordagens propostas, explicitando o funcionamento do processo de renderização, rela-tando aspectos como a ferramenta seqüencial utilizada, a métrica indicada e a soluçãoparalela desenvolvida; o Capítulo 4 discorre sobre o ambiente de teste utilizado para efe-tuar a execução das versões seqüencial e paralela, além de trazer os resultados obtidos,demonstrando a validade da nova abordagem paralela e da métrica escolhida; o Capítulo5 conclui o estudo e apresenta possíveis pesquisas futuras a serem realizadas a partir dosresultados obtidos neste trabalho; por fim, é descrita a bibliografia utilizada.

2 Documentos Personalizáveis

A criação de documentos personalizáveis envolve diversas técnicas e tecnologias quepermitem a sua aplicação. Neste contexto, algumas foram resultado de anos de pes-quisa diretamente voltada para a impressão digital de documentos, enquanto outras fo-ram desenvolvidas para usos em diferentes cenários, mas acabaram sendo adotadas porapresentarem características desejáveis a construção de documentos variáveis. Este Ca-pítulo apresenta algumas das linguagens e conceitos fortemente ligados aos documentospersonalizáveis.

2.1 VDP

Impressão de dados variáveis ou Variable Data Printing (VDP) [3] trata-se de umatendência que reúne diversas técnicas, conceitos e padrões para possibilitar a criaçãode documentos com conteúdo dinâmico. Também conhecido como Variable InformationPrinting (VIP) , Personalized Printing, Database Publishing, entre outros, VDP trazdiversas facilidades para a construção de documentos flexíveis. Com o uso de VDP, odesigner pode definir áreas personalizáveis de um documento que correspondem as porçõesvariáveis deste. Contrastando com a simples impressão digital, ao invés de se criar umdocumento contendo uma única mensagem para diversos clientes, com VDP é possívelutilizar um documento para passar tantas mensagens quanto necessárias, personalizadaspara cada cliente. Portanto, a grande vantagem do uso de VDP é o que se pode chamarde personalização em massa. A Figura 2.1 ilustra a dinamicidade que pode ser encontradaem um documento com conteúdo personalizável, tal como variações de formatação, texto,imagens ou até mesmo de sua própria estrutura interna.

VDP foi adotado por diversas empresas, por facilitar o processo de criação dos docu-mentos. Tratando-se de situações reais de mercado pode-se citar o caso das olimpíadas deSydney [4], em que os resultados da competição foram publicados através do uso de VDP.Diversas outras podem ser observadas no cotidiano, como, por exemplo, a fatura de umbanco. Esta possui sempre o mesmo layout, mas difere no conteúdo, mais especificamentenos dados pessoais e financeiros de cada cliente. Desta maneira, o banco pode definir umúnico documento com áreas personalizáveis, onde estas correspondem as informações quediferenciam-se de um cliente para o outro. Outro exemplo muito comum que se pode citar

4

2. Documentos Personalizáveis 5

Figura 2.1: Flexibilidade oferecida pelo VDP

é o caso dos encartes de supermercados. Este tipo de documento possui sempre a mesmaestrutura: figuras de produtos espalhados na página com seus respectivos preços. Assim,o designer pode fixar as posições das imagens e de seus preços, mas considerar que tantoum quanto outro são porções variáveis em um documento. Com isso, o template criadopode ser reutilizado para a construção de diversos encartes de produtos diferentes.

Contudo, para que VDP seja realmente aplicável à construção de documentos maisflexíveis são necessárias linguagens para descrever as partes variáveis e estáticas destes.Entretanto, a maioria das impressoras não é capaz de lidar diretamente com estas lin-guagens, gerando a necessidade da existência de uma fase de pré-processamento. Nesteescopo, são utilizadas técnicas de Pretty-printing [5]. Estas tratam-se da transformaçãode um conteúdo com uma formatação não usual (ou óbvia) a um leitor humano parauma forma usual e inteligível (Figura 2.2). Tal fase é realizada através do processo derenderização, a fim de aplicar a formatação explicitada pelas primitivas das linguagens aoconteúdo do documento, tornando-o visualmente apropriado ao usuário final e, por fim,imprimível.

Figura 2.2: Pretty-printing


2.2 VDT

Uma técnica amplamente utilizada no cenário de VDP, trata-se de VDT (VariableData Templates) [6]. Esta propõe um fluxo de trabalho (Figura 2.3), com o objetivode padronizar o processo de criação e impressão dos documentos, tornando-o confiável,previsível e aumentando a vazão de documentos impressos. Deve-se ressaltar que o fluxode trabalho apresentado é um modelo genérico, podendo ser extendido e modificado parasuprir necessidades específicas de cada empresa.

Figura 2.3: Fluxo de trabalho VDT

A implementação deste fluxo não estabelece o uso de uma tecnologia específica, po-dendo se adaptar a qualquer uma que realize a função necessária. Existem três fasesbásicas: criação, combinação e processamento final. A fase de criação gera como saídaum template de documento que descreve o layout a ser empregado, além de elementosfixos e estáticos nele contidos. Na segunda fase, deste template são instanciados diver-sos documentos contendo dados específicos provenientes de uma base de dados. Cadainstância é repassada para um processo de formatação, renderização e rasterização1 (ter-ceira fase), gerando documentos prontos para serem impressos. É importante ressaltarque os três processos pertencentes a última fase são complementares: primeiramente odocumento é formatado por uma determinada linguagem, logo após é aplicado o processode renderização transformando-o em um formato composto e, por fim, para que este sejavisualizado ou impresso, faz-se o processo de rasterização, onde se converte o documentorenderizado para uma representação de pontos no papel ou pixels numa tela.

Diversas vantagens são obtidas através da aplicação deste fluxo de trabalho segmen-tado: as empresas são capazes de lidar mais facilmente com impressões de uma grandequantidade de dados, devido a existência de fases bem definidas e corretamente especifi-cadas; separou-se o design do conteúdo, permitindo a composição do layout independen-

1processo de transformação de um gráfico vetorial para uma representação de pixels ou pontos, po-dendo assim serem visualizados numa tela ou impressos.


temente da disponibilidade dos dados em um primeiro momento; liberdade para aplicara tecnologia que melhor se adapta a necessidade de cada empresa, além do fluxo serfacilmente extendido.

2.3 W3C

W3C (World Wide Web Consortium) [7] trata-se de um consórcio internacional deempresas e universidades preocupadas com padrões para a criação e interpretação de con-teúdo para o ambiente Web (da internet). Os guias e regras providos por este grupo(chamados de W3C Recommendations) dispõe da melhor maneira de utilizar as tecnolo-gias existentes em tal cenário. Além disso, o grupo W3C é responsável pela criação dediversas linguagens, presentes na realidade atual de mercado, como por exemplo: o HTML(HyperText Markup Language) [8], o XHTML (Extensible HyperText Markup Language)[9], CSS (Cascading Style Sheets) [10], entre outras.

Como visto anteriormente, para a utilização de VDP são necessárias linguagens ca-pazes de descrever e formatar o conteúdo variável e estático de um documento. Assim,algumas das tecnologias propostas pelo W3C foram adotadas no âmbito da impressãodigital de documentos variáveis. Tal escolha decorre do fato de que o desenvolvimentodestas é resultado de diversos anos de pesquisa por um grupo consolidado, que atuadiretamente no mercado, apresentando diversas características desejáveis, tais como fle-xibilidade, portabilidade, robustez e uma especificação que condiz com o propósito deVDP.

2.4 XML

XML (Extensible Markup Language) [11] é uma metalinguagem utilizada para repre-sentar dados de forma estruturada. Desenvolvido pelo W3C, a princípio, o XML deveriaser aplicado para facilitar a troca de informações através da internet. Entretanto suautilização foi adotada em outros cenários, como na área de impressão digital de documen-tos, tornando-se um padrão para a descrição de informações pertinentes a determinadoscontextos.

Nesta seção será apresentada a estrutura de um documento XML, assim como cate-gorias de aplicações existentes para interpretar este tipo de linguagem.

2.4.1 Estrutura e Características do XML

Derivado do SGML (Standard Generalized Markup Language) [12], o XML é maisespecifico do que o primeiro, tornando mais fácil a sua análise gramatical e o seu pro-cessamento. Contudo, as chamadas tags (palavras delimitadas por ’<’ e ’>’ ), que se


tratam da estrutura utilizada no XML para delimitar um determinado conteúdo, descen-dem diretamente do SGML. No corpo de tais estruturas (entre ’<palavra’ e ’>’ ), podemser definidos atributos pertinentes a tag, possuindo a sintaxe da forma ’nome do atri-buto’=’valor do atributo’. Tratando-se de um documento XML bem formado (correto),para cada tag (de abertura) encontrada no documento, deve existir sua correspondentetag de fechamento, expressa por ’</palavra>’, onde ’palavra’ é a mesma da primeira.Além disso, outro quesito deve ser respeitado: é preciso que uma única tag, referida comoroot, englobe todas as demais, representando uma forma de ’pacote’ para toda a estruturasubseqüente.

Entre uma tag de abertura e sua respectiva de fechamento podem ser encontrados:nada (vazio), informações ou outras tags. Assim, uma característica marcante da meta-linguagem deve ser destacada: o XML é organizado de forma hierárquica. Isto decorredo fato de que cada tag pode encapsular outros dados, sendo considerada com um nívelhierárquico superior àqueles que ela contém. Além disso, o XML provê uma maneira paradescrever comentários, auxiliando o usuário a manter o documento claro para outros. AFigura 2.4, ilustra um exemplo de um documento XML.

Figura 2.4: Documento XML

Na metalinguagem XML todas as tags são arbitrárias, significando que não são pré-definidas, ou seja, são criadas pelo usuário. Tal característica foi estabelecida para ampliara área de aplicação desta tecnologia. Têm-se, por outro lado, casos destinados a um usomais específico, como a metalinguagem HTML, também derivada do SGML. Da mesmaforma que o XML, no HTML são utilizadas tags como estrutura de controle. Entretanto,estas não são arbitrárias, mas pré-definidas pela especificação do HTML, assim como afunção realizada por cada uma delas. O HTML é puramente destinado à visualização deconteúdo em navegadores, portanto, se houver a ocorrência de alguma tag que não estácontida na especificação da linguagem, o navegador não será capaz de interpretá-la. Istorestringe a utilização do HTML somente para a apresentação de conteúdo com o auxíliodestes programas, enquanto o XML flexibiliza a descrição de informações para qualquer


aplicação, ampliando o escopo em que pode ser empregado.Outra grande vantagem obtida pelo uso de XML é a separação do conteúdo de sua

formatação (ou apresentação). Como esta metalinguagem tornou-se um padrão paraa representação de dados, é possível que uma ou mais aplicações troquem informações(formatadas por XML), e decidam de forma independente como apresentar o conteúdoao usuário final. Em outras palavras, é a aplicação que decide que atitude tomar quandouma determinada tag, atributo ou conteúdo forem encontrados.

Além disso, o XML provê uma maneira do usuário prefixar uma tag, com o objetivode a definir para uma determinada situação. Tal funcionalidade é conhecida como XMLNamespaces [11]. Com isso, em um mesmo documento XML, podem existir tags comnomes iguais (onde a palavra da tag é a mesma), mas com namespaces diferentes. Parautilizar o XML Namespaces deve-se colocar o prefixo desejado antes da palavra da tag,separando-os pelo caracter ’:’ (<prefixo:palavra> ou </prefixo:palavra>). Assim, a pos-sibilidade de ocorrências de tags idênticas dentro de documentos XML distintos se tornamuito baixa, permitindo a reutilização e extensão de esquemas XML já existentes.

A flexibilidade apresentada pelo XML, entretanto, acaba provocando um problema:as aplicações devem ser capazes de validar a estrutura do documento XML, verificandose o documento lido condiz com a especificação original. Para auxiliar na explicaçãodo problema, a Figura 2.5 apresenta um documento XML que descreve um conjunto dealunos de uma turma.

Figura 2.5: Documento XML que descreve alunos de uma turma

Analisando o caso de um único aluno, supõe-se que ele deve, obrigatoriamente, possuirpelo menos um nome (os demais dados são opcionais). Devido ao fato da criação de tagsser arbitrária, a especificação do XML não pode fixar que ao ser encontrada um elemento<aluno>, dentro deste deve necessariamente haver outra tag <nome>, contendo o nomedo aluno e a respectiva terminação da tag. Desta forma, o XML provê maneiras paraque seja definido que, no contexto descrito, é necessário que um aluno deva possuir umnome. Isto é feito através da utilização de documentos DTD (Document Type Definition)que podem estabelecer características mandatórias da estrutura do XML definido pelousuário. Entre estas, atributos e tags que cada tag deve conter, tags que não devem


possuir conteúdo, assim como as que devem, entre diversas outras regras.

2.4.2 XML Parsers

XML parsers são ferramentas ou bibliotecas utilizadas para ler dados formatadosatravés de XML, verificando a existência de um documento sintaticamente bem formadoe permitindo a realização de algumas formas de processamento sobre eles. Atualmenteexistem dois tipos principais de parsers XML: SAX (Simple API for XML) [13] e DOM(Document Object Model) [14].

SAX trata-se de um parser de baixo nível baseado em eventos, que provê uma espe-cificação de API (Application Programming Interface) para lidar com estes. Este parserreporta eventos causados durante a leitura e parse do documento (como, por exemplo,uma tag inicial ou o fechamento de uma tag) através de funções de callback definidas naAPI. Com isso, o programador decide qual atitude tomar para os diferentes eventos. Esteparser possibilita a leitura de documentos que ocupem muito mais espaço do que a me-mória disponível e a obtenção dos dados desejados sem a necessidade de ler o documentointeiro.

O parser DOM constrói uma estrutura de árvore na memória representando o docu-mento XML, após realizar a leitura inteira do documento em questão. Este parser, assimcomo o SAX, provê uma API, que neste caso serve para lidar com a árvore construída. Aaplicação que está utilizando o DOM pode, então, navegar na árvore e realizar operaçõesem cima da mesma, como, por exemplo, adicionar nodos, removê-los, editá-los e realizarconversões nos nodos já existentes. Desta forma, a manipulação do documento XML lidoé realizada de forma simples e clara. Entretanto, o consumo de memória é proporcional aotamanho do documento, desencorajando o uso deste parser para tratar com documentosmuito grandes.

Neste sentido, todo parser DOM e SAX pode ser classificado por duas categoriasdistintas, devido a realização ou não de validação. Aqueles que não realizam valida-ção preocupam-se em processar todas as declarações do documento XML, constatandosomente se este é sintaticamente bem formado. Já os que realizam validação, fazem omesmo trabalho, mas verificam, adicionalmente, se o documento XML lido condiz com aestrutura e sintaxe definida no DTD referente a ele. Em termos de desempenho, pode-se notar que aqueles que não realizam validação são mais rápidos, por executarem umtrabalho menor.

Cabe-se ressaltar que a escolha do tipo de parser que melhor se adapta a necessidadede uma determinada aplicação é subjetiva, ao ponto de que requisitos específicos doprograma devem ser analisados a fim de apontar a melhor opção. Devem ser verificadosaspectos como: se é necessária a validação do documento, se será realizada de formainstigante a manipulação do XML lido, se os documentos são muito grandes, etc. Neste


contexto, implementações prontas de parsers DOM e SAX, que suportam validação e nãovalidação, estão disponíveis em diversas linguagens de programação, como Java, C, C++,VB (Visual Basic) , Pearl, entre outras.

2.5 XSL

Pode-se constatar que a representação de dados através do formato XML provê umamaneira organizada de descrever as informações pertinentes a um determinado contexto.Entretanto, com este advento, surge a necessidade de processar estes dados para apresentá-los de maneira cabível a cada situação distinta, seja para pessoas os lerem ou para apli-cações os utilizarem como entrada (em um determinado formato, não necessariamenteXML). Como mencionado anteriormente, o XML separa o conteúdo de sua apresentação,permitindo a sua publicação em diversos formatos, tanto em meio material, como livros,jornais, pôsters, cartas, etc., quanto em meio digital, como em texto puro, XHTML,HTML, SGML, etc. Desta maneira, deve ser possibilitada a transformação e formataçãodo conteúdo XML para suportar estas representações distintas.

XSL (Extensible Stylesheet Language) trata-se de uma linguagem desenvolvida peloW3C com o intuito de prover maneiras de formatar e transformar o conteúdo XML. Em-basada nas linguagens CSS e DSSSL (Document Style Semantics and Specification Lan-guage) [16], em um primeiro momento, o XSL tratava-se de uma especificação única, queprovia toda a sintaxe para lidar com o processamento de documentos XML. Entretanto,mais tarde, foi dividida em três linguagens diferentes:

• Linguagem para navegar e referenciar elementos do documento XML;

• Linguagem para transformar documentos XML;

• Linguagem para formatar documentos XML.

Para possibilitar a aplicação destas tecnologias, se tornaram necessários interpreta-dores capazes de aplicar as instruções especificadas ao documento XML, provocando acriação dos processadores XSL, responsáveis por tal função.

Esta seção apresenta as três linguagens derivadas do XSL original, assim como osprocessadores XSL existentes para lidar com estas.

2.5.1 XPath

A linguagem XPath (XML Path language) [17] provê a sintaxe necessária para en-dereçar porções de um documento XML. Por fazer parte do conjunto XSL, trata-se deuma recomendação W3C e é utilizado por outras linguagens como XPointer (XML Poin-ter) [18] e o XQuery (XML Query) [19]. A linguagem XPath é aplicada a um documento


XML, assumindo que este seja bem formado. Desta maneira, o XPath não trata o XMLcomo simples texto, mas o interpreta como uma árvore de nodos. No contexto da lingua-gem, sete tipos diferentes de nodos [17] podem existir: elementos, atributos, namespaces,instruções de processamento, comentários e o nodo raiz do documento. Não se deve con-fundir o nodo raiz do documento com a tag root deste. O primeiro se refere ao início dodocumento XML, ou seja, um nível acima da tag root. Além disso, a navegação implícitarealizada pelo XPath lida apenas com os nodos do tipo elemento e raiz do documento,sendo necessários comandos explícitos para acessar os demais. A Figura 2.6 apresentaum documento XML, seguido de sua representação em árvore, exemplificando alguns dostipos de nodos descritos.

Figura 2.6: Documento XML versus árvore XML

Além de oferecer meios de navegação na árvore formada, o XPath disponibiliza di-versas maneiras para lidar com o conteúdo encapsulado pela estrutura XML. Entre elas,estão funções para manipular strings, números, valores booleanos, datas, nodos da árvore,seqüências, etc. Muitas destas foram apenas recentemente incorporadas ao XPath, coma nova versão (2.0) [20], lançada em janeiro de 2007.

A sintaxe empregada no uso desta linguagem tenta se aproximar da notação de ca-minhos geralmente associada a sistemas de arquivos. Neste âmbito, duas categorias desintaxe podem ser utilizadas: a abreviada e a expandida. A primeira provê uma maneiramais simples de referenciar os elementos XML, mas engloba apenas as instruções maiscomuns para facilitar a navegação. Já a segunda possui um conjunto maior de recursos,mas estes devem ser descritos explicitamente através de comandos mais longos, o quepode se tornar exaustivo e repetitivo. Para atingir o potencial máximo da linguagem, épossível, então, combinar as duas sintaxes em uma única expressão XPath, obtendo asvantagens oferecidas por cada uma delas.

Para facilitar a compreensão dos comandos de navegação na árvore providos pelalinguagem XPath, alguns conceitos de relação entre os nodos devem ser esclarecidos. AFigura 2.7 apresenta um documento XML, juntamente com sua árvore representativa, que


servirá de exemplo para demonstrar os diferentes tipos de relacionamento identificadospelo uso do XPath.

Figura 2.7: Árvore XML

Levando em consideração a representação utilizada pela linguagem XPath para inter-pretar a estrutura XML (árvore de nodos), pode-se definir que cada elemento XML podeou não possuir um pai, que se refere àquele que está exatamente a um nível superior naárvore e possui uma ligação direta com o nodo em questão. Um elemento não possuirá umpai se, e somente se, não houver nenhum outro que o encapsula no documento XML, ouseja, o elemento em questão deve estar especificamente no topo da árvore XML. Em umdocumento XML bem formado existe apenas um elemento que reflete tal situação: o nodoraiz do documento. Analisando o documento apresentado na Figura 2.7, pode-se cons-tatar que o pai de <semestre1> e <semestre2> é o elemento <cienciaDaComputacao>,enquanto o pai dos elementos <aluno> trata-se ou de <turma101>, ou de <turma102>,dependendo de qual elemento <aluno> se esta verificando. Por outro lado, os nodos quepossuem um pai são considerados como seus filhos, portanto, no exemplo ilustrado, pode-se citar que <semestre1> e <semestre2> são filhos de <cienciaDaComputacao>. Nestecaso, todos os nodos que não são pais de nenhum outro, obviamente não possuem filhos.

A partir destas duas definições podem ser construídos outros conceitos utilizados peloXPath, como: ancestrais, descendentes e irmãos. Ancestrais de um determinado nodotratam-se de um conjunto de nodos, do qual fazem parte: seu pai, o pai de seu pai e assimpor diante até que se inclua o nodo raiz do documento. Descendentes de um nodo, poroutro lado, são: seus filhos, os filhos de seus filhos e assim consecutivamente, até que osnodos incluídos até o momento não possuam mais filhos. Por fim, os irmãos de um nodosão todos aqueles que apresentam o mesmo pai que ele. Tomando como exemplo o caso doelemento <semestre1> tem-se que seus ancestrais estão contidos num conjunto formado


por: <cienciaDaComputacao>, <pucrs>, <faculdade> e o nodo raiz do documento. Seusdescendentes tratam-se de <turma101> e seus respectivos filhos: os 4 elementos <aluno>.Neste caso, os nodos texto não são inclusos na consulta, pois como dito anteriormente,a menos que descritos comandos explicítos, o XPath lida somente com nodos elementose raiz do documento. Por fim, em termos de irmãos, <semestre1>, possui apenas um:<semestre2>.

A sintaxe expandida do XPath provê comandos, chamados de axis, que condizem comas funcionalidades de todos os conceitos acima explicitados. No entanto, tais comandosnão se limitam a apenas isto, fornecendo maneiras de referenciar o próprio nodo, seusatributos, seu namespace e seu nodo texto. A Tabela 2.1 apresenta os comandos fornecidospelo XPath, juntamente com uma breve descrição sobre cada um deles.

Tabela 2.1: Comandos XPath da sintaxe expandidaComando Descriçãoancestor retorna todos os ancestrais de um nodo

ancestor-or-self retorna o próprio nodo e todos os seus ancestraisattribute retorna todos atributos de um nodochild retorna todos os filhos de um nodo

descendant retorna todos os descendentes de um nododescendant-or-self retorna o próprio nodo e todos seus descendentes

following retorna todos os elementos que ocorrem depoisde um nodo com exceção de seus descendentes.

following-sibling retorna todos os elementos que ocorrem depoisde um nodo e são seus irmãos

namespace retorna os namespaces de um nodoparent retorna o pai de um nodo

preceding retorna todos os nodos que ocorrem antes deum nodo com exceção de seus ancestrais

preceding-sibling retorna todos os nodos que ocorrem antes deum nodo e são seus irmãos

self retorna o próprio nodo

Na sintaxe expandida, o emprego destes comandos é efetuado através da forma axis::nodo[predicado 1] ... [predicado N], onde os predicados são opcionais e tratam-se de algumafunção ou teste que se deseja aplicar ao comando especificado. Uma construção XPathválida trata-se de um único comando ou uma conjunção de diversos deles, representandouma cadeia de referencias a nodos, cada uma executada sobre o resultado obtido coma anterior. Em termos mais práticos, pode-se, por exemplo, simplesmente desejar en-contrar todos os filhos de um determinado nodo ou realizar uma busca mais complexa,como descobrir todos os filhos dos irmãos de seus ancestrais. Desta forma, a linguagemXPath provê um meio de unir os vários comandos para a composição destas expressões.Este é chamado de location path (ou caminho de localização) e consiste de um ou maiscomandos separados pelo carácter ’/’ (barra), sendo avaliados da esquerda para a direita.Define-se que um caminho de localização é absoluto quando inicia por ’/’, significandoque parte do nodo raiz do documento XML. Caso contrário o caminho é relativo, o quequer dizer que se está lidando ou com uma localização previamente definida, ou com araiz do documento, caso nenhuma tenha sido especificada.

Expressões XPath com o uso da sintaxe expandida são bem intuitivas e fáceis de


utilizar, entretanto um pouco trabalhosas no sentido de que à medida que crescem, suarepresentação pode se tornar muito repetitiva e sua descrição, exaustiva. Devido a tal fato,pode-se empregar a sintaxe abreviada, facilitando a construção de expressões grandes. ATabela 2.2 apresenta os comandos abreviados, juntamente com sua função correspondente.

Tabela 2.2: Comandos XPath da sintaxe abreviadaAbreviação Axis Correspondente

// descendant. self.. parent@ attribute

(vazio) child

Desta forma, alguns dos comandos podem ser simplificados para uma notação maisenxuta, tornando possível a utilização de uma mistura da sintaxe abreviada para algunscomandos e a expandida para os demais que não possuem uma correspondente represen-tação na primeira.

2.5.2 XSLT

XSLT (Extensible Stylesheet Language Transformation) [21] é uma recomendaçãoW3Cdesignada para aplicar transformações em documentos XML. O próprio XSLT é baseadoem XML e foi desenvolvido com o intuito de transformar um documento XML em HTMLou XSL-FO (Seção 2.5.3), desta maneira expressando a forma como seria visualizado oconteúdo encapsulado. Entretanto, sua aplicação foi expandida para a transformação deum documento XML em qualquer outro formato de texto, como WML (Wireless MarkupLanguage) [22], XHTML, texto puro, entre outros. Para realizar tal feito, esta tecnologiase aproveita do fato de que um documento XML contém apenas o conteúdo e nenhumareferência sobre sua formatação, possibilitando a conversão dele para qualquer formatode apresentação.

Além disso, o XSLT é amplamente utilizado para transformações de documentos XMLem outros documentos XML, sejam eles mais simples, mais complexos ou com represen-tações particulares. Como visto anteriormente, a tecnologia XML trouxe a liberdade decriar tags arbitrárias para ampliar a sua área de aplicação. Devido a tal fato, diferentesusuários podem representar o mesmo conteúdo através de estruturas distintas, provocandoa necessidade de um processo de transformação, para que a aplicação de um possa utilizarum certo documento de outro. Por exemplo, no caso de duas empresas: a primeira poderepresentar seus funcionários com o uso da tag <funcionario>, enquanto a segunda podedescrevê-los com o auxílio da tag <empregado>. Nota-se que neste caso o uso de DTDnão se aplica, pois sua função não é estabelecer uma forma única para a representaçãodo conteúdo, o que não seria possível, mas sim determinar a maneira correta de utilizaro XML criado por um usuário em uma situação específica (por exemplo, em determinadaaplicação). Aqui se está lidando com a situação de diferentes maneiras de se representar o


conteúdo, para o utilizá-lo em aplicações distintas. Isto pode naturalmente se diferenciar,pois cada usuário terá a sua própria maneira de estruturar o documento XML.

Por outro lado, o XSLT não é somente utilizado para realizar transformações, mastambém se aplica a circunstâncias em que se deseja descobrir informações de um certodocumento XML, como, por exemplo: quantos funcionários a empresa possui, qual o nomedo funcionário com algum RG específico, quem são todos os gerentes da empresa ou quala soma dos salários de todos que participam dela. Neste sentido, a noção de XSLT seaproxima muito de querys de banco de dados e por isso é classificado, também, como umalinguagem de query XML. Inicialmente, XSLT não apresentava a base necessária parasuportar tal funcionalidade, conforme descrito em [23], entretanto, a versão atual contémas primitivas necessárias, tornando-o hábil a realizar buscas complexas no documento deforma eficaz.

A fim de prover as funcionalidades apresentadas acima, o XSLT utiliza o conhecimentoobtido pelo uso de XPath no documento XML. O XPath é um elemento chave nestalinguagem e sem este não é possível criar documentos XSLT para efetuar as transformaçõesou buscas.

Como mencionado anteriormente, a saída de uma transformação é o resultado doprocessamento do XSLT sobre um documento XML. Esta execução é realizada por umcomponente chamado de XSL Processor (seção 2.5.4), que tem como entrada os documen-tos XML e XSLT (ou XSL-FO). É importante ressaltar que o documento XML de entradanão é modificado durante a computação, pois sempre é gerado um arquivo de saída novo,contendo os resultados da aplicação das transformações. Assim, para um mesmo docu-mento XML podem haver diversos XSLT permitindo distintas transformações sobre osmesmos dados.

A linguagem XSLT utiliza uma forma modular de implementação, contendo diversoscomponentes templates, nos quais são especificados padrões de ocorrência (matching pat-terns) que definem quando cada template deve ser instanciado. Todos os padrões sãodescritos pelo uso de expressões XPath. Dentro de um template são colocados trechosde código descrevendo alguma transformação. Por default o template instanciado quandoiniciada a transformação é aquele que possui o padrão ’/’, referente a raiz do documento.A Figura 2.8 apresenta os módulos descritos.

Assim que o template inicial é instanciado, é necessário aplicar os demais templatesatravés de uma chamada explícita. Para tanto, existe uma função específica do XSLT(apply-templates), onde é passado um conjunto de nodos (através de uma expressãoXPath) por parâmetro. Assim, o XSLT, basicamente, procura o template com o pa-drão de ocorrência que melhor se encaixa com estes nodos, instanciando-o. No caso emque se encontre um template que sirva, muda-se o contexto para o nodo que se encaixoucom o padrão dele e realiza-se o processamento descrito. Da mesma forma, neste passo,novas aplicações de template podem ser realizadas. A Figura 2.9 ilustra, então, para o


Figura 2.8: Estrutura modular do XSLT

exemplo anterior a chamada apply-templates.Pode-se analisar que o parâmetro select, leva em consideração que o nodo atual é

aquele especificado pelo padrão de ocorrência do template em que está contido. Destamaneira, é possível utilizar caminhos relativos ao nodo contexto ou caminhos absolutos,ignorando o nodo contexto atual e partindo-se da raiz do documento XML. Da mesmaforma, ambas as representações de caminhos podem estar presentes nos matching patternsdos templates.

Figura 2.9: XSLT Apply-templates

Além do apply-templates, o XSLT provê funcionalidades, como: condicionais baseadosem valores dinâmicos obtidos através do documento XML, como if e choose (equivalenteao switch case de C); definições de variáveis estáticas, com valores pré-fixados, ou dinâ-micas, obtidas por um valor lido do XML, para realizar conversões de tipos, operaçõesaritméticas, etc.; laços sobre elementos do documento e ordenações nos valores de cadanodo do XML.


2.5.3 XSL-FO

A linguagem XSL-FO (Extensible Stylesheet Language Formatting Objects) [24] trata-se de uma recomendação W3C e é utilizada para descrever o layout e formatação doconteúdo, o qual se está encapsulando. XSL-FO é inteiramente baseado em XML, fa-cilitando o uso de XSLT para transformar um determinado conteúdo estruturado peloXML em um documento XSL-FO contendo as diretivas referentes a apresentação do con-teúdo. Entretanto, não é preciso utilizar a linguagem XSL-FO somente para formatardeterminado conteúdo descrito pelo uso de XML, podendo ser destinada a uma situaçãoem que se tenha, por exemplo, texto puro. Devido a sua proveniência ser de lingua-gens presentes a muito tempo no mercado, como o DSSSL e o CSS, sua especificação foicriada com o uso da experiência adquirida pela aplicação destas a diferentes situações.Deste modo, o XSL-FO foi desenvolvido atendendo diversas necessidades específicas dosusuários, cobrindo todos os pontos fracos apresentados pelas linguagens anteriores.

Assim como seus predecessores, para que um documento XSL-FO seja inteligível aum leitor humano ou impresso de forma correta é necessário um processo de renderização.Neste caso, traduz-se os comandos expressados pelo XSL-FO para um formato visualizável.Na situação em que o conteúdo a ser formatado trata-se de um documento XML, todasas tags arbitrárias devem ser eliminadas, filtrando apenas o conteúdo de interesse, pois aengine de renderização não será capaz de interpretá-las.

Em termos de formatação, a linguagem XSL-FO organiza o conteúdo de forma pagi-nada. Assim são fornecidas diretivas elementares de navegação em páginas, como númera-ção, cabeçalhos, rodapés, entre outras. Por outro lado, o XSL-FO não se preocupa em quetipo de media o documento formatado irá ser visualizado, mas apresenta uma abordagemgenérica para qualquer um deles. É a engine de renderização, a responsável pelo formatode resultado que irá ser gerado, seja ele uma página da internet ou um documento a serimpresso.

Com o uso da linguagem XSL-FO as seguintes seções de um documento são descritas:

• Páginas: as próprias páginas de um documento, cada uma delas contendo regiões;

• Regiões: descrevem diferentes regiões de uma página, cada uma delas contendoblocos;

• Blocos: apresenta outros blocos, linhas, parágrafos, tabelas e listas;

• Linhas: descreve textos numa linha e podem conter elementos inline;

• Elementos Inline : elementos dentro de uma linha, como símbolos, textos comformatações específicas, etc.

A Figura 2.10 ilustra os alguns dos diferentes elementos [24], referentes a paginação,que em conjunto formam um componente XSL-FO.


Figura 2.10: Componentes de um documento XSL-FO

Um elemento XSL-FO é encapsulado pela tag fo:root. Logo após, encontra-se a tagfo:layout-master-set que contém diversos templates de páginas, especificando formataçõescomo o tamanho das margens, a altura e largura das páginas. Estes são descritos pelouso da tag fo:simple-page-master, onde as diversas regiões de uma página podem serformatadas independentemente umas das outras. Estas tags possuem um atributo master-name onde se define um nome único para refenciá-las, aplicando assim a formataçãoestabelecida. No escopo de um fo:simple-page-master, a Figura 2.10 demonstra as regiõesexistentes em uma página. Um exemplo comum da disposição destas regiões seria o casoem que a região fo:region-start significaria a parte esquerda da página, fo:region-end, adireita, fo:region-before, o topo, fo:region-after, a base e a fo:region-body o meio (Figura2.11).

Figura 2.11: Exemplo de disposição das regiões XSL-FO em uma página

Contudo, a porção referenciada por uma determinada região do XSL-FO é dinâmica,podendo assumir diferentes valores conforme alguns parâmetros especificados na definiçãodo layout da página. Assim, é possível rotacionar as regiões, informando, por exemplo,uma configuracão alternativa em que fo:region-start correspondesse à porção direita dapágina, fo:region-end à esquerda, fo:region-after ao topo e fo:region-before à base. Comisso, o usuário obtém ummaior controle quanto a configuração da estrutura de cada páginado documento. Além disso, o XSL-FO permite especificar a direção do texto contido em


uma região. Isto ocorre devido ao suporte a internacionalização provido pela linguagem.Assim, é possível formatar documentos em que o texto é apresentado por exemplo, dadireita para esquerda (no caso de uma língua árabe) ou de cima para baixo (no caso dalíngua chinesa). É devido a estas características do XSL-FO que os termos utilizadosno âmbito da linguagem fornecem uma idéia mais ampla e não prefixam as porções dodocumento, como com o emprego de left, right, top e bottom.

Outro elemento que pode estar contido dentro de um fo:layout-master-set é o fo:page-sequence-master, que define um tipo de paginação mais complexo. Todos os filhos deste,especificam regras quanto a geração de um documento, possuindo um atributo que refere-se a um nome único, utilizado para a aplicação de cada um deles. Além disso, estes nãoestabelecem a formatação propriamente dita de cada página e para tanto referenciamum fo:simple-page-master. São estes: fo:single-page-master-reference, fo:repeatable-page-master-reference e fo:repeatable-page-master-alternatives.

No caso do uso de fo:single-page-master, é definido que para aquele que o referencia,apenas será gerada uma única página. Se o conteúdo especificado ultrapassar este limiteum erro será gerado. Com o uso de fo:repeatable-page-master-reference são geradas de 0até N páginas, onde N é um valor pré-definido pelo usuário. Se N for ultrapassado, um erroserá gerado, caso contrário não, mesmo que o número de páginas for menor que N. Por fim,fo:repeatable-page-master-alternatives define diversas alternativas de formatação para umapágina, quando uma determinada regra for encontrada. Estas são representadaspela tag fo:conditional-page-master-reference que referencia um fo:simple-page-master aser utilizado. Esta regra pode ser, por exemplo, aplicar uma formatação quando a páginafor par e outra quando for ímpar.

No conteúdo de uma página, diversos modos de cores diferentes podem ser aplicados,como RGB (Red, Green and Blue), CMYK (Cyan, Magenta, Yellow and Key) ou algumpersonalizado. Entretanto, para utilizá-los, estes devem ser explicitados através do usodo elemento fo:declarations. Esta tag é opcional, mas se utilizada pode conter um oumais fo:color-profile que especificam um tipo de cores específico. Quando instanciado oconteúdo no XSL-FO, pode-se então, referenciar os diferentes modos conforme desejado.

Por fim, tem-se a definição de um conjunto de páginas através da tag fo:page-sequence,que referencia algum elemento do fo:layout-master-set para definir a formatação de cadauma delas. Em um mesmo documento XSL-FO podem existir diversas fo:page-sequences.Nestas, pode ser definido um fo:title, que não produz uma saída diretamente visível nodocumento, mas uma propriedade. Assim, permite-se adicionar informações para des-crever o conjunto correspondente, como uma espécie de comentário em uma linguagemde programação. Além disso, tem-se a tag fo:static-content que referencia uma regiãoda página, especificando dados que podem ser reutilizados no conjunto subseqüente dafo:page-sequence, como cabeçalhos e rodapés. Por outro lado, o elemento fo:flow defineo conteúdo distinto de uma determinada região das páginas. Cabe ressaltar que, caso


o conteúdo descrito neste elemento ultrapasse uma página, são instanciadas tantas ou-tras quantas necessárias, sendo preenchidas com o restante do conteúdo se a formataçãoespecificada pelo elemento do fo:layout-master-set referenciado permitir.

No contexto de cada fo:flow tem-se um ou mais parágrafos, representados pela tagfo:block e neste podem ser definidos diferentes aspectos do bloco, como margens, bordas,fontes, alinhamento, etc. Estes podem ser compostos unicamente por texto, tabelas oulistas. Além disso, o XSL-FO provê uma maneira de formatar apenas uma parte doconteúdo contido dentro de um bloco, através dos elementos inline, definidos pela tagfo:inline. Estes podem ser utilizados, por exemplo, para definir um pedaço do texto comuma formatação específica, como negrito ou itálico.

2.5.4 Processadores XSL

Atualmente, existem duas categorias distintas de processadores XSL: os que lidamcom XSLT e os que lidam com XSL-FO. Os primeiros são responsáveis por realizar astransformações descritas nos documentos XSLT, enquanto os segundos devem gerar umdocumento inteligível e visualizável a partir das primitivas de formatação.

Os processadores XSLT normalmente recebem como entrada um documento XML eoutro XSLT, apesar de existir a possibilidade de criar documentos XML com as diretivasde transformação integradas nos próprios. Separar o o documento XML do XSLT, facilitaa criação de diversas transformações distintas para o mesmo conjunto de dados XML,por isso é preferível. Devido a necessidade de verificar se o XML de entrada e o própriodocumento XSLT são documentos XML bem formados, estes processadores incluem umparser XML que garante tal requisito, antes de ser aplicada quaisquer transformações.Para facilitar a transformação dos documentos, o arquivo XML de entrada é lido parauma estrutura em árvore (chamada de source tree), através da utilização de um parserXML da categoria DOM. Tendo isto em mãos, o processador XSLT pode então, navegarnesta, aplicando os templates especificados na linguagem de transformação. Assim, cria-seuma nova árvore como resultado, chamada de result tree. Esta pode, então, ser escritaem um arquivo, enviada a outro determinado fluxo de saída ou repassada para um outrodocumento XSLT.

Os processadores XSL-FO recebem como arquivo de entrada um único documentoXSL-FO, para então processar a formatação especificada. Isto ocorre, pois o conteúdo aser formatado já está presente neste documento, juntamente com as diretivas de forma-tação. Neste caso também é necessário a utilização de um parser XML, avaliando se opróprio documento XSL-FO de entrada trata-se de um XML bem-formado. Normalmente,estes processadores oferecem uma variada gama de formatos de saída, o que é possíveldevido a flexibilidade da linguagem XSL-FO. Através da leitura do arquivo de entrada égerada uma árvore (source tree), onde cada nodo é um objeto com o conteúdo e a for-


matação correspondente. A partir desta árvore, de forma iterativa cria-se outra (resulttree), definindo como os objetos devem ser exibidos, com suas posições, cores, bordas,margens, etc. A leitura desta árvore demonstra, então, o documento final e como ele seráapresentado. A computação realizada pelos processadores XSL-FO é conhecida como umtipo de renderização e na linguagem comercial os próprios são chamados de engines derenderização.

2.6 PODi

Com o mesmo propósito do W3C, PODi (Print On Demand Initiative) [25] foi criadoem 1996, com o intuito de criar padrões e descobrir a melhor maneira de utilizar asdiversas tecnologias existentes no mercado. Entretanto, esta iniciativa voltou-se paraum âmbito diferente do W3C, focando na impressão digital de documentos. O PODireúne diversas empresas atuantes no mercado de impressão, formando um consórcio comfins não lucrativos. São membros deste grupo grandes empresas como: Adobe, Canon,HP (Hewlett-Packard), Xerox e Kodak. Através do PODi, os participantes podem trocarexperiências e publicar estudos realizados no cenário de interesse. Através de tais pesquisaso grupo PODi promove guias, artigos, relatórios e conferências, relatando as melhorespráticas para as tecnologias presentes no mercado. Estes resultados são disponibilizadospara os membros do grupo, que podem então aplicá-los no funcionamento geral de suaempresa.

Além disso, o PODi é responsável por criar padrões e tecnologias, ambos abertos aopúblico em geral, que melhor se encaixam e suprem as necessidades existentes de empresasinteressadas na área de impressão digital. O consórcio é responsável pelo desenvolvimentode linguagens baseadas em XML, que é um padrão já consolidado, promovendo caracte-rísticas desejáveis no âmbito de impressão digital de documentos como a flexibilidade e aextensibilidade.

2.7 PPML

PPML (Personalized Print Markup Language) [26] é uma linguagem baseada em XMLdesenvolvida pelo PODi para a criação de um ou mais conjuntos de documentos perso-nalizados de alta definição. Uma de suas grandes vantagens trata-se da possibilidade dedescrição de objetos reutilizáveis, que podem ser referenciados pelos documentos, dimi-nuindo assim a redundância e o tamanho dos documentos a ser impresso. Tal facilidadeotimiza o processo de impressão como um todo, pois estes objetos são processados umaúnica vez pela impressora, que os armazena na sua cache, acessando-os quando necessário.Além disso, esta linguagem não pré-estabelece o formato do conteúdo dos documentos,


mas oferece meios para apenas demarcar a área ocupada por ele no documento, flexibili-zando o uso de qualquer linguagem para descrevê-lo.

Por ser baseado em XML, o PPML é uma linguagem hierárquica, que utiliza tagsaninhadas para encapsular o conteúdo pertinente a cada situação. Em um documentoPPML, a tag root trata-se da <ppml>. Dentro desta podem haver um ou mais conjun-tos de documentos, cada um deles contidos na tag <document_set> ou <job>. Estastags são sinônimos, portanto qualquer uma delas pode ser empregada para o mesmo fim.Normalmente, a formação de um conjunto refere-se ao tratamento dos documentos nelecontidos como uma unidade única, por exemplo, quando são destinados ao mesmo cliente.Entretanto, o agrupamento dos documentos não é sempre necessário, portanto pode-seomitir tais tags, definindo um único conjunto diretamente dentro da <ppml>. Neste sen-tido, cada documento é descrito com o uso da tag <document>, demarcando um conjuntode páginas relacionadas. Estas são formadas pela tag <page>, cada uma contendo uma<page_design> e uma ou mais tags <mark>. A primeira descreve a área retangularda página que o conteúdo vai ocupar, através de parâmetros como a largura e altura dapágina. Além disso, pode-se definir áreas de sangramento (bleeding areas), que são aque-las que ultrapassam a área retangular previamente estabelecida. Os segundos tambémdefinem áreas retangulares, mas dentro de um <page_design>, que serão preenchidascom o conteúdo propriamente dito. Este conteúdo pode tratar-se de qualquer formato,como uma imagem, um componente XSL-FO ou elemento já renderizado. A Figura 2.12apresenta a estrutura de um documento PPML descrito até então.

Figura 2.12: Estrutura inicial de um documento PPML

Como mencionado anteriormente, com o uso de PPML é possível estabelecer objetosreutilizáveis (reusable objects), que serão referenciados no contexto de cada documento.Estes objetos são definidos através da tag <reusable_object>, que contém zero ou umaview, um ou mais objetos filhos e uma lista opcional com diferentes views associadas a


cada destes. As views são elementos que determinam se alguma transformação ou corteserão feitos no objeto que referenciam. Neste sentido, a view de um reusable object édescrita através da tag <view>, os objetos contidos nele são delimitados por <object> eas views de cada elemento <object> são apresentadas por uma lista <occurrence_list>que contém uma ou mais tags <occurrence>, referenciando um dado objeto. Sendo as-sim, cada elemento <occurrence> terá uma <view>. O formato dos objetos, é definidoatravés de uma tag <source> que este engloba e o próprio conteúdo pode ser descritodiretamente ou referenciado através de um arquivo externo que o possui. Para tanto, astags <internal_data> e <external_data> são utilizadas respectivamente.

Um reusable object pode ser especificado no domínio de um PPML inteiro, de um<document_set> (ou <job>), de um único documento ou de uma página. Neste sentido,existem diversas políticas para melhor definir e distribuir os reusable objects em um PPML,melhorando o desempenho do processo de impressão. Tais políticas fogem do escopo destetrabalho, para tanto o autor se refere a [27].

Com a finalidade de utilizar os reusable objects definidos, deve-se referenciá-los dentrode um <mark>. Isto é realizado através da tag <occurrence_ref>. Por outro lado, nãoé mandatório que um <mark> deva referenciar um reusable object, podendo conter ele-mentos <object>, descrevendo o conteúdo diretamente. A Figura 2.13 ilustra a estruturacompleta de um documento PPML, a partir dos elementos apresentados.

Figura 2.13: Estrutura final de um PPML


2.8 PPMLT

PPMLT (Personalized Print Markup Language-Template) [28, 29] trata-se de um pa-drão PODi, empregado na descrição de templates que servirão para a criação de docu-mentos personalizados. É baseado totalmente em XML e foi desenvolvido com o intuitode facilitar o processo de criação, tornando possível o processo de design do documentoantes mesmo de se obter todas as informações variáveis de cada um deles.

Este formato pode ser dividido em três porções representativas, encapsuladas pela tagroot <ppmlt>: Template, Data-Mapper e Data. O primeiro elemento, expressado com ouso da tag <template>, descreve o protótipo de um documento PPML, definindo suas asporções fixas e dinâmicas (personalizáveis). Este protótipo será combinado com os dadoscontidos no próprio documento PPMLT (presentes na porção Data), gerando diversasinstâncias de documentos PPML. Para realizar tal feito, o PPMLT utiliza a linguagemXSLT, que descreve as porções variáveis dos documentos. Ainda mais, através do auxíliodesta é possível aumentar o grau de flexibilidade do documento, fazendo com que o mesmoapresente layouts variados conforme os dados presentes na seção Data. Por exemplo, seos dados descrevem clientes de uma loja qualquer, é possível adaptar o PPML geradopassando uma mensagem se o cliente for do sexo masculino e outra, se feminino.

O elemento Data-Mapper é descrito pelo uso da tag <data_mapper> e tem a funçãode mapear o conteúdo presente no elemento Data para o próprio template. Este elemento éopcional, pois tal mapeamento pode ser feito diretamente com uso de XSLT, estabelecendocertas condições para a aplicação que processa o documento PPMLT ser capaz de entenderqual campo, definido na porção Data, corresponde a cada parte variável do template.

Figura 2.14: Records de um PPMLT

Por fim, a seção Data é definida pela tag <data>, podendo conter dados externos,presentes em outro arquivo, ou internos definidos no próprio PPMLT. Se externos, é feitoo uso da tag <external_data> referenciando um arquivo, caso contrário, da tag <inter-nal_data>. Na última o conjunto de informações é descrito diretamente no PPMLT.Neste sentido a tag <records> engloba um ou mais elementos <r> (representando um


record), cada um deles responsáveis por gerar uma instância de documento PPML. Nocontexto de um record são definidas diversas tags, cada uma delas com o nome referenteao campo que representam na instância de documento e contendo o valor do dado campo.A Figura 2.14 apresenta uma estrutura válida de um documento PPMLT, exemplificandoo formato dos elementos <r>.

A utilização de PPMLT oferece uma grande vantagem quanto ao tamanho em discoque um documento irá ocupar. A Tabela 2.3, retirada de [29], demonstra a significativadiferença de tamanho quando comparado a um simples PPML.

Tabela 2.3: Comparativo do tamanho de um arquivo PPMLT e um PPML25 documentos 1.000 documentos 10.000 documentos 100.000 documentos

PPMLT 18Kb 154Kb 1,41Mb 14MbPPML 140Kb 4,52Mb 45Mb 450Mb

2.9 PDL

PDL (Page Description Language), também conhecido como PCL (Printer ControlLanguage), trata-se de uma linguagem de alto nível de abstração, utilizada para descrevero conteúdo de uma ou mais páginas. Através do emprego deste tipo de linguagem, o textoe imagens de um documento são descritos através de comandos específicos, ao invés deum mero conjunto de pontos (Figura 2.15). Estes comandos são computados na própriaimpressora, que através de um processo de rasterização gera a sua representação específicado documento a ser impresso.

Figura 2.15: Impressão de dados com e sem o uso de PDL

Sem o auxílio deste tipo de tecnologia, para se imprimir um objeto, como, por exemplo,uma frase, seria necessário enviar todos os pontos da página que este irá ocupar, paraque então, a impressora os lesse e conseguisse imprimí-los. Assim, esta abordagem trariadiversas limitações, pois conforme o tamanho do documento crescia, a informação enviadapara as impressoras se tornava gigantesca, prejudicando o desempenho da impressão dele.Além disso, à medida que se desejava utilizar uma resolução maior para as imagens e ostexto contidos no documento, maior era o conjunto de pontos submetidos a impressora,atrasando mais ainda a impressão do documento.


PDL otimiza o processo de impressão por diminuir a quantidade de informação aser transmitida para o dispositivo e facilita a capacidade de integração com esquemascomplexos de texto e imagem. Esta linguagem flexibiliza o uso de altas definições deobjetos de um documento e é independente do dispositivo no qual será impressa, portantoportável. Dois exemplos de PDL são o PDF (Portable Document Format) [30] e o PS(PostScript) [31].

2.10 SVG

SVG (Scalable Vector Graphics) [32,33] trata-se de um tipo de PDL com grande aplica-ção na área de impressão de documentos digitais. É uma linguagem open source utilizadapara descrever gráficos bidimensionais. O único PDL baseado totalmente em XML, SVGfoi desenvolvido pelo grupo W3C com amplo suporte empresarial, como Adobe, Apple,HP, IBM, Microsoft, entre outras. Estas organizações trabalharam em conjunto com oW3C para tornar o SVG no formato padrão para a descrição de gráficos vetoriais. Ini-cialmente esta tecnologia surgiu para ser utilizada na internet, entretanto sua aplicaçãoextrapolou tal ambiente, sendo incorporada à diversos outros cenários, entre eles o deimpressão digital de documentos variáveis.

Com o uso de SVG podem se obter gráficos de alta qualidade que independem deresolução. A tradução literal para o acrônimo SVG nada mais é do que gráficos vetoriaisescaláveis. Em outras palavras, um gráfico escalável significa que ao aumentar ou dimi-nuir a resolução da imagem, não haverá perda quanto a definição da mesma. Isto ocorre,porque esta linguagem utiliza instruções baseadas em vetores (portanto gráficos vetoriaisescaláveis) para descrever os objetos contidos na imagem, diferentemente de outros for-matos de imagens (formatos bitmap) como GIF (Graphics Interchange Format) , JPEG(Joint Photographics Experts Group) e PNG (Portable Network Graphics) , que utilizamuma matriz de pontos (pixels) individuais que compõe uma imagem. No caso de SVG,ao ocorrer alguma mudança na resolução, as instruções descritas por este formato são ca-pazes de se adaptar, enquanto no caso do uso da matriz, os pixels são apenas replicados,causando uma perda de definição da imagem em questão (Figura 2.16). Com isso, é pos-sível imprimir gráficos SVG em qualquer resolução sem a perda de definição, nem o efeito’pixelado’ (ou ’escadinha’) que pode ser observado em formatos bitmap. Além disso, porbasear-se em XML, a tecnologia SVG contém muitos fragmentos de texto repetidos, o quefacilita a sua compressão, tornando-o significantemente menor do que formatos bitmap.

Existem três tipos de objetos que podem ser descritos pelo uso de SVG: formas gráficasvetoriais (compostas por linhas e curvas), imagens (podendo incluir imagens de outroformato, como JPEG e PNG) e texto. Estes objetos podem ser agrupados, estilizados etransformados (com a aplicação de filtros de imagens, máscaras, regiões de corte, etc).Por ser baseado em XML, o usuário pode facilmente manipular ou visualizar seus objetos


Figura 2.16: SVG versus bitmap

através da utilização de um parser DOM, que provê acesso aos atributos, propriedadese elementos da árvore XML descrita pela linguagem. Além disso, é um formato que éfacilmente integrado com os demais padrões XML, como por exemplo, XSLT e XSL-FO. Ouso desta linguagem provê outras funcionalidades como o suporte a animações e interaçãocom o usuário. Uma área amplamente beneficiada pelas características do formato SVGtrata-se da geografia, mais especificamente da cartografia [34], onde técnicas como o Zoompodem ser aplicadas sem a perda de definição da área a qual se está analisando.

Contudo, a linguagem SVG ainda apresenta algumas limitações quanto ao suporte paraanimações, interabilidade e alguns aspectos para flexibilizar a visualização de imagensem diferentes formatos de tela. Todavia, por ter como base o XML, é uma linguagemextensível, facilitando a criação de novas funções para lidar com os problemas correntes.O CSVG (Constraint SVG) [35] trata de alguns dos problemas existentes do formato SVGe mantém a compatibilidade com o SVG original. Entretanto, o uso de SVG puro já provêtodos os requisitos necessários para a impressão digital de documentos variáveis de altadefinição, não sendo necessário (até então) o uso de tais extensões.

3 Abordagem Proposta

Neste Capítulo propõe-se estudos e novas estratégias referentes ao funcionamento deferramentas e documentos ligados ao escopo da renderização de documentos. A rende-rização por si só trata-se do processo de interpretação de uma determinada linguagemde formatação crua, objetivando apresentar o conteúdo por ela encapsulado de forma in-teligível a um leitor humano. Esta computação é empregada no pré-processamento dedocumentos personalizáveis, permitindo que estes sejam impressos. Como apresentadoanteriormente, existem diversas tecnologias que podem estar presentes na construção deum documento variável.

Este Capítulo fornece, em um primeiro momento, uma breve apresentação sobre aslinguagens aplicadas aos arquivos de entrada utilizados neste estudo e aos arquivos de saídaresultantes. Logo após, descreve o funcionamento da ferramenta seqüencial responsávelpor efetuar a renderização dos documentos, seguindo da métrica escolhida para medir ocusto computacional associado ao processamento de cada um destes. Por fim, discorresobre nova estratégia paralela proposta para acelerar a computação.

3.1 Estrutura dos Arquivos de Entrada e Saída

Neste trabalho, os documentos de entrada utilizados pela versão seqüencial, paralelae para validar a métrica proposta são compostos pela união das tecnologias PPMLT eXSL-FO. Tal escolha foi feita, pois esta situação representa a grande maioria dos casosde diversas print shops que utilizam a técnica de VDT. Com esta combinação, é possívelalcançar um alto grau de flexibilidade, reusabilidade e otimização de impressão. Nestecontexto, a linguagem PPMLT é responsável por descrever o conteúdo estático de umdocumento, enquanto o XSL-FO é aplicado na formatação do conteúdo dinâmico encap-sulado dentro de cada <mark> do próprio PPMLT. Além disso, por este trabalho focarexatamente na fase de renderização do processo de impressão, o conteúdo personalizadoproveniente da base de dados já está contido em todos os arquivos de entrada. Mais espe-cificamente, o elemento <data> do template descrito através de PPMLT, já contém todosos records necessários para gerar um número determinado de instâncias de documentosde um job a ser impresso. Assim, cada instância gerada terá o formato PPML, contendopartes descritas pela linguagem XSL-FO.

29

3. Abordagem Proposta 30

Por outro lado, este estudo será focado para o processo de renderização dos elementosXSL-FO para um PDL específico. Um dos PDLs mais utilizados no âmbito da impressãodigital trata-se de SVG, por apresentar características como, extensibilidade, flexibilidadee capacidade de descrição de gráficos de alta qualidade. Portanto, a saída gerada pelasferramentas trata-se de um conjunto de documentos definidos em um arquivo PPML, cadaum contendo porções descritas em linguagem SVG.

3.2 Composition Tool

Composition Tool (CTool) é a aplicação responsável por realizar a renderização de ar-quivos PPML ou PPMLT. Por lidar com estas tecnologias, a ferramenta engloba um parserXML, para verificar a corretude do documento de entrada, um processador XSLT, res-ponsável por aplicar as diretivas especificadas pela linguagem XSLT presentes no PPMLTe um processador XSL-FO que realiza a renderização dos componentes necessários. ACTool utiliza um parser XML do tipo SAX, obtendo a capacidade de lidar com do-cumentos grandes e entre os diversos processadores XSL-FO disponíveis e a engine derenderização adotada trata-se da aplicação FOP (Formatting Objects Processor) [36]. Aferramenta FOP é capaz de renderizar elementos XSL-FO para uma variada gama deformatos PDL, entre eles SVG. É uma aplicação Java open source, implementada com ouso de padrões de programação, sendo flexível e extensível.

Considerando a situação em que o formato do arquivo de entrada é um PPMLT, o pro-cessamento realizado por esta ferramenta pode ser divida em duas fases complementares.A primeira fase corresponde a geração das instâncias de documentos descritos pela lin-guagem PPML, contendo os dados pertinentes a cada uma delas. Ao receber um PPMLT,toda a formatação, mapeamento e dados estão dispostos separadamente nos componen-tes correspondentes. Para cada elemento <r>, descrito no PPMLT é necessário geraruma instância de documento <document> no PPML de saída. Portanto, primeiramentea CTool aplica o template de documento descrito a cada record existente no PPMLTgerando diversos elementos <document>, cada um representando um documento real deum job. Os dados gerados não são armazenados na memória, pois podem ser muitograndes, mas são escritos em disco, sendo utilizados como entrada na próxima fase deprocessamento. A primeira fase é ilustrada na Figura 3.1.

Com isso, é realizada a segunda parte do processo em que é necessário efetuar a ren-derização propriamente dita. Analisando o documento PPML de saída pode-se perceberque ele possui a mesma estrutura do PPML de entrada, mas com as porções descritas porXSL-FO substituídas por SVGs correspondentes. Assim, o processamento consiste em umparse do documento de entrada, copiando as porções PPML diretamente para o arquivode saída e quando encontrado um XSL-FO, extraindo-o para renderizá-lo. Para tanto,à medida que não aparecer nenhum conteúdo renderizável, a aplicação simplesmente o


Figura 3.1: Primeira fase do processamento da CTool

escreve no arquivo de saída. Assim que encontrada a tag correspondente ao início de umXSL-FO (a tag <fo:root>), passa-se a armazenar todo o conteúdo em um buffer tempo-rário até que se encontre o final da mesma (</fo:root>). Este buffer, então, é repassadoa engine de renderização, que retorna um SVG correspondente. O resultado é recolo-cado em sua posição original e o processo continua. A segunda fase do processamento éapresentado na Figura 3.2.

Figura 3.2: Segunda fase do processamento da CTool

3.3 Métrica

Com o objetivo de definir uma métrica que seja capaz de prever o esforço gasto narenderização de um job, uma análise sobre os passos desta computação e da estrutura daentrada do programa deve ser realizada. Como visto anteriormente, um arquivo PPMLTé composto basicamente por um template de documento que será aplicado a todos osrecords existentes. O resultado será um conjunto de documentos <document> que estarãodispostos em um arquivo PPML. Esta fase trata-se simplesmente da aplicação de umlayout específico preenchendo as lacunas com os dados variáveis disponíveis. Em outraspalavras, se refere apenas a leitura de um arquivo XML e escrita de outro em disco. Paraavaliar o impacto desta fase quanto ao tempo total de execução, medições foram realizadase são apresentadas na Tabela 3.1.

Como se pode observar, a geração de uma grande quantia de documentos ultrapassapor pouco os 2 minutos e em nenhum dos casos apresentados é representativo se comparado


Tabela 3.1: Tempo gasto na primeira fase versus tempo de execução totalNúmero de Documentos Tempo da Primeira Fase (segundos) Tempo Total (segundos)

1000 7,50 758,465000 32,13 2444,2410000 63,76 4875,7420000 124,87 9478,31

ao tempo total de execução da CTool. Devido a tal constatação, pode-se concluir que amaior parte da computação está focada na próxima fase do processamento.

A segunda fase é inteiramente focada sobre as porções XSL-FO de cada documento.Como mencionado anteriormente, nesta fase, a CTool busca por estes componentes emcada instância de documento do job, para então submetê-los a engine FOP. Esta realizaa renderização e retorna um SVG que será escrito no documento final. Desta maneira,à medida que a computação dos XSL-FOs se torna mais custosa, mais tempo será gastono processamento do job inteiro. Assim, deve-se analisar qual característica influencia nopeso da renderização de um componente XSL-FO.

Na maioria dos casos da impressão digital de documentos, os XSL-FOs são consti-tuídos puramente por texto, fazendo com que o trabalho da engine seja a aplicação daformatação especificada para cada palavra descrita. Além disso, é responsabilidade daengine posicionar o texto dentro da página de um documento, construindo parágrafos elinhas na área reservada de cada XSL-FO. Deste modo, à medida que a quantia de textoaumenta, a engine terá mais trabalho para fazer, se preocupando em formatar e posici-onar mais conteúdo. Assim, um dado consistente para medir o esforço gasto na fase derenderização trata-se do número de palavras contidas dentro de todos os XSL-FOs doarquivo de entrada. Para avaliar esta métrica testes foram realizados e seus resultadossão apresentados no Capítulo 4.

3.4 Solução Paralela

Em estudos passados [1, 2], foram apresentadas estratégias para melhorar o desem-penho do processo de renderização. Estas, foram implementadas no nível de XSL-FO,significando que o parse e escrita no arquivo de saída eram centralizados em dois compo-nentes, enquanto as engines de renderização eram replicadas. Contudo, à medida que otamanho dos documentos passava a crescer, estes dois processos responsáveis pelas fun-ções de parse e escrita, tornavam-se sobrecarregados, comprometendo o desempenho dosistema como um todo.

Para lidar com esta situação, desenvolveu-se uma nova abordagem de paralelização.Como o problema principal das soluções anteriores tratava-se dos componentes que cen-tralizavam as operações com o disco, optou-se por replicar não somente as engines FOP,mas também o parse, a extração dos componentes XSL-FOs, além da escrita do arquivode saída. A Figura 3.3 apresenta a nova abordagem proposta.


Figura 3.3: Nova abordagem paralela

Cada processo irá executar a CTool em paralelo, recebendo o mesmo arquivo de en-trada. A divisão do trabalho é baseada no id dos processos, onde cada um irá realizara computação de uma porção diferente do documento. Entretanto, o arquivo de entradacontém cabeçalhos e outras informações indispensáveis que podem ser referenciadas emtodas as partes do documento, como os reusable objects. Devido a isso, cada processo criaum novo documento, que apenas possui sua porção correspondente e estas informações.Sobre o documento criado será realizada a renderização, resultando na geração de diver-sos arquivos de saída, correspondentes as porções computadas por cada processo. Em umprimeiro momento, não há a necessidade de juntá-los, porque estes podem ser enviadosas impressoras de forma independente.

4 Resultados Experimentais

Com o objetivo de avaliar a métrica escolhida e a nova abordagem paralela propostas,alguns experimentos foram realizados. Este Capítulo discorre sobre os arquivos de entradaselecionados, o conjunto de máquinas utilizado para executar as versões seqüencias eparalelas, e descreve uma análise sobre os resultados obtidos neste estudo, ressaltandoos possíveis benefícios que poderiam ser obtidos com uma alocação inteligentedos recursos disponíveis para os diversos jobs da fila.

4.1 Ambiente de Teste

Esta seção apresenta a arquitetura paralela utilizada para executar a nova abordagemproposta e provê uma breve discussão sobre as tecnologias aplicadas na implementaçãodesta. Além disso, ela descreve os casos de testes escolhidos para a avaliar a métricaproposta e o ganho obtido com a nova solução.

4.1.1 Descrição do Ambiente

A arquitetura escolhida para executar a versão paralela trata-se de um multicompu-tador, mais especificamente um cluster composto por 10 blades interligadas por uma redeGigaBit Ethernet (poder de transmissão de até 1Gb por segundo). Cada um dos nodospossui 4 cores, com um processador Opteron 2.4Ghz e 8Gb de memória RAM.

A plataforma de software adotada na solução proposta é composta pela linguagemde programação Java (Java Standard Development Kit versão 1.4.2), juntamente com abilbioteca MPICH 1.2.7 (MPI Chameleon) [37] que provê as funcionalidades do padrãoMPI (Message Passing Interface) [38]. Devido a utilização da linguagem de programaçãoJava, a biblioteca mpiJava 1.2.5 [39] foi empregada na solução paralela.

4.1.2 Casos de Teste

Sabe-se que os arquivos de entrada da aplicação CTool tratam-se de um arquivo PPMLou PPMLT. Devido a motivos previamente explicitados, optou-se pelo formato PPMLTpara descrever os jobs que servirão para avaliar a métrica e a nova abordagem paralelaapresentadas neste trabalho. Analisando as diferentes características que um job poderá

34

4. Resultados Experimentais 35

conter, neste momento existem 4 principais que devem ser ressaltadas, são elas o númerode: XSL-FOs, páginas, documentos e palavras contidas nos componentes XSL-FOs.

Todos os casos de teste, presentes neste trabalho representam situações reais de mer-cado e seus nomes, imagens e textos foram modificados a fim de proteger direitos autorais,pertinentes as empresas que os concederam. O layout de cada um deles pode ser classifi-cado quanto a um determinado tipo de layout, como por exemplo: pôster, carta, cartãopostal e brochura1. As características dos casos de teste são expostas na Tabela 4.1. Pararessaltar o número de instâncias que serão criadas, assim que a conversão de PPMLTpara PPML for realizada pela aplicação CTool, o número de records de cada arquivo deentrada é especificado pelo termo ’documentos’ na Tabela 4.1.

Tabela 4.1: Características dos casos de testeCaso de Teste Documentos Páginas Imagens XSL-FOs Total de Palavras Tipo de LayoutSignage10000 10.000 1 5 7 100.000 PôsterSignage20000 20.000 1 5 7 200.000 PôsterLetter10000 10.000 2 5 8 1.850.000 CartaLetter20000 20.000 2 5 8 3.700.000 Carta

Postcard10000 10.000 2 18 8 3.580.000 Cartão postalPostcard20000 20.000 2 18 8 7.160.000 Cartão postalBrochure10000 10.000 12 38 14 7.850.000 BrochuraBrochure20000 20.000 12 38 14 15.700.000 Brochura

O primeiro caso de teste é chamado de Signage10000, onde cada um de seus do-cumentos é composto por 1 página, 5 imagens e 7 XSL-FOs. Este arquivo engloba umtotal de 10.000 records, o que representa a geração do mesmo número de documentosno PPML de saída. Desta maneira, dispõe de um conteúdo de 100.000 palavras dentrodos componentes XSL-FOs a serem renderizados, com aproximadamente 10 palavras pordocumento. O layout apresentado por este arquivo de entrada é do tipo pôster.

O segundo caso de teste, Signage20000, trata-se de uma variação do primeiro, con-tendo 20.000 documentos ao invés de 10.000. Com isso, este arquivo totaliza 200.000palavras a serem renderizadas, sendo que a média de palavras por documento se mantéma mesma. A Figura 4.1 ilustra três documentos renderizados do primeiro e segundo casosde teste.

Figura 4.1: Três documentos dos casos de teste Signage1Uma brochura trata-se de uma espécie de panfleto, contendo uma única página ou diversas, que são

dispostas uma do lado da outra e dobradas, formando uma espécie de livreto.


O terceiro PPMLT de entrada é o Letter10000. Este contém 10.000 documentos,com 2 páginas, 5 imagens e um total de 8 XSL-FOs cada. Um documento possui emtorno de 185 palavras, somando um total de 1.850.000 palavras. Seu layout é do tipocarta.

Assemelhando-se ao terceiro caso, o quarto (Letter20000) contém 20.000 documentose 3.700.000 palavras a serem renderizadas. A Figura 4.2 apresenta uma instância de umdocumento renderizado, correspondente aos casos de teste Letter10000 e Letter20000.

Figura 4.2: Um documento dos casos de teste Letter

O arquivo Postcard10000 (quinto caso de teste) apresenta cerca de 3.580.000 pala-vras (com aproximadamente 358 palavras por documento), sendo composto por 10.000documentos. Individualmente, os documentos possuem um layout de cartão postal, in-cluindo 2 páginas, 18 imagens e 8 XSL-FOs.

Uma variação do quinto caso de teste, trata-se do arquivo denominadoPostcard20000(sexto caso de teste). Este possui 20.000 documentos, com a mesma configuração doPostcard20000, totalizando 7.160.000 palavras. A Figura 4.3 demonstra um exemplo dedocumento renderizado, correspondente ao quinto e sexto casos de teste.

Figura 4.3: Um documento dos casos de teste Postcard

Por fim, os casos de teste Brochure10000 (sétimo caso de teste) e Brochure20000(oitavo de teste) apresentam 10.000 e 20.000 documentos respectivamente. Seus docu-mentos são compostos por 12 páginas, 38 imagens e 14 XSL-FOs. Com em torno de 785


palavras por documento, o penúltimo soma uma quantia de 7.850.000 palavras, enquantoo último, 15.700.000 palavras a serem renderizadas. O tipo de layout apresentado porambos é do tipo brochura e a Figura 4.4 ilustra algumas páginas dos documentos nelescontidos.

Figura 4.4: Algumas páginas de um documento dos casos de teste Brochure

4.2 Análise dos Resultados

Para avaliar se a métrica escolhida é representativa à medida que é um dado signifi-cativo para medir o custo computacional de cada caso de teste, execuções dos arquivosde entrada apresentados neste trabalho foram realizados. Estas foram feitas através dautilização das versões seqüencial e paralela. Assim, a partir da primeira pôde-se analisarse a métrica escolhida condiz com o esforço gasto no processamento de cada caso de testee com a segunda avaliou-se o possível ganho que poderia ser obtido através da análise doperfil dos documentos, aplicando a métrica proposta, para executar diversos jobs em pa-ralelo. Além disso, verificou-se o ganho obtido com a nova abordagem e se os empecilhosexistentes nas versões previamente criadas, foram superados. Os resultados, então, sãoapresentados a seguir.

4.2.1 Validação da Métrica

Através do uso da versão seqüencial, os oito casos de teste descritos neste trabalhoforam executados com a finalidade de validar a métrica proposta. A Tabela 4.2 apresentaos tempos de execução obtidos.

Analisando os tempos obtidos apresentados na Tabela 4.2, pode-se perceber que amétrica estipulada condiz com o esforço gasto para processar um documento PPMLT. Oscasos de teste Brochure10000 e Brochure20000, os que contêm o maior número de palavras,foram aqueles que demoraram mais tempo para serem renderizados, sendo computadosem 4875,7382 segundos e 9478,3134 segundos respectivamente. Os arquivos de entrada


Tabela 4.2: Tempo de execução seqüencialCaso de Teste Tempo de Execução (segundos)Signage10000 456,4850Signage20000 902,8060Letter10000 1380,7814Letter20000 2762,1552

Postcard10000 2449,7032Postcard20000 4818,8176Brochure10000 4875,7382Brochure20000 9478,3134

Postcard10000 e Postcard20000 foram renderizados em 2449,7032 segundos e 4818,8176segundos. O processamento dos arquivos Letter10000 e Letter20000 foi finalizado em1380,7814 segundos e 2762,1552 segundos. Por fim, os casos de teste Signage10000 e Sig-nage20000 foram os mais rápidos a serem renderizados, com 456,4850 e 902,8060 segundosrespectivamente.

Uma questão interessante pode ser observada: para cada par de documentos com asmesmas características, à medida que a quantidade de documentos dobra, o tempo derenderização praticamente duplica. Tal fato acontece, pois dobrando o número de docu-mentos, duplica-se o número de palavras a serem renderizadas, portanto o mesmo efeitoé observado no tempo de execução. Além disso, pode-se perceber que a métrica escolhidaserve para avaliar o custo computacional de casos de teste que possuem diversas caracterís-ticas diferentes, como a situação do Postcard20000 e Brochure10000. É possível observarque o tempo de processamento de ambos é muito parecido, pois apesar de se diferenciarempor diversos aspectos, o número de palavras a serem renderizadas é semelhante. Por outrolado, o caso de teste Letter20000 supera o tempo de execução do arquivo Postcard10000,pois o seu número de palavras é maior, considerando seus 20,000 documentos.

As constatações supracitadas demonstram que a informação levada em consideraçãopara medir o esforço gasto na fase de renderização, o número de palavras, é uma escolhaválida e consistente para os casos apresentados.

4.2.2 Execução Paralela

Os oito casos de teste foram executados através do uso da nova abordagem paralelaproposta. Para tanto, optou-se por utilizar como unidade de processamento cada coredisponível na arquitetura paralela escolhida, ao invés de lidar com um nodo propriamentedito. Desta maneira, poder-se-ia executar a solução com até 40 processos, ao invés deapenas 10. Assim, seria possível realizar uma análise mais profunda do comportamentoda aplicação em termos de escalabilidade. Esta escolha pode ser facilmente aplicada,pois não há nenhum tipo de comunicação efetivo entre os processos que venha a causaralgum impacto de desbalanceamento de carga, quando agrupando até 4 processos emum mesmo nodo do cluster. Entretanto, para avaliar se alguma perda de desempenhoquando processando um documento em 4 cores, provavelmente causada por disputas a


barramentos do disco e memória, pudessem ocorrer, testes foram feitos, comparando otempo de execução da versão paralela em 4 nodos e em 4 cores. A Tabela 4.3 apresentaos resultados obtidos.

Tabela 4.3: Tempo de execução em 4 cores versus em 4 nodosCaso de Teste 4 Nodos (segundos) 4 Cores (segundos)Signage10000 131,1242 125,0327Signage20000 256,1371 246,9540Letter10000 385.5073 388,4881Letter20000 760.3414 763,0234

Postcard10000 643,6750 642,8414Postcard20000 1217,2900 1213,3315Brochure10000 1238,4635 1247,1714Brochure20000 2442,0000 2437,5481

Como se pode observar o tempo de execução permanece em torno da mesma faixa,possibilitando a adoção de cores como unidades de processamento propriamente ditas.A seguir são apresentados o tempo de execução, uma análise sobre o perfil dos jobs e ospeedup obtidos através do processamento dos oito casos de teste descritos na seção 4.1.2,variando de 2 à 40 processos.

Tempo de Execução

Com a finalidade de realizar uma breve análise do ganho de desempenho apresentadopela versão paralela e para prover parâmetros para verificar as vantagens que poderiam serobtidas com uma estratégia de escalonamento inteligente, executou-se a solução paralelaproposta. A Figura 4.5 ilustra um gráfico dos tempos de processamento, juntamentecom uma tabela contendo alguns destes valores, ambos referentes a computação dos doisprimeiros casos de teste, Signage10000 e Signage20000.

Figura 4.5: Tempo de execução - Signage10000 e Signage20000

Pode-se constatar que os tempos obtidos chegam ao mínimo de 27,2462 segundospara o PPMLT Signage10000 (com 40 processos) e 36,5156 segundos para o PPMLT Sig-


nage20000 (com 40 processos), representando uma grande melhoria de 429,2388 e 866,2904segundos se comparados respectivamente aos tempos da versão seqüencial.

Seguindo com os testes nesta versão, o gráfico de execução e tabela abaixo (Figura4.6) referem-se aos casos de teste Letter10000 e Letter20000.

Figura 4.6: Tempo de execução - Letter10000 e Letter20000

Com estes PPMLTs o tempo de execução atingiu um total de 73,3160 segundos, apartir da utilização de 40 processos e de 133,1620 segundos, com o uso de 40 processos,para o terceiro e quarto arquivos respectivamente. Estes tempos demonstram um ganho deaté 1307,4654 (Letter10000) e 2628,9932 (Letter20000) segundos em relação a ferramentaseqüencial.

Figura 4.7: Tempo de execução - Postcard10000 e Postcard20000

Analisando a Figura 4.7, que apresenta os tempos de execução dos casos de teste Post-card10000 e Postcard20000, pode-se constatar que houve uma redução de até 2334,4652e 4587,8606 segundos com o uso de 40 processos.


Finalmente, a Figura 4.8 ilustra o tempo de execução dos maiores casos de teste:Brochure10000 e Brochure20000.

Figura 4.8: Tempo de execução - Brochure10000 e Brochure20000

Por fim, ganhou-se 4600,7262 segundos no tempo de execução do Brochure10000(tempo de renderização de 275,0120 segundos) e 9084,4275 segundos no tempo de exe-cução do Brochure20000 (tempo de renderização de 393,8859 segundos), ambos com 40processos.

Análise do Perfil de Jobs

Para verificar os benefícios quanto a alocação de recursos que poderiam ser obtidosatravés da análise prévia do perfil dos jobs da fila com uso de parâmetros reais, tomou-secomo base os tempos descritos até então. Neste sentido, dois cenários são apresentados,contrastando a serialização da computação de jobs da fila com o uso de uma instância daversão paralela proposta e a execução vários destes em paralelo, com o auxílio de diversasinstâncias dela.

Levando em consideração a execução do caso de teste Brochure20000 com 30 e 40nodos pode-se perceber que o ganho obtido chega a aproximadamente 117 segundos. Poroutro lado, pode-se executar o teste Brochure20000 com apenas 30 nodos e alocar os 10demais para outro job, como, por exemplo, Postcard20000. Desta maneira, conseguirá seexecutar ambos por volta de 554 segundos, que corresponde ao tempo de renderizaçãodaquele que leva mais tempo com os recursos correspondentes. Caso estes jobs fossemserializados de forma que todos os recursos estivessem alocados para um e depois paraoutro teria-se um tempo de execução de 623 segundos, ou seja, 79 segundos a mais. Estenúmero, a primeira vista, pode não parecer significativo, mas corresponde a aproximada-mente 15% de ganho de desempenho. Outra situação em que se observaria um ganho dedesempenho se comparada a serialização de jobs da fila é o caso de se executar os arqui-


vos Letter10000, Postcard20000 e Brochure10000 com respectivamente 5, 15 e 20 nodos.Através da execução em paralelo destes jobs, se verificaria um tempo de aproximadamente452 segundos ao invés dos 578 segundos obtidos com a execução serial de cada um delescom o uso de todos os recursos. Neste caso, a redução de tempo chega a 126 segundos,representando uma queda significativa de 22% de tempo.

Speedup

Com o objetivo de avaliar a escalabilidade da nova abordagem paralela proposta,nesta seção apresentam-se gráficos de speedup referentes aos oito casos de teste obtidos.A Figura 4.9 ilustra a aceleração obtida.

5

10

15

20

25

30

35

40

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40

Spe

edup

Processos

Signage10000Signage20000

Letter10000Letter20000

Postcard10000Postcard20000Brochure10000Brochure20000

Ideal

Figura 4.9: Speedup referente aos 8 casos de teste descritos

Analisando o gráfico apresentado pode-se constatar que o fator de aceleração paratodos os casos de teste se manteve entre 15 e 25, demonstrando um grande ganho da novaversão paralela se comparada as versões paralelas previamente propostas. O caso de testeSignage10000 foi aquele que apresentou o menor speedup dentre todos, mas por outro ladofoi no arquivo Signage20000 que se verificou o maior speedup alcançado, juntamente como arquivo Brochure20000. Os demais PPMLTs mantiveram um fator de aceleração porvolta de 20. Apesar dos speedups obtidos não apresentarem uma situação muito próximada ideal, pode-se verificar que o ganho obtido é substancial e não atinge uma fase dedesaleração mesmo com 40 processos. Assim, pode-se afirmar que a abordagem propostaé escalável, ao ponto de apresentar um ganho significativo de aceleração à medida que sãoinseridos mais processos.

Por outro lado, devido a inexistência de comunicação entre os processos o esperado eraque o speedup das execuções se mantivesse muito perto da reta ideal. No entanto, o gráfico


apresentado contradiz esta constatação, demonstrando que a partir de um determinadonúmero de processos associados a execução de um caso de teste, a aceleração passa a seafastar do esperado. Acredita-se que isto decorre do fato de que à medida que o grão(número de documentos a serem gerados por processo) diminui, o tempo de inicialização(que envolve a leitura e quebra do arquivo PPMLT original) acaba se tornando significa-tivo, prejudicando o desempenho da aplicação paralela. Assim, quanto mais rápida for aexecução mais impactante será o tempo de inicialização, reduzindo o fator de speedup.

5 Conclusão e Trabalhos Futuros

O trabalho apresentado, mostrou-se como um estudo válido para compreender o fun-cionamento de uma grande parte do processo aplicado em print shops, que utilizam atécnica de VDP. Os resultados apresentados demonstram que os problemas existentesnas estratégias anteriores, conseguiram ser resolvidos. Além disso, este estudo indicauma métrica consistente (número de palavras em um componente XSL-FO) para prevero comportamento e o custo computacional gasto para cada documento de entrada.

Através dos resultados apresentados é possível definir um ponto de partida para di-versas outras linhas de pesquisa, que buscariam novas formas para otimizar ainda mais oprocesso de impressão como um todo. Com a métrica escolhida, pretende-se partir paraum estudo de como ela deve ser aplicada em um cálculo, prevendo o tempo que será gastona computação de um documento. A Figura 5.1 ilustra uma estratégia, a qual pretende-sedesenvolver.

Figura 5.1: Escalonador para jobs da fila

Uma aplicação escalonadora utilizaria o cálculo especificado, juntamente com diversasinstâncias da solução paralela apresentada, decidindo a quantidade de recursos que cadadocumento na fila iria utilizar e executando vários deles em paralelo. Assim, existiria umaversão paralela mais inteligente, capaz de se adaptar as diferentes situações existentes, deacordo com os resultados obtidos neste trabalho, aumentando ou melhorando a utilizaçãodo hardware disponível.

44

5. Conclusão e Trabalhos Futuros 45

Por outro lado, é importante ressaltar que até então focou-se apenas na fase de rende-rização dos documentos. Entretanto, existem outras fases neste processo que apresentamum custo computacional relativamente grande, como o processo de rasterização. Este éefetuado sobre PDLs e imagens contidos em <marks> dos arquivos PPMLT logo antesde imprimí-los. Assim como os XSL-FOs, estes formatos possuem características relaci-onadas que podem ser empregadas na previsão de seu custo computacional. Portanto,uma linha de pesquisa potencial, seria realizar a mesma abordagem realizada sobre osXSL-FOs, definindo uma métrica para atribuir um peso de processamento a cada umdeles e por fim, executando-os em paralelo, através da alocação de recursos de maneirainteligente.

Referências Bibliográficas

[1] NUNES, T. et al. High performance XSL-FO rendering for variable data printing. In:SAC ’06: Proceedings of the 2006 ACM symposium on Applied computing. New York,NY, USA: ACM, 2006. p. 811–817. ISBN 1-59593-108-2.

[2] NUNES, T. et al. An improved parallel XSL-FO rendering for personalized documents.In: Recent Advances in Parallel Virtual Machine and Message Passing Interface. Paris,France: Springer Berlin / Heidelberg, 2007. p. 56–63. ISBN 978-3-540-75415-2.

[3] PURVIS, L. et al. Creating personalized documents: an optimization approach. In:DocEng ’03: Proceedings of the 2003 ACM symposium on Document engineering. NewYork, NY, USA: ACM, 2003. p. 68–77. ISBN 1-58113-724-9.

[4] GOODMAN, T. Case study: Digital publishing at the olympic games. In: OpenPublish. [S.l.: s.n.], 2001.

[5] OPPEN, D. C. Prettyprinting. ACM Trans. Program. Lang. Syst., ACM, New York,NY, USA, v. 2, n. 4, p. 465–483, 1980. ISSN 0164-0925.

[6] GIANNETTI, F. A multi-format variable data template wrapper extending podisPPML-T standard. In: DocEng ’07: Proceedings of the 2007 ACM symposium on Do-cument engineering. New York, NY, USA: ACM, 2007. p. 37–43. ISBN 978-1-59593-776-6.

[7] W3C. The World Wide Web Consortium. Disponível em: http://www.w3c.org. Aces-sado em: 15/08/2007.

[8] RAGGETT, D.; HORS, A. L.; JACOBS, I. HTML 4.01 Specification. Dezembro 1999.Disponível em: http://www.w3.org/TR/html401. Acessado em: 12/08/2007.

[9] PEMBERTON, S. et al. XHTML 1.0 The Extensible HyperText Markup Language (Se-cond Edition). Agosto 2002. Disponível em: http://www.w3.org/TR/xhtml1. Acessadoem: 13/08/2007.

[10] BOS, B. et al. Cascading Style Sheets, Level 2. Maio 1998. Disponível em:http://www.w3c.org/TR/WD-css2. Acessado em: 10/08/2007.

46


[11] BRAY, T. et al. Extensible Markup language (XML) 1.0 (Fourth Edition). Setembro2006. Disponível em: http://www.w3.org/TR/REC-xml. Acessado em: 13/08/2007.

[12] SMITH, J. M. Standard Generalized Markup Language and related standards. [S.l.]:Computer Communications, 1989. 80-84 p.

[13] MEGGINSON, D. SAX. Janeiro 1998. Disponível em: http://www.saxproject.org.Acessado em: 17/08/2007.

[14] APPARAO, V. et al. Document Object Model (DOM) Level 1 Specification. Outu-bro 1998. Disponível em: http://www.w3.org/TR/REC-DOM-Level-1. Acessado em:17/08/2007.

[15] BERGLUND, A. Extensible Stylesheet Language (XSL) Version 1.1. Dezembro 2006.Disponível em: http://www.w3c.org/TR/xsl. Acessado em: 23/08/2007.

[16] CLARK, J. Document Style Semantics and Specification Language (DSSSL). 1996.Disponível em: http://www.jclark.com/dsssl. Acessado em: 01/09/2007.

[17] CLARK, J.; DEROSE, S. XML Path Language (XPath). Novembro 1999. Disponívelem: http://www.w3c.org/TR/xpath. Acessado em: 02/09/2007.

[18] DEROSE, S. et al. XML Pointer Language (Xpointer). Agosto 2002. Disponível em:http://www.w3.org/TR/xptr. Acessado em: 16/09/2007.

[19] BOAG, S. et al. XQuery 1.0: An XML Query Language. Janeiro 2007. Disponívelem: http://www.w3c.org/TR/xquery. Acessado em: 02/09/2007.

[20] BERGLUND, A. et al. XML Path Language (XPath) 2.0. Janeiro 2007. Disponívelem: http://www.w3c.org/TR/xpath20. Acessado em: 17/09/2007.

[21] CLARK, J. XSL Transformations (XSLT) Version 1.0. Novembro 1999. Disponívelem: http://www.w3c.org/TR/xslt. Acessado em: 02/09/2007.

[22] Open Mobile Alliance Ltd. WAP Wireless Markup Language Specification (WML).2005. Disponível em: http://www.oasis-open.org/cover/wap-wml.html. Acessado em13/09/2007.

[23] DEUTSCH, A. et al. Querying XML data. In: Bulletin of the IEEE Computer SocietyTechnical Committee on Data Engineering. [S.l.: s.n.], 1999. p. 10–18.

[24] KIMBER, E. W. Using XSL Formatting Objects for production-quality internati-onalized document printing. In: Proceedings of the XML Europe 2003. London, UK:International Digital Enterprise Alliance, 2003. p. 1–20.

[25] PODi. PODi. Disponível em: http://www.podi.org. Acessado em: 10/09/2007.


[26] BOSSCHERE, D. D. Book ticket files & imposition templates for variable data prin-ting fundamentals for PPML. In: Proceedings of the XML Europe 2000. Paris, France:International Digital Enterprise Alliance, 2000.

[27] MENEGUZZI, F. R. et al. Strategies for document optimization in digital publishing.In: DocEng ’04: Proceedings of the 2004 ACM symposium on Document engineering.New York, NY, USA: ACM, 2004. p. 163–170. ISBN 1-58113-938-1.

[28] PODi. PODi, Personalized Print Markup Language - Templating 1.0 (PPMLT). Dis-ponível em: http://www.podi.org. Acessado em: 11/09/2007.

[29] PODi. PPML Templates: Methods and Workflows. 1st. ed. [S.l.], Dezembro 2002.

[30] Adobe Systems. PDF Reference. 4th. ed. [S.l.], 2003.

[31] Adobe Systems. PostScript Language Reference Manual. 2nd. ed. [S.l.], 1990.

[32] ANDERSSON, O. et al. Scalable Vector Graphics (SVG) 1.1 Specification. Janeiro2003. Disponível em: http://www.w3.org/TR/SVG11/. Acessado em: 20/08/2007.

[33] MONG, J. C.; BRAILSFORD, D. F. Using SVG as the rendering model for structuredand graphically complex web material. In: DocEng ’03: Proceedings of the 2003 ACMsymposium on Document engineering. New York, NY, USA: ACM, 2003. p. 88–91. ISBN1-58113-724-9.

[34] HEGDE, S. Potential of SVG as an interface to a route optimization model for thetransport of hazardous material. 2004.

[35] MCCORMACK, C. L.; MARRIOTT, K.; MEYER, B. Constraint SVG. In: WWWAlt. ’04: Proceedings of the 13th international World Wide Web conference on Alternatetrack papers & posters. New York, NY, USA: ACM, 2004. p. 310–311. ISBN 1-58113-912-8.

[36] Apache. Formatting Objects Processor. Disponível em: http://xml.apache.org/fop.Acessado em: 15/06/2007.

[37] MPICH. MPICH Home Page. Novembro 2005. Disponível em: http://www-unix.mcs.anl.gov/mpi/mpich1. Acessado em: 15/06/2007.

[38] SNIR., M. et al. MPI: the complete reference. [S.l.]: MIT Press, 1996.

[39] mpiJava. The mpiJava Home Page. Janeiro 2003. Disponível em:http://www.hpjava.org/mpiJava.html. Acessado em: 15/06/2007.

AnálisedoPerﬁlde Jobs paraaAceleração ...€¦ · Pontifícia Universidade Católica do Rio...

Documents

Transcript of AnálisedoPerﬁlde Jobs paraaAceleração ...€¦ · Pontifícia Universidade Católica do Rio...