Criando Livros Eletrônicos e Físicos para o Kindle, com Software Livre

Hoje estão terminando os meus vinte dias de férias anuais (seriam trinta, mas eu sempre vendo dez, quando posso). Este ano, para variar, não pude viajar (pagar as contas é difícil!) e resolvi mergulhar de cabeça em uma empreitada há muito adiada:

1. Revisar todas as minhas obras já escritas até hoje (40% concluído);
2. Transportar todas para arquivos Markdown ou LaTeX, livrando-me, enfim, dos últimos RTF, DOC e ODT da minha vida literária (50% concluído).
3. Colocar tudo à venda na loja do Kindle Direct Publishing (25% concluído).
4. Profit!

Embora não tenha conseguido fazer tudo a que me propus (eu escrevi muito mais do que eu imaginava nessa minha vida), com a ajuda de algumas dicas colhidas com amigos virtuais (principalmente o Alec Silva), consegui publicar sete obras nestas minhas férias (possivelmente nove até domingo). Foi um esforço tremendo, que já consumiu mais um pouquinho de meus sofridos olhos na tentativa de enxergar as gralhas e os erros mesmo de ortographia ou grammatica. Mas foi compensador, porque eu começo a atravessar a fronteira entre ser um blogueiro que não ganha nada com isso e ser um autor amador da loja KDP, que não ganha quase nada com isso…

Essa minha postagem serve apenas para fazer o devido agradecimento ao Alec (e também ao Samuel Cardeal, que fez para mim uma linda capa de livro) e para documentar o processo que eu utilizei para a criação dos livros físicos e dos eletrônicos.

Espero que este artigo não seja interpretado como nada mais do que isso: o mapa do caminho que eu segui, para o caso de alguém querer pisar na mesma direção.

O Desafio

Agora que o Kindle Direct Publishing começou a oferecer a venda de livros físicos, comecei a me interessar pela possibilidade de publicar. Eu já vinha querendo isso, mas não me sobrava tempo para fazer, visto que eu trabalho oito horas por dia, cinco dias por semana, e tenho família para receber a minha atenção.

Minha experiência inicial com a KDP — publicando a primeira edição de Mythos Mineiros, em novembro de 2016, já me havia apontado algumas dificuldades. A publicação dos novos livros, agora em março, serviu para eu finalmente entender todo o processo e identifiar os desafios:

1. O PDF tem que ser em um formato aceitável. Infelizmente o formato A5 não é um deles (mas o A4 é, veja só). Assim, depois de já terminado o trabalho de formatação de um dos livros, O Reino Esquecido, tive de reformatar tudo em formato 6x9 polegadas, que é o preferido da Amazon.
2. Desenhar uma capa segundo as medidas, que variam conforme a quantidade de páginas do livro.
3. O livro eletrônico deve ser no formato MOBI. Descobri isso depois de sofrer durante horas tentando forçar a aceitação de um livro no formato EPUB.
4. Fazer capa não é fácil. Se fosse fácil, todo mundo fazia.

Software Utilizado

Texmaker

editor de textos

LibreOffice Writer

processador de textos avançado

TeXlive

sistema de publicação de textos avançado

Poppler Utils

conversores e manipuladores de arquivos PDF e PostScript

Pandoc

conversor de formatos de texto

GIMP

editor de imagens

Inkscape

editor de imagens vetoriais

Calibre

editor, conversor e leitor de livros eletrônicos

Além, é claro, do bom e velho Linux de guerra, que me acompanha desde 2000 e nunca me deixou na chuva para me molhar e a sua maravilhosa linha de comandos.

Fontes Utilizadas

É preciso ter certo cuidado na escolha das fontes a usar, porque muitas das fontes comerciais de hoje vêm com licenças bastante limitadoras. O preço de aquisição de um arquivo de fonte profissional é bastante salgado (de cinquenta dólares para cima) e as multas a que você corre risco se for pilhado violando suas licenças são de derrubar você no chão.

Por isso, para evitar qualquer tipo de risco financeiro ou de imagem, todos os meus trabalhos foram feitos usando fontes de utilização irrestrita — as que vêm incluídas por padrão no TeXLive, ou disponibilizadas pelo Google Fonts.

Estas foram as fontes que usei até agora em meus trabalhos:

Para corpo de texto:

• Cochineal
• Old Standard TT
• CMU Serif

Para títulos:

• Antykwa Poltawskiego
• Cochineal
• Alegreya Sans
• CMU Bright

Para capas:

• Rubik
• Alegreya Sans
• Iosevka
• Anton
• Caveat
• Caveat Brush
• Permanenet Marker

Para informações em código:

• Iosevka
• CMU Typewriter Text

Não estou incluindo imagens destas fontes para não sobrecarregar inutilmente meu servidor. Elas são fáceis de encontrar na Internet, seja no Google Fonts, seja no FontSquirrel ou na Open Font Library

Processo de Digitação

A primeira parte do processo foi “arrancar” os textos que se encontravam presos em formatos de arquivo binários. Algumas de minhas obras encontravam-se em arquivos do LibreOffice, outras em arquivos do Word (as mais antigas) e uma delas eu só encontrei em formato PDF (esta foi o “Praia do Sossego”, que foi submetido a uma revisão pela editora e cuja versão final só existia no arquivo de prova que ela me mandou antes de imprimir). Todos estes textos precisariam ser convertidos para um formato de texto plano para eu poder acrescentar as marcas de formatação do LaTeX.

No caso dos arquivos do LibreOffice isso é relativamente fácil, porque o Pandoc trabalha com esse formato:

$ pandoc -f odt -o ARQUIVO.tex ARQUIVO.odt

Dois segundos ou três depois desse comando no terminal, a pasta continha um novo arquivo contendo o texto do original já com as marcas de formatação LaTeX. Mamão com açúcar.

No caso dos arquivos do Word ou RTF foi um pouco mais difícil, porque eu primeiro tive que converter para o formato OpenDocument (para isso eu usei o LibreOffice). Essa etapa adicional “sujou” um pouco a formatação do arquivo, dificultando o processo depois.

Difícil mesmo foi o caso de Praia do Sossego, que só existia em formato PDF. Foi preciso primeiro arrancar o texto puro de dentro do PDF, usando o poppler:

$ pdftotext -nopgbrk ARQUIVO.pdf ARQUIVO.txt

De posse do texto em formato plano, entrou em ação o Texmaker:

Numa fase inicial o objetivo era localizar todos os erros semânticos do arquivo e corrigir, acrescentando as marcações LaTeX onde estivessem faltando. O texto em LaTeX é relativamente simples, como no bloco abaixo (eu acrescentei algumas formatações que não há no livro, só para ilustrar):

\chapter{Dezembro}  
  
\vfill  
  
Trouxe-a de \emph{passageira} naquela tarde, dirigindo tão rápida  
e loucamente quanto possível. Cada \textbf{esquina} era um perigo,  
mas uma oportunidade. Cada lágrima que se formava no olho caía na  
alma, mas secava no ar, sem que ela visse.  

Os comandos \emph e \textbf querem dizer “ênfase” e “negrito”, respectivamente.

Incluídos os comandos semânticos do LaTeX, a fase seguinte, ainda usando o TeXMaker, foi encontrar a formatação ideal. Nesta fase eu ainda não estava me preocupando com o livro eletrônico.

Para simplificar o processo de formatação e criar um fluxo de trabalho reutilizável (já que pretendo colocar dezenas de livros no Amazon ao longo desse ano, além de me lançar como free lancer para quem quiser fazer lay-out de livro comigo) eu utilizei as funções de inclusão de arquivo e de definição de macros, que são parte do LaTeX. Isso é simplesmente maravilhoso.

Cada PDF é criado a partir de um arquivo mestre, muito simples:

%%%%%%%%%%%%%%%%%% BLOCO DE INFORMAÇÕES BÁSICAS %%%%%%%%%%%%%%%
% Este bloco contém os dados do livro e carrega configurações %
% globais, que não há necessidade de mudar. 
\input{metadata} % Informações do livro % 
\input{configs} % Configurações imutáveis % 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%% BLOCO DE INFORMAÇÕES ESPECÍFICAS %%%%%%%%%%%%% 
% Certas opções do LaTeX são muito específicas e não precisam %
% ser carregadas para todos os livros. Elas residem aqui. %
\usepackage{multicol} % Se houver seções com colunas. % 
\usepackage{lettrine} % Se for usar letras capitulares. % 
\usepackage{paralist} % Opções extras para listas. % 
\usepackage{epigraph} % Se quiser epígrafes nos capítulo % 
\renewcommand{textsc}[1]{MakeUppercase{#1}} % Fonte sem SC %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%% BLOCO DE MONTAGEM DO LIVRO %%%%%%%%%%%%%%%%%
% As linhas a seguir não devem ser removidas, elas invocam os %
% comandos que montam o conteúdo do livro. % 
\begin{document} % Começo do processamento. % 
\maketitle % Inserção das páginas de rosto. % 
\saudação % Inserção de uma folha de saudação. % 
\tableofcontents % Inserção do índice. % 
\dedicatoria % Inserção da dedicatória, se houver. % 
\frontmatter % Inserção da parte pré-textual, se houver. % 
\mainmatter % Inserção do conteúdo do livro. % 
\backmatter % Inserção da parte pós-textual, se houver. % 
\end{document} % Fechamento do arquivo, não remover. % 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

No arquivo acima, as linhas iniciadas com “%” são comentários, não são processadas pelo LaTeX.

Cada livro fica dentro de uma pasta própria, e dentro de cada pasta ficam, obrigatoriamente, o arquivo-mestre LIVRO.tex e o arquivo de configurações globais configs.tex. Além destes, os seguintes arquivos são necessários para compilar o PDF:

1. metadata.tex — informações do livro;
2. saudação.tex — arquivo de saudação;
3. dedicatoria.tex — se houver dedicatória;
4. frontmatter.tex — parte pré-textual: prefácio, introdução, apresentação, etc.;
5. mainmatter.tex — o conteúdo da obra;
6. backmatter.tex — apêndices, glossário, índices, biografia, etc.

Destes, somente metadata.tex e mainmatter.tex são obrigatórios.

Os arquivos metadata.tex e configs.tex são onde eu pus a minha “magia negra” e o conteúdo deles eu não explico. Mesmo porque, o arquivo de configurações tem mais de quatrocentas linhas e você não está a fim de ler isso tudo.

Tudo o que você, de fato, precisa entender é como esses arquivos se concatenam através do pdfLaTeX, um dos muitos programas incluídos no TeXLive.

1. O arquivo mestre lê os metadados e as configurações globais;
2. Com estes arquivos ele aprende (ou “reaprende”, em alguns casos) o que fazer com os comandos de montagem;
3. Depois de ler todos os arquivos e comandos, na sequência, o pdfLaTeX monta o arquivo PDF.

Processo de Polimento e Revisão

Uma vez assegurado que o texto “compila” sem erros, é hora de personalizar a formatação. Isto pode ser feito através do arquivo de metadados, onde existem macros para escolha de fontes, determinação de tamanhos de texto, espaçamentos entre parágrafos, tamanho de página, etc. Estas informações são usadas pelo pdfLaTeX, em conjunto com as configurações globais (config.tex) para determinar a aparência do PDF gerado.

Obtendo a aparência desejada, é hora de polir e revisar, o que significa:

1. Lidar com as linhas órfãs e viúvas (o LaTeX não se preocupa com isso, cabendo ao usuário resolver esses conflitos);
2. Lidar com as linhas muito vazias (rios) ou muito cheias, especialmente estas últimas, que enfeiam para caramba o livro;
3. Localizar erros de alinhamento e quebras de páginas;
4. Revisão ortográfica e gramatical.

A revisão ortográfica e gramatical tem que ser feita no olho, mesmo, pois não se pode confiar em um verificador automático. Mas eu uso também um verificador, para aparar os erros mais claros— especialmente para localizar pontuação faltante ou frases truncadas. Como o TeXMaker não tem essa funcionalidade, eu reconverto o arquivo para OpenDocument e o abro no LibreOffice, onde tenho instalados um ótimo corretor gramatical e um corretor ortográfico em português brasileiro.

$ pandoc -f latex -o /tmp/ARQUIVO.odt ARQUIVO.tex

Observe que eu jogo o arquivo gerado para a pasta temporária do Linux, porque eu não vou precisar dele por muito tempo.

Agora eu abro o LibreOffice e o TeXMaker lado a lado e vou corrigindo no segundo os erros que o primeiro aponta. É um trabalho bem chato, mas revisar é chato.

Criação do PDF para o livro físico

Quando tudo está certo no texto do livro, é hora de gerar pela última vez o PDF. Para evitar algum problema de referências cruzadas ou índice incorreto, é bom fazer isso duas vezes seguidas:

$ pdflatex ARQUIVO ; pdflatex --interaction=batchmode ARQUIVO

É bom dar uma última olhada se ficou tudo bonito e do jeito que se quer, porque a produção de documentos por esse processo não é WYSIWYG (visual, what you see is what you get, “o que você vê é o que você terá”). Os grupos de usuários de LaTeX costumam dizer que ele é um sistema WYSIWYM: what you see is what you mean, “o que você vê é o que você manda” (ou “quer”).

Criação da Capa para o livro físico

Com o livro físico já pronto (a parte de dentro), é preciso criar uma capa legal para ele. Para isso eu uso o dois softwares, o GIMP e o Inkscape. Dos dois, o Inkscape é o mais útil, mas o GIMP possui algumas funções que podem ser úteis na manipulação de imagens, afinal ele só serve para isso, enquanto o Inkscape é mais voltado para lay-out.

Lá na própria página da Amazon você pode baixar templates para a criação de capas, como esse abaixo (em resolução reduzida, só para fins ilustrativos):

O Inkscape importa o arquivo PDF e o converte para SVG (seu formato nativo). A partir daqui é só inserir no arquivo as imagens e caixas de texto que você quiser, não esquecendo de remover, no momento certo, os textos de ajuda deixados pela Amazon, e também as guias de formatação.

Quando tudo estiver do seu agrado, o Inkscape permite exportar o arquivo como PDF 1.5, então já é hora de ir testar a obra no KDP.

Obtenção de imagens

Meus livros não têm ilustrações interiores. Para as capas eu tenho procurado utilizar somente imagens antigas de uso livre (“domínio público”), fotografias que eu mesmo tirei, imagens que eu mesmo criei usando o GIMP e, em último caso, imagens obtidas do WikiMedia Commons e do Creative Commons. Afinal, não há nada mais chato do que descobrir um trabalho seu apropriado por uma outra pessoa, como eu mesmo já experimentei uma vez.

Upload do livro físico

Na sua bookshelf você tem os links para inclusão do novo livro físico (paperback). Siga as instruções, envie o miolo e a capa e aguarde o processamento (demora entre dois e cinco minutos).

Nesse momento você vai reparar que existe a opção de criar a capa usando o programa da própria Amazon, mas eu prefiro fazer eu mesmo, porque as opções ali são bem limitadas.

Um problema que você vai enfrentar no começo são as rejeições de seu lay-out de capa. Isso acontece porque você demora a pegar as “manhas” da Amazon. Eles são bem exigentes quanto à qualidade gráfica dos trabalhos (afinal, a reputação deles está relacionada à qualidade do que vendem) e costumam recusar sua capa se ela tiver alguns defeitos. Eu gostaria de chamar a sua atenção para cinco erros bobos (todos cometidos por mim em algum momento) que vão te dar dor de cabeça:

1. Imagens de baixa resolução podem resultar em capas borradas. No meu caso isso não é um problema, pois as imagens de baixa resolução que eu usei eram mesmo para ser borradas, mas você não deve descartar esse alerta se não sabe o que está fazendo.
2. Imagem sobreposta a texto. Isso costuma acontecer quando você trabalha com várias camadas e um “cantinho” de uma camada se sobrepõe a uma caixa de texto.
3. Texto ilegível por causa de áreas de imagem. Esse é um defeito muito comum em capas feitas “nas coxas” (eu já vi isso até em trabalhos de editoras). Acontece quando você coloca um texto sobre uma área cuja cor interfere com a das letras. Imagens de fundo com muito contraste de cor costumam causar isso, porque há certas áreas muito escuras e outras muito claras, então partes do texto se confundem com o fundo.
4. Texto fora da área útil da página. É possível colocar uma imagem na borda da página e deixar um pedaço “sangrar” para fora. Mas isso não pode acontecer com nenhum tipo de texto. Eu tive que refazer a capa de “Amores Mortos porque aquele texto que forma o plano de fundo da parte frontal da capa estava”sangrando”.
5. Camadas superpostas. Esse foi outro caso em que a capa de “Amores Mortos” me deu dor de cabeça. A contracapa tem dois artefatos (minha foto e minha biografia) que se sobrepõe como se tivessem sido coladas superpostas em uma folha de caderno (inclusive uma parte do texto da biografia ficava oculto). Tive de refazer essa parte do lay-out, ou a Amazon não publicaria o meu livro.

Criação da capa do livro eletrônico

Este passo é bem simples. É o momento em que eu uso o GIMP obrigatoriamente (se não o tinha usado na manipulação da imagem da capa antes). Consiste em importar o PDF da capa montada e selecionar a parte direita dele (que corresponde a capa da frente do livro físico) e copiar. Esta área copiada deve ser colada como novo arquivo (“Editar > Colar como > Novo Arquivo”) e em seguida devemos redimensionar o arquivo para perto do tamanho mínimo aceito pela KDP. Eu mando redimensionar “proporcionalmente” e escolho a altura de 1024 pixels em 96 dpi. Até agora o KDP não reclamou.

Nos primeiros livros eu usei o formato TIFF, mas logo descobri que os arquivos ficam imensos e isso, certamente, vai fazer os meus leitores chiarem. Então agora estou usando JPEG, enquanto a KDP não começar a aceitar PNG.

Criação do livro eletrônico

Com o livro físico já pronto e aguardando a publicação pelo KDP, é hora de passar ao livro eletrônico. Para isso vamos recorrer novamente ao Pandoc:

$ pandoc -f latex -o ARQUIVO.epub ARQUIVO.tex

Este passo demora no máximo cinco segundos, se o arquivo for bem grande. Você vai ver a criação de mais um arquivo em sua pasta de trabalho. Mas esse arquivo é praticamente inútil. O Amazon não o aceita de jeito nenhum, e não tem choro e nem reza braba que mude isso. Mas tem um programa maravilhoso: o Calibre.

Abrimos o arquivo EPUB no Calibre ebook-edit e vamos consertando os pequenos problemas. Para começar, eu substituo a folha de estilos gerada pelo Pandoc por uma personalizada. Em seguida, reordeno as páginas, para que o arquivo tenha uma sequência lógica:

1. Capa (com imagem)
2. Folha de rosto (dados da edição)
3. Folha de saudação (dados de copyright e info de contato)
4. Sumário
5. Parte pré-textual (se houver)
6. Capítulos do conteúdo
7. Parte pós-textual (se houver)

O EPUB gerado pelo Pandoc é bastante “limpo” em relação ao conteúdo, mas é bastante confuso e “sujo” em relação à formatação e à estrutura. Mas o Calibre tem um comando de “verificação” que lhe permite ver todos os erros e corrigi-los. Um erro particularmente desagradável do Pandoc é permitir caracteres acentuados nas “id” de seções. Como as URL dentro de um EPUB não aceitam caracteres além do 128º bit, isso quer dizer que todos esses links ficam quebrados.

Por fim eu insiro a imagem no arquivo da capa e defino esse arquivo como capa. Feito isto, valido pela última vez e fecho o arquivo.

Agora vem o pulo do gato.

Arquivos EPUB são relativamente grandes e costuma haver problemas de conversão. Então eu descobri que a conversão para MOBI resolve isso bem, porque esse formato é mais reduzido (em geral 45% ou menos do tamanho do EPUB em kbytes) e porque, aparentemente, o formato interno do Kindle, o AZW3, é mais próximo do MOBI do que do EPUB. A conversão é feita por um utilitário de linha de comando que vem com o Calibre:

$ ~/calibre-bin/calibre/ebook-convert ARQUIVO.epub ARQUIVO.mobi

Embora seja o arquivo MOBI que nós vamos enviar ao Amazon, eu não apago o arquivo EPUB, porque na eventualidade de revisões e reedições eu não preciso passar de novo por todo o processo de conversão.

Tempo Requerido

A maior parte do tempo dispendido se refere ao trabalho criativo. As tarefas mecânicas, como conversões e revisões, são todas relativamente rápidas — pelo menos para mim, que já aprendi todo o processo.

1. Conversão do arquivo ODT para LaTeX: segundos;
2. Conversão do arquivo PDF para TXT: segundos;
3. Inclusão ou revisão das marcas de formatação LaTeX: indefinido, depende do tamanho do arquivo, de quão “sujo” ele saiu e de quão complicada será a formatação;
4. Inclusão dos metadados no arquivo: alguns minutos;
5. Um passo de compilação do pdfLaTeX: entre cinco e dez segundos;
6. Reconversão de LaTeX para ODT usando o Pandoc: segundos;
7. Revisão ortográfica e gramatical: indefinido, horas ou dias;
8. Compilação do PDF: segundos;
9. Criação da capa no Inkscape: indefinido, entre alguns minutos e um dia inteiro;
10. Upload dos arquivos no KDP: minutos;
11. Validação dos arquivos pelo KDP: entre 5 e 30 minutos;
12. Prova tipográfica virtual: entre 5 e 30 minutos;
13. Publicação pelo KDP: entre 40 minutos e 72 horas;
14. Conversão de LaTeX para EPUB usando o Pandoc: segundos;
15. Edição do EPUB usando o Calibre: trinta minutos a uma hora;
16. Criação da capa do livro eletrônico: um minuto ou menos;
17. Upload do livro eletrônico no KDP: entre 30 segundos e 5 minutos;
18. Validação de arquivos pelo KDP: simultaneamente ao upload;
19. Prova tipográfica virtual: entre 5 e 30 minutos;
20. Publicação pelo KDP: entre 40 minutos e 72 horas.

Conclusões

Como você poder ver, trabalhando simultanemante na revisão e na conversão de mais de um livro, em um esquema “multitarefa”, é possível lançar vários livros num espaço de tempo realmente curto. Como eu fiz.

A reutilização do código permite que o retrabalho seja mantido em níveis mínimos. Cada um dos sete livros que eu fiz para este mês demorou menos que o anterior, à medida que eu simplificava o processo e incorporava ao configs.tex as soluções que eu havia encontrado para os problemas do livro anterior. O primeiro livro me custou uma semana, o último eu demorei uma noite (seis horas) e mais uma manhã (quatro horas).

Fica assim evidente que é perfeitamente viável utilizar exclusivamente software livre para criar livros de qualidade aceitável para vender na KDP. E se você, por algum motivo, acreditar que há alguma coisa que pode ser melhorada na formatação de meus livros, é só me dizer o que é e eu implemento em futuras edições. Muita coisa eu não fiz porque eu não tenho bom gosto, não porque fosse impossível fazer.

Conteúdo publicado conforme a licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 4.0 Internacional (CC BY-NC-SA 4.0). COPIAR NÃO É PRESTIGIAR. NÃO PIRATEIE, NÃO SACANEIE!