Arquivo

Posts Tagged ‘LaTeX’

ScribTeX = Wiki + TeX…?

terça-feira, 17 mar 2009; \12\UTC\UTC\k 12 Deixe um comentário

Ainda falando sobre a edição colaborativa de textos em TeX, acabei de trombar em algo bastante inusitado,

A idéia é simples, é uma mistura orgânica de Wiki com TeX: o software contém uma distribuição completa de TeX (LiveTeX) e vc usa a sintaxe normal do TeX/LaTeX; a diferença é que é num ambiente “Web2.0”: numa interface de Wiki e nas “nuvens” (i.e., não é no seu computador, mas nas “Internets” 😉 ). Então, vc tem o controle de versão e a possibilidade de colaboração feito pela parte “Wiki”, e o TeX feito pela distribuição LiveTeX contida no software. A interface é análoga a do GoogleDocs: vc cria seu documento e escolhe com quem vai compartilhar e tudo mais — básico mas efetivo.

Me parece que essa idéia é análoga a do branch do Instiki que o Distler usa,

Porém, o ScribTeX parece usar o Wikimedia como engine (além de ser um ‘hosted service’, i.e., funcionar “in the cloud”) — código fonte pode ser encontrado no GitHUB: MathWiki.

Eu, pessoalmente, ainda prefiro algo nas linhas daquilo que descrevi no post que fiz aqui no AP sobre isso (integração de “Emacs + AUCTeX” com git rodando num servidor central, esse sim, na “cloud”), mas acho que essa é uma excelente opção para um “hosted service” (i.e., eu não tenho que administrar nem servidor nem instalação nenhuma 😛 ), pra algo na “cloud”, no melhor estilo Web2.0.

Vamos ver como andam as coisas daqui pra frente… 😈

Matemática na era da Web2.0…

quarta-feira, 25 fev 2009; \09\UTC\UTC\k 09 3 comentários

A WWW daria uma lousa e tanto… se a gente conseguisse rabiscar uma equação

A WWW foi concebida no CERN e, desde então, o patamar em que chegamos atualmente (chamado de Web 2.0) é bem diferente daquilo que se imaginava na época da criação da Web. Hoje em dia já se fala em Web 3.0, que é uma espécie de codinome para Cloud Computing. Porém, o sonho original para a WWW é a chamada Semantic Web. Eis o próprio T.B. Lee falando sobre esse assunto,

De fato, a tal “Web 3.0” deve incluir toda essa parte “semântica” (veja mais em W3C Semantic Web Activity, The Semantic Web e The Semantic Web Revisited (PDF)), chamada tecnicamente de Metadata — apesar de que a incorporação de todos esses “metadados” em bancos-de-dados e aplicações (“cloud”) afins ainda vai levar algum tempo. 😉

De qualquer maneira… essa “simples” idéia — de assimilar os “metadados” de forma fundamental e intrínseca nas entranhas da Web — tem um enorme potencial quando o assunto é Publicação Científica. Um exemplo claro disso é o Scientific Publishing Task Force: Mindswap: Science and the Semantic Web, Science and the Semantic Web (PDF), Semantic web in science: how to build it, how to use it, ScienceOnline09: The Semantic Web in Science.

Então, como se pode ver com clareza, essa idéia de se associar “semântica” aos elementos já pertencentes da WWW, realmente será algo revolucionário.

A razão pra essa longa introdução é o paradigma adotado pelo MathML, que é a linguagem que permitirá a introdução de linguagem Matemática na WWW. Existem dois modos de se “descrever” uma informação em MathML, Presentation MathML e Content MathML — enquanto o pMathML foca na apresentação e aparência das equações e elementos matemáticos, o cMathML foca no significado semântico das expressões (num esquema bem parecido com Cálculo λ 😎 ).

Então, fica claro que o objetivo de MathML não é apenas o de “apresentar” uma informação, mas também de dar significado semântico a ela, o que fará com que a comunicação matemática seja muito superior do que a comunicação atual, feita em HTML!

O paradigma atual: \TeX

Hoje em dia, efetivamente, quem tem necessidade de publicar muitas equações usa \TeX, mais especificamente, usa-se \LaTeX — esse é o de facto padrão.

Essa linguagem é extremamente poderosa, versátil e flexível, podendo ser extendida de várias maneiras diferentes. E isso facilita muito sua aplicação em várias áreas diferentes: desde símbolos matemáticos, gráficos vetoriais, …, até símbolos musicais, de xadrez e tipografia em línguas gráficas, como árabe, hindu, chinês e afins!

Por essas e por outras, atualmente é muito mais comum de se encontrar programas que convertem de \TeX para MathML do que programas que nativamente facilitam a edição nativa [em MathML]. Tanto que existe um livro unicamente dedicado a esse assunto: The LaTex Web Companion. Aliás, nessa linha, eu recomendo o uso do formato DocBook, cuja saída pode ser HTML, PDF, \TeX (via o uso de XSLT), etc.

Portanto, o que acabou acontecendo é que quando alguém precisa publicar fórmulas e afins, ou se cria um documento em PDF, ou se usa de “algum desvio” para colocar a informação na Rede — em geral, esse desvio consiste em se converter o conteúdo desejado em alguma imagem, e inserí-la no HTML em questão.

A saída: habilitar os navegadores

A alternativa pra tornar tudo isso integrado (Web 3.0, MathML, etc) e unificado é prepararmos os navegadores para essa nova jornada, nova etapa, da WWW. Por exemplo, o Firefox tem toda uma infra-estrutura dedicada para MathML: MathML in Mozilla. Porém, pra isso, é preciso que os desenvolvedores de navegadores sigam os padrões já definidos para MathML. Essa é uma lista dos navegadores que suportam MathML. Além disso, pra quem usa Firefox, esse é um ‘add-on’ bem interessante, Firemath (eu não tenho uma conta com o Mozilla, então, se alguém que tiver uma conta quiser me mandar o add-on, eu agradeço 😉 ).

Portanto, o caminho ainda se encontra aberto… e as possibilidades são infinitas! 😈

Referências…

Edição colaborativa em TeX…

domingo, 12 out 2008; \41\UTC\UTC\k 41 8 comentários

Muita gente, mais cedo ou mais tarde, acaba trombando nesse problema: como editar colaborativamente um artigo científico, em geral editado em \TeX e \LaTeX?

Imagine a seguinte situação: vc numa sala, no seu depto preferido, e seu colaborador na sala ao lado! Como é que vcs podem se coordenar para escrever um artigo juntos? Agora, imaginem uma situação mais idealizada, só pra facilitar o argumento a seguir: vc e seu colaborador estão a meio planeta de distância. 😈

No meio científico, essa situação é razoavelmente comum: vários autores colaborando num mesmo artigo, um em cada canto desse nosso mundo redondo.

Praqueles que não têm uma necessidade tipográfica muito grande, algo como Google Docs dá conta do recado: vc simplesmente transfere sua ferramenta editorial para “the cloud“. 😉

Agora, pra quem tem necessidades tipográficas mais agudas — e.g., TeX, LaTeX, DocBook ou HTML —, a colaboração é certamente mais complicada e delicada.

As primeiras alternativas que surgiram foram as seguintes:

Quem usa Emacs pode utilizar AUCTeX e psvn.el para integrar tudo de modo suficientemente transparente.

Uma alternativa um pouco mais moderna, que integra e faz o papel de agregar as funcionalidades de “editor de textos” e “controle de versões”, é a seguinte:

  • Gobby (roda em qualquer plataforma: Microsoft Windows, Mac OS X, GNU/Linux e *NIX afins);
  • SubEthaEdit (só para Mac OS X).

Essencialmente, ambos são equivalentes: O Gobby é uma implementação “software livre” do SubEthaEdit. Para usuários menos experientes em lidar com o controle de versões, delegar essa tarefa diretamente para o editor pode ser uma saída viável. Para maiores informações sobre esse tipo de editores, é só dar uma olhada em Collaborative real-time editor. Infelizmente, eu não sei quantos desses têm suporte para TeX ou LaTeX.

Isso tudo posto… aautgora é hora de falar no Git: o Git é um dos softwares para controle de versão mais rápidos disponível atualmente. Aliás, mais do que isso, o paradigma descentralizado e distribuído do git o torna um candidato natural para um sistema de arquivos com as mesmas propriedades: o jeito mais fácil de entender o conceito do git é imaginar que vc pode, e.g., ter uma pasta no seu computador ‘replicada’ em outros computadores (que vc explicitamente permitiu acessar a pasta original): ou seja, todos os seus colaboradores vão ter acesso à mesma pasta, de tal forma que quando qualquer arquivo (formatos ASCII ou binários, i.e., TeX, LaTeX, DOC(X), PDF, JPEG, TXT, HTML, RTF, etc) dentro dessa pasta for atualizado, todos os colaboradores recebem essa mesma atualização!

Fora isso, o git tem algumas outras propriedades bem interessantes para quem está desenvolvendo uma colaboração científica, que tende a ser um processo altamente emaranhado e não-linear: suporte para desenvolvimento não-linear (resolução de conflitos de edição), desenvolvimento distribuído, é possível usar subversion através de comandos de compatibilidade, velocidade e escalabilidade (eficiência para grandes projetos), autenticação criptografada, entre outras.

Ou seja, através do uso do git o controle de versões é extremamente mais poderoso e flexível, isso pra não falar na resolução de conflitos, i.e., quando dois ou mais dos seus colaboradores estiver trabalhando no artigo (ou gráfico, imagem, etc — qualquer tipo de arquivo), ao mesmo tempo, qual modificação tem maior prioridade? O git é excelente nesse departamento… além de permitir que vc compartilhe toda uma pasta com seus colaboradores, uma vez que qualquer tipo de arquivo é monitorado e atualizado automaticamente.

É, a meu ver, a saída mais sofisticada e robusta para o problema de colaboração e acesso de várias pessoas a um mesmo conjunto de arquivos (e tudo pode funcionar de modo encriptado, o que torna todo o processo ainda mais confortável). Porém, infelizmente, ainda não há nenhum suporte para git no Emacs nem em nenhum outro editor que eu conheço. Mas, dado que o AUCTeX é uma ferramenta tão poderosa, vale a pena se ajustar ao meio termo: “Emacs + AUCTeX” e Git no console. Pode ser meio confuso no começo, mas uma vez que se acostuma com esse arranjo… é puro zen! 😎

O que me traz à terceira opção: Dropbox (leiam mais no link Tour).

Essencialmente, o Dropbox é uma versão mais “user-friendly”, amigável, de softwares de controle de versões: o processo de instalação cria uma pasta no seu computador que fica arquivada no cloud deles… e, dessa forma, toda vez que qualquer arquivo denro dessa pasta for modificado, as diferenças são propagadas para o cloud, onde ficam arquivadas também. E é agora que vem o pulo-do-gato: uma das sub-pastas (dentro da pasta-mãe, compartilhada via o serviço do Dropbox) é chamada Public, de modo que qualquer arquivo dentro dessa pasta pode ser acessado por quem tiver o respectivo acesso permitido.

Até aqui, tudo soa exatamente como no git, acima… a diferença crucial é que o Dropbox não usa o git como ‘backend’, i.e., o Dropbox tem seu próprio método de atualização dos arquivos — que, até agora, não é muito bem conhecido publicamente.

Portanto, nesse sentido, o Dropbox é uma espécie de git light, i.e., é uma versão mais levinha e com menos recursos do que o git — não tão robusto, mas que satisfaz as necessidades da grande maioria dos usuários.

A grande vantagem é que não é preciso que “alguém” instale um servidor rodando git, o que torna tudo muito mais acessível a qualquer nível de usuários. 😉

Então, no final das contas, essa não é uma saída tão ruim assim… perde-se uns recursos dum lado, mas ganha-se em manutenção do outro — em geral, é um bom meio termo. E, de quebra, ainda é possível se usar TrueCrypt para se encriptar o conteúdo de toda a pasta, tornando tudo muito mais seguro (mesmo que o conteúdo da pasta esteja na ‘cloud’, ele estará encriptado 😉 ).


Pessoalmente, meu sonho de consumo seria um servidor rodando uma combinação dos seguintes:

juntamente com todo o indexamento feito pelo SPIRES! E, a essa mistura, adicionaria-se um servidor git, para que todos os usuários pudessem colaborar livremente e, de modo completamente transparente, publicar o artigo assim que acabado!

Dessa forma, numa mesma e única plataforma estariam centralizadas as melhores e mais robustas funcionalidades disponíveis no momento — seria o paraíso! 🙂

Bom… é isso aí: a diversão é mais-do-que-garantida, []’s! 😈

%d blogueiros gostam disto: