Produção editorial digital: 6 bons motivos para aprender HTML e CSS
Para aqueles que estão migrando da produção editorial tradicional para os eBooks, ou planejam entrar agora no iniciante mercado de criação de livros digitais, há uma pergunta que não quer calar: preciso mesmo entender de código para criar um eBook? Não seria melhor esperar por uma solução que vá tirar dos designers visuais o peso de lidar com linhas intermináveis de código? Alguém já deve estar pensando em alguma ferramenta para resolver isso… A dúvida é mesmo cruel, já que do ponto de vista da apresentação gráfica do conteúdo, da parte prática mesmo, a divisão entre o mundo web e o editorial é vasto, muito vasto. Além disso, os métodos e ferramentas para desenvolver produtos destinados à impressão profissional já são bem conhecidos pelos profissionais e usam, de forma geral, o sistema WYSIWYG. Incluir mais um conjunto de conhecimentos com características tão diferentes na já atribulada rotina dos profissionais da área gráfica não é tão fácil assim.
Para esclarecer esse dúvida, mas também para oferecer algum “incentivo”, separei cinco argumentos fundamentais para convencer o pessoal da produção editorial print-only a entrar de vez no fantástico – às vezes nem tão fantástico assim, é verdade – mundo das linguagens web. Vamos a eles:
1. HTML e CSS são ingredientes vitais em várias iniciativas do digital publishing
Vivemos um estágio onde há diferentes tipos de livros e revistas digitais, com formas de produção e plataformas de leitura específicas, algumas abertas, outras proprietárias, e a todo momento vemos surgir novos tipos. Todos podem ser igualmente chamados de publicações digitais. Em qual deles vale a pena investir profissionalmente? Se pudéssemos apostar em um terreno seguro, acima de qualquer discussão sobre padrões, para quem quer navegar nessa onda dos eBooks, esse seria o das linguagens web. Elas são os blocos de construção básicos dos principais tipos de livros digitais, ePUB e Kindle, e estão por trás de várias outras iniciativas que transformam conteúdo web em livros eletrônicos, como o Pressbooks. Mesmo livros e revistas no formato de aplicativos podem ser construídos com a ajuda delas, e como a web não vai à lugar nenhum, é bem provável que essas tecnologias padrão sejam relevantes por muito tempo – a decisão da Adobe em focar em HTML5 para desenvolvimento mobile, deixando de lado o Flash Player para estas plataformas, é um forte sinal nesse sentido. Entender e dominar o idioma da web é meio caminho para se manter “dentro do jogo”. Fugir dele é inútil.
2. Programas totalmente WYSIWYG para criação de conteúdo web tem sérios problemas
Eles existem, e tem suas aplicações, mas são pouco flexíveis e inserem ainda mais complexidade no processo de desenvolvimento. O que se pode fazer com eles é limitado, por que a web – e o mundo do eBook, que bebe da mesma fonte – é um meio complexo, cheio de possibilidades, e deve ficar mais complexo ainda com o HTML5. Ao contrário do setor gráfico, onde ocorre uma forte padronização das tecnologias e delimitação do ambiente, métodos e programas de produção – basicamente construídos sobre o PostScript/PDF –, no mundo web não há um ambiente restrito que delimite tão fortemente o contexto de apresentação gráfica da informação. Basta imaginar os diversos tamanhos de tela disponíveis, métodos de interagir com a informação (teclado, mouse, touch), modos de cor, versões de programas, velocidades de conexão, plataformas, níveis de suporte aos padrões… Enfim, não há uma única maneira padronizada e universalmente aceita de preparar um conteúdo automaticamente diante desse cenário, pois essa é a natureza do meio: ilimitado, aberto, colaborativo. É por isso que é tão difícil criar um programa totalmente visual para conteúdo baseado em linguagens web. Até agora, não há nenhum capaz de lidar com toda a gama de possibilidades e problemas inerentes à produção, seja para a web ou para eBooks. Na prática, para resolver os problemas criados por eles é preciso ainda mais conhecimento das linguagens.
3. Conversões automáticas entre formatos não são confiáveis para uso profissional
Alguém pode argumentar que, para certos tipos de livros – de texto puro, por exemplo – é possível produzir um eBook “satisfatório” com uma simples conversão entre formatos, digamos, de PDF para ePUB, sem lidar com código. Para conversões amadoras, sem muitas expectativas ou controle sobre o resultado final, talvez seja verdade, mas essa não é uma opção para quem quer trabalhar profissionalmente com eBooks e precisa entregar um produto livre de erros. Conversões automáticas, por mais eficientes, não são capazes de antever como o arquivo será interpretado em cada eReader, e geralmente falham nesse quesito fundamental: regularidade. A única maneira garanti-la é conhecer a fundo como se comporta o código gerado e como será interpretado nos sistemas de leitura, para então identificar e solucionar os problemas… e para publicações de layout mais complexo – que devem frutificar com a chegada do EPUB3 – este tipo de conversão automática tem menos utilidade ainda.
4. Os “idiomas da web” são linguagens relativamente simples de se aprender
O HTML não é uma linguagem de programação, mas uma linguagem de marcação. A curva de aprendizado desta categoria de linguagem de codificação é relativamente pequena, pois suas regras básicas não são complexas. Em pouco tempo é possível aprender seu contexto, regras e potencialidades. Acontece o mesmo com as folhas de estilo CSS. Há muito mais desafio em aprender uma linguagem de programação “pra valer” como o PHP ou o Python.
5. Os recursos de aprendizado disponíveis são inúmeros e acessíveis
No início do desenvolvimento web, há 20 anos, aprender a lidar com HTML era para poucos: simplesmente não havia material disponível para aprender a linguagem. Não havia cursos, tutoriais, publicações, Youtube, vídeocasts e toda a sorte de materiais instrucionais disponíveis hoje. Com dedicação e persistência é possível até mesmo aprender a lidar com essas linguagens de graça – embora um bom curso presencial seja uma excelente forma também, mais eficiente para muitas pessoas.
6. Novas competências = novas oportunidades
Uma pesquisa recente mostra que a indústria editorial está tendo dificuldades em agregar competências digitais no seu fluxo de trabalho (isso nos EUA, mas acredito que o mesmo se aplica aqui). A integração do mercado editorial com tecnologias mobile está em plena expansão e profissionais capazes de lidar com os dois mundos (impresso e digital) são/serão valorizados no mercado. O nível de demanda para produção de conteúdo digital tem crescido proporcionalmente com a popularização dos dispositivos móveis, e há muitas oportunidades surgindo, em várias frentes, não só no terreno do digital publishing. Se consideramos também as projeções de crescimento do mercado de livros digitais, e da web de forma geral, não há dúvida que essa lacuna ficará mais evidente.
Padronização do design dos eBooks: hyperlinks
O suporte a folhas de estilo CSS nos leitores de ePub é muito irregular, para não dizer sofrível. Mesmo atributos simples como uma simples alteração de cor nos hyperlinks não é garantida em todos os leitores. O iBooks, leitor de eBooks da Apple que usa o motor de renderização Webkit, é um exemplo disso. Recusa-se a aceitar a alteração na cor dos links, mesmo se o CSS for aplicado inline, junto ao código, o que deveria ter a preferência sobre outros estilos. A cor padrão aplicada pelo programa é um púrpura (fig. 1) que possui pouco contraste com a cor preta padrão do texto. O resultado é que muitos links são difíceis de encontrar à primeira vista. Mudar a sua cor da forma padrão não funciona no iBooks. Por exemplo: ao usar o CSS a { color: red; }, nada acontece. A mesma cor púrpura de sempre é utilizada. Se aplicarmos estilos inline (diretamente no código HTML) a cor é alterada, mas este tipo de aplicação do CSS é difícil de introduzir e atualizar. Isso acontece no iBooks, no Adobe Digital Editions (e em todos os eReaders que usam a mesma base, o Adobe RMSDK) estilos inline não são obedecidos.
Figura 1: Um doce para quem encontrar os links neste texto 
Investigando o problema
Mas será que não é mesmo possível alterar essa cor mantendo um padrão entre os diferentes eReaders? E outros atributos, como underline e cor de fundo? Como outros programas/dispositivos leitores se comportam nesse quesito? Para buscar soluções, criei um ebook de teste (Baixe: Padronização do design dos eBooks: links (78)) com diversas formas de se estilizar um link via CSS para testá-lo em diversos eReaders, e verificar como se comportam de acordo com o tipo de código: estilos inline, em folhas de estilo externas ou no cabeçalho do HTML. Como o iBooks utiliza o Webkit para renderizar as páginas, testei também várias extensões CSS desta engine para verificar como o eReader da Apple se comporta. As extensões CSS (ou CSS vendor extensions) do Webkit, assim como as de outros motores de layout como o Gecko (Firefox) e Trident (Internet Explorer), são propriedades de estilos CSS que afetam somente os programas que os utilizam como base, e não funcionam nos programas que não as usam. Assim podemos aplicá-los para (tentar) resolver problemas como estes, sem prejuizo algum para a interpretação do código do ePub.
Fiz algumas descobertas interessantes:
- Como havia dito, uma parte dos eReaders, entre eles os que usam a mesma base do Adobe Digital Editions, simplesmente não reconhecem estilos inline, aplicados junto do código. O CSS especificado em uma classe ou diretamente à tag <a>, por meio de um CSS externo, foi aplicado corretamente. O iBooks, por sua vez, reconheceu os estilos inline, mas não os externos (por classe ou aplicados à tag <a>
; - No iBooks, se o texto do link estiver envolto por uma tag span, é possível alterar a cor do texto do link e a cor de fundo, mas o underline é mantido em outros leitores, pois é uma propriedade do link em si;
- O CoolReader (programa relativamente popular e bastante utilizado na plataforma Android) não reconheceu os estilos aplicados por meio de “id” ou diretamente à tag <a> no CSS externo, apenas aqueles aplicados por meio de “class”;
- Ao enclausuar o texto do link em uma tag <span>, o Nook ignorou a cor de fundo do link;
- A extensão -webkit-text-fill-color é capaz de alterar a cor do texto do link no iBooks sem prejudicar a funcionalidade. A boa notícia é que outros eReaders que utilizam o Webkit também se beneficiam da mudança. Nos meus testes, os programas de leitura Stanza (iPad), iBis Reader (Online) e Moon+ Reader (Android) responderam à propriedade CSS -webkit-text-fill-color, ou seja, aplicaram a cor corretamente;
- Inserir no ePub o arquivo com.apple.ibooks.display-options.xml, um arquivo geralmente utilizado em ePubs de layout fixo do iBooks, faz com que o programa aceite qualquer cor de link (permite também que fontes embutidas sejam utilizadas), mesmo sem a extensão -webkit-text-fill-color. Mas como é usado apenas no iBooks, não é uma opção muito universal;
- Parece ser uma prática relativamente comum entre vários eReaders (Stanza, Laputa, FBReader e mesmo o Aldiko para Android) adotar uma espécie de pré-processamento do código, ou seja, ao ser aberto, o conteúdo do ePub é extraído e é renderizado pelo programa com a ajuda do seu próprio CSS, ignorando o CSS embutido no arquivo. Alguns leitores oferecem a possibilidade de carregar esse CSS especificado pelo designer, outros não (Laputa, FBReader, Stanza Desktop). Isso dificulta muito a padronização do projeto visual do ePub, pois cada eReader tem sua opinião sobre a melhor forma de apresentar o ePub, e ela nem sempre é a melhor possível. Seria importante que os programas permitissem que os estilos propostos pelo designer fossem carregados primeiro, assim como acontecem nos navegadores no caso de websites. Alguém já navegou em algum site onde o design do site foi todo redefinido pelo navegador ao ser aberto, sem sua solicitação? Creio que não.
Galeria 1: Imagens das telas de alguns eReaders. Note a discrepância na interpretação dos links.
Conclusões
A melhor abordagem ao estilizar links no ePub é aplicar uma classe qualquer à tag em questão e especificar os estilos em um arquivo CSS externo para afetar os eReaders baseados no RMSDK da Adobe, incluindo a propriedade -webkit-text-fill-color para os programas que usam Webkit, principalmente o iBooks. Não enclausure o texto do link em nenhuma tag, aplique o estilo à classe, se preciso. Assim, para especificar cor nos links dos seus ePubs inclua sempre no seu código:
/* HTML */
<a class=“link” href=“http://www.seulink.com”>Texto do link</a>
/* CSS */
a.link {
color: #suacor;
-webkit-text-fill-color: #suacor;
}
Esta é solução mais universal para estilização de links. Ainda assim, alguns eReaders como o FBReader e o Laputa Reader para Android sobrepõem completamente o CSS criado pelo designer do ePub. Outros, como o Moon+ Reader e o Aldiko, também para Android, só aceitam o CSS se o leitor especificar deliberadamente essa opção nas configurações do programa. Neste caso, não há muito o que fazer, mas como o código não interfere nos demais estilos e na performance do arquivo, é uma opção viável.
Lembrando que essa abordagem de usar extensões Webkit pode ser aplicada para buscar a solução de outros tipos de problemas de interpretação do CSS nos eReaders que usam esse “motor”, como o iBooks e o Stanza (iPad), mas não a utilize isoladamente para recursos fundamentais do livro, pois somente os eReaders com Webkit serão capazes de apresentá-los. O ideal seria mesmo que a especificação ePub (e o CSS que ela suporta) fosse implementada corretamente nos eReaders, mas até lá soluções como essa serão necessárias.
Padronização do visual do ePub: futuro distante
A dificuldade em se aplicar cores a um simples hyperlink mostra a complexidade em se produzir ePubs que fujam do default dos programas e busquem uma padronização no projeto visual do Livro eletrônico. Ainda estamos longe do estágio em que um arquivo com layout mais avançado seja lido de forma padronizada nos mais diversos eReaders. Quem sabe com a adoção do ePUB3 isso começa a se resolver. Até lá, muito teste e cautela na aplicação de estilos CSS para o ePub.
Revolução eBook
