Além da edição dirigida pela sintaxe SGML, a validação estrutural de um documento é assegurada por um parser (SP) associado ao Editor. Assim, à saída do editor temos um documento SGML puro (texto com anotações e sintaticamente válido). Há que processá-lo para se obter o documento num formato ideal para publicação. O ideal é que este processamento seja o mais normalizado possível, sem haver necessidade de muitas parametrizações ou mesmo programações específicas.
Pretendia-se que esta tese fosse publicada em papel (é o normal e obrigatório), em CDROM e na Internet. O que implicava a geração do documento em formato: para papel, RTF, PDF ou PS; para a Internet e CDROM, HTML. Tínhamos, portanto à partida dois formatos bem diferentes, o normal para papel em que um documento é estruturado em páginas e o outro, em HTML, não tem conceito de página física (não há dimensões limites), é hipertexto (consegue-se navegar no documento seguindo as referências e entradas de índices). Depois do que foi apresentado na tese, havia também a convicção de se usar DSSSL para especificar o estilo no qual o documento deveria ser convertido.
Uma das razões que fez a escolha recair sobre o DTD Docbook foi a existência de um projecto de desenvolvimento de um conjunto de stylesheets em DSSSL para processar documentos escritos segundo aquele DTD. Este projecto de desenvolvimento está a ser conduzido por Norman Walsh com a designação "Modular Docbook DSSSL Stylesheets" [Wal2000] e tem recebido contribuições de várias dezenas de utilizadores o que faz com que novas e melhoradas versões sejam lançadas com muita frequência (quando aderimos ao esquema começamos por utilizar a versão 1.05, agora já estamos a utilizar a versão 1.50). A compatibilidade entre versões é garantida desde que algum cuidado seja tido em conta aquando da sua utilização. De qualquer modo, a linguagem de especificação não é alterada, o que acontece é que elementos que não eram suportados pela especificação têm vindo a ser adicionados.
Como o Docbook nunca tinha sido usado para formatar um documento escrito em português foi preciso adicionar o suporte da língua portuguesa, tarefa que o autor realizou e que uma vez terminada, foi imediatamente adicionada à distribuição por Walsh.
Tendo o documento SGML e a especificação DSSSL do estilo era preciso um processador que percebesse as duas linguagens, fosse capaz de juntar os dois ficheiros e produzir o resultado final desejado. A escolha dessa ferramenta foi simples, o jade [Cla96b] é o motor de DSSSL que suporta mais funcionalidades da linguagem (existem outros como o SENG escrito em Java mas o suporte da linguagem é muito parcial) e além disso, não tem direitos comerciais, como vem sendo hábito no software desenvolvido por James Clark (é distribuído ao abrigo da licença da GNU).
Com o documento SGML e a especificação de estilo DSSSL, o jade pode converter o documento em RTF, TeX, MIF, HTML, texto ASCII, ou FOT (documento xml que descreve o grove final do processo de formatação, a Flow Object Tree). Como a essência do formato HTML é diferente dos outros, seriam necessárias duas especificações de estilo já previstas na distribuição das stylesheets. Houve que parametrizar cada uma delas.
A parametrização feita pelo autor para a versão papel foi a seguinte:
<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [ <!ENTITY dbstyle SYSTEM "..\style1.50\docbook\print\docbook.dsl" CDATA DSSSL> ]> <style-sheet> <style-specification use="docbook"> <style-specification-body> (define %paper-type% "A4") (define %default-title-end-punct% " ") (define %two-side% #t) (define %section-autolabel% #t) (define %example-rules% #t) (define biblio-citation-check #t) (define biblio-number #f) </style-specification-body> </style-specification> <external-specification id="docbook" document="dbstyle"> </style-sheet>
Como se pode ver, um grande número de parâmetros estão relacionados com a mancha de texto no papel.
A parametrização para HTML é ligeiramente diferente:
<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
<!ENTITY dbstyle SYSTEM "../style1.44/docbook/html/docbook.dsl" CDATA DSSSL>
]>
<style-sheet>
<style-specification use='docbook'>
<style-specification-body>
(define %default-title-end-punct% " ")
(define %section-autolabel% #t)
(define %example-rules% #t)
(define biblio-citation-check #t)
(define biblio-number #f)
(element emphasis
(let ((func (if (attribute-string (normalize "ROLE"))
(attribute-string (normalize "ROLE"))
(normalize "normal"))))
(cond
((equal? func "SCRIPT") ($italic-mono-seq$))
((equal? func "NORMAL") ($italic-seq$))
(else (literal func)))))
</style-specification-body>
</style-specification>
<external-specification id='docbook' document='dbstyle'>
</style-sheet>As parametrizações relacionadas com o papel desapareceram. Podemos ver aqui uma redefinição de estilo para o elemento EMPHASIS. Está a usar-se este elemento para inserir caracteres num estilo matemático. Para esse efeito, o seu atributo ROLE toma um valor que indica o tipo de conteúdo do elemento. O estilo é portanto condicionado pelo conteúdo do atributo ROLE.
Para a versão papel, optou-se de início por gerar RTF. O resultado era directamente visível no MSWord Viewer, o que permitia trabalhar num só sistema operativo (o AuthorEditor só existe para Windows). As coisas corriam bem até se ter atingido o montante de 120 páginas. A partir daqui o MSWord Viewer começou a ter um comportamento não determinístico em relação às imagens, umas eram carregadas outras não (as imagens no formato RTF são mantidas externamente, no código há apenas um comando de inclusão da imagem; é da responsabilidade do software que irá abrir o documento, o carregamento das imagens). Com mais algumas páginas, as imagens simplesmente deixaram de ser carregadas o que impossibilitava a sua impressão e mesmo a disposição correcta do texto uma vez que o respectivo espaço não era reservado.
Tínhamos um problema grave, era preciso gerar outro formato para a impressão em papel. O avançado estado de escrita da tese não permitia grandes aventuras e por uma questão de princípio era conveniente manter a produção em SGML e a formatação em DSSSL. A opção foi começar a gerar TeX. A partir do TeX era também possível gerar PDF o que nos deu dois caminhos à escolha:
Gerar TeX; converter as imagens para EPS; o resultado final para impressão seria o Postscript.
Gerar TeX; converter o TeX em PDF; converter as imagens para PNG; o resultado final para impressão seria o PDF (que permite também distribuir como edição electrónica - CDROM).
Como o resultado da conversão das imagens para EPS não foi satisfatório, ao contrário da conversão daquelas para PNG, optou-se pela segunda via.
O jade gera um formato TeX especial, que para ser processado precisa de uma versão e de uma configuração especial: o jadetex (que vem acompanhado do pdfjadetex que realiza a conversão posterior para PDF).
O jadetex é um processador de TeX específico que realiza a conversão pretendida muito bem, contudo a sua configuração é muito penosa e, ainda, preenchida com alguns passos obscuros.
Depois desta plataforma estar instalada, tudo começou a correr melhor, as imagens já eram carregadas (no caso do PDF elas são incluídas dentro do ficheiro final), mas as tabelas (apenas 3 ou 4) apareciam completamente desformatadas. Com a ajuda preciosa de um dos autores do jadetex (Sebastian Rhatz), constatou-se que a versão do jade que se estava a utilizar era a mais pura mas para o caso precisava de uma versão estendida desenvolvida por um grupo de utilizadores que decidiram levar o desenvolvimento do jade a sério e criaram o projecto de desenvolvimento OpenJade [OpenJade].
Depois de instalado (na versão 1.2.2), o circuito montado ficou a funcionar em pleno, permitindo gerar esta versão da tese.