Ponto V!

Home Arquitetura Programação SVG: O primo Itt³ dos padrões abertos
SVG: O primo Itt³ dos padrões abertosImprimir
Escrito por Daniel Monteiro

SVG não é um formato muito valorizado dentro do eco-sistema de formatos do W3C. Primo menos famoso do HTML5, infelizmente não virou buzzword. Um arquivo neste formato, se bem preparado, tem a capacidade de substituir o Flash em muitas aplicações. Mas ele não se limita apenas à web. O SVG pode ser um poderoso formato de troca de dados, bem como um excelente formato de saída gráfica de ferramentas. Gostaria de, neste curto artigo, expor pontos positivos e negativos, a fim de compartilhar minha estima por este formato vetorial.

Primo Itt - Família Adams

Nesse atual cenário de fragmentação e guerras de plataformas móveis, cada vez mais próximas dos desktops, com cada vez mais novos tipos de dispositivos surgindo para roubar um naco do mercado desktop, convém estar preparado para todo tipo de tamanho de exibição. E este é um cenário onde gráficos vetoriais, especialmente o SVG, tem a chance de brilhar. Não importa o tamanho da sua tela, um gráfico vetorial sempre ficará cristalino, liso e nítido. Neste cenário, a única limitação possível é o fill-rate ( a taxa de preenchimento de pixels na tela, que já seria uma limitação no caso de gráficos bitmap ). Convém lembrar que hoje, mais que em qualquer época que o mercado de jogos já viveu, temos uma onda de jogos antigos sendo ressuscitados tanto via emulação, quanto porte ou mesmo reconstrução. Por que não facilitar o trabalho usando gráficos escalares? Eles vão ter a mesma aparência, não importa se é no seu pulso ou numa projeção na Lua. Quem diz é a Microsoft Research¹...

Outra característica interessante é a discretização de elementos. Ao contrário de um gráfico bitmap, seu sistema se dedicará a desenhar cada elemento da gravura de forma separada. Ele verá o que é o rosto e o que são os olhos da bela ninfa sendo desenhada na tela. Ele terá total ciência de o que é uma barra de ferro e o que é sua sombra. Então POR QUE não aproveitar essa característica e exercer algum controle sobre esse desenho? Talvez você prefira uma ninfa ruiva?! Ou talvez as grades da delegacia vejam o nascer do sol, com suas sombras aos poucos se tornando mais fracas, dando lugar a outros decalques outrora apagados, surgindo com uma fugaz vermelhidão digna da mais bela aurora. Tudo isso pode ser feito quando se tem elementos discretos em uma imagem. Claramente esta não é uma característica única de uma imagem vetorial, mas que apenas faz sentido quando se pode modificar dinamicamente os elementos sem perda de informação e sem força bruta. E por que não criar uma correspondência entre elementos específicos da figura e classes de seu sistema? Tudo depende de onde se quer chegar.

Apesar de toda a versatilidade do formato SVG, a parte mais básica de seu léxico é composta por um punhado de comandos de desenhos dispostos como campo string de uma tag XML. Se sua aplicação ou ferramenta realiza algum processamento geométrico ou gráfico de qualquer natureza e tudo que se tem é uma saída textual, por que não complementar esta saída com uma visuzalização semântica SVG opcional? O boilerplate realmente necessário é mínimo diante de quanto se pode ganhar de conhecimento de seu sistema a partir da correta interpretação de sua entrada e saída. Muito possivelmente seu ambiente de programação já disponibiliza infraestrutura de externalização XML, mas mesmo que não seja o caso, é realmente muito simples externalizar texto simples contendo tags XML. Considere por um instante as possibilidades de se trabalhar com os streams de entrada e saída padrões e toda a gama de pipeline de processamento de assets que se pode criar encadeando ferramentas! Repare também que por ser XML, pode-se colocar qualquer informação nos arquivos. Então não é porque um passo do pipeline não usa aquela informação que ela não estará disponível para os passos seguintes.

Como não existe solução para todos as perguntas, SVG não esta livre de seus problemas. Muitos deles não são realmente do formato em si, mas inerentes tanto a sua natureza XML quanto ao mercado de software gráfico. O formato em si é simples - talvez até simplório sob determinada ótica- não sendo muito diferente do formato aceito pelo comando DRAW, presente nos interpretadores BASIC residente dos computadores de 8-bits, comuns nos anos 70 e 80. No entanto, o desejo de abranger e relaxar os requerimentos de um arquivo bem formado permite que arquivos bastante complicados de se ler sejam criados, e acredite, seu programa favorito irá produzir alguns deles. Esta economia pouco vantajosa acaba esbarrando em um problema ainda maior: arquivos XML gerados pelas ferramentas do mercado são excessivamente grandes. Alias, é difícil acreditar que haja uma especificação de SVG especial para dispositivos móveis (o SVGTiny) que também seja baseada em XML. Arquivos XML não apenas são mais lentos para serem lidos, mas são também mais complexos de se manipular via código. A não ser que se trate de uma ferramenta de processamento offline, pré-processamento para um arquivo flat-file é altamente recomendado.

Do ponto de vista de suporte de ferramental, o SVG tem opções pagas e gratuitas. Existe a ferramenta open source Inkscape, que dá o melhor suporte ao SVG (sendo este seu formato nativo), mas que ainda tende a ser bastante verborrágica em seu formato final. Tem como vantagem o fato de permitir inspecionar o DOM do arquivo carregado em memória, preservando quaisquer metadados não-SVG presentes no XML original. Sem dúvida uma característica excelente quando se trata de uma visualização semântica.

Sistemas comerciais como o Adobe Illustrator e o Corel Draw! tem suporte em nível variavel. O Adobe Illustrator tem boa interpretação do formato, mas pode confundir algumas cores ou tentar converter de um sistema de cores para outro sem sua permissão. Sem falar que seu arquivo final é compactado, provavelmente já pensando em publicação na WEB. Já o Corel Draw! é surpreendemente incapaz de lidar adequadamente com SVG. Não apenas interpreta erroneamente arquivos que usem coordenadas relativas (ele tende a considerar tudo como absoluto), mas também exporta arquivos usando um léxico incomum, apesar de mais claro. Melhor continuar no Inkscape.

Apesar da situação pouco animadora quanto a variedade de ferramentas (não existe opção aberta para exportação de SVGTiny, por exemplo. A única mais conhecida pertence ao kit de desenvolvimento Symbian, da Nokia), a situação pode melhorar já que seus primos mais famosos do HTML5 estão fazendo mais sucesso. Use o SVG, espalhe suas vantagens e as ferramentas surgirão. Gosto de citar (totalmente fora de contexto) a lei de MetCalfe²: "O valor de um sistema de comunicação cresce na razão do quadrado do número de usuários do sistema". Infelizmente, esse é um ponto importante que ainda não pode ser coberto.

Tanto para fins de depuração e teste quanto para resultados visuais limpos e bem projetados, o SVG pode ser sim, uma arma poderosa. Sua flexibilidade e facilidade de composição permitem tanto a boa geração automática, quando o desenho usando ferramentas de desenho ou a composição manual do arquivo. Dê zoom a vontade e tudo que você verá são raízes¹!

 


Comentários (2)
  • Henrique Sant'Anna
    avatar

    Parabéns pelo artigo, Daniel. Também torço pela popularização do formato.

  • Anônimo
    avatar

    :woohoo: esse formato é ótimo para games parece pois da para crescer ou diminui uma imagem sem perda de qualidade :D

Escrever um comentário
Your Contact Details:
Gravatar enabled
Comentário:
[b] [i] [u] [url] [quote] [code] [img]   
:angry::0:confused::cheer:B):evil::silly::dry::lol::kiss::D:pinch::(:shock:
:X:side::):P:unsure::woohoo::huh::whistle:;):S:!::?::idea::arrow:
Security
Por favor coloque o código anti-spam que você lê na imagem.
LAST_UPDATED2  

Busca

Linguagens

Twitter