- Mesmo um EPUB sem DRM que passou na validação pode ser tratado como “corrupted” no Kobo, e o problema não vem de erro no formato do arquivo, mas de compatibilidade com o mecanismo de renderização
- epubcheck é a ferramenta de validação padrão de fato para verificar a estrutura do EPUB e a conformidade com as regras, mas não detecta problemas do parser CSS antigo de renderizadores específicos
- O Kobo usa o RMSDK, mecanismo proprietário de renderização de e-books da Adobe, que foi criado com base no EPUB2 e depois recebeu uma atualização leve para EPUB3, sem ter sido modernizado
- A causa do problema era uma única linha,
max-width: min(150px, 30vw);, e esse código válido de CSS level 4 não é suportado pelo RMSDK, fazendo o carregamento do livro falhar no Adobe Digital Editions e no Kobo
- Para verificar compatibilidade com Kobo, só o epubcheck não basta; é necessária uma validação adicional abrindo de fato o arquivo no Adobe Digital Editions
O problema começou com um EPUB que passava no epubcheck
- Ferramentas da Adobe muitas vezes são usadas porque o Creative Suite é padrão da indústria ou porque faltam alternativas, e a crítica deste texto parte de uma frustração com o software da Adobe
- O novo livro foi distribuído como um arquivo
EPUB sem DRM fornecido diretamente aos leitores e, antes da distribuição, passou por várias etapas, incluindo a verificação com epubcheck
- O
epubcheck é a ferramenta padrão de fato para confirmar que um e-book está bem estruturado, e só aprova quando o manifest reflete sem omissões todos os trechos e imagens do livro
- Se a ordem dos elementos HTML estiver incorreta ou houver até mesmo um pequeno desvio das regras do International Digital Publishing Forum, a validação falha
- Fazer um arquivo passar 100% no
epubcheck não é fácil para iniciantes, mas para quem trabalha com publicação ele funciona quase como um linter de tipos ou uma suíte de testes formais
- A expectativa natural é que um livro aprovado no
epubcheck funcione em qualquer leitor ou aplicativo compatível com EPUB
O erro “corrupted” só acontecia no Kobo
- O novo livro passou no
epubcheck ruleset 3.3, mas um leitor relatou o aparecimento da mensagem “corrupted”
- Para verificar a possibilidade de compatibilidade retroativa, também foi oferecida uma versão EPUB2, mas esse arquivo igualmente seguia as regras por completo e apresentava o mesmo problema
- O leitor informou que o livro não abria em várias gerações de dispositivos Kobo
- O mesmo EPUB funcionava sem problemas em outros ambientes, como Amazon Kindle, Apple Books e Thorium
- A investigação mostrou que o Kobo usa o RMSDK, mecanismo proprietário de renderização de e-books da Adobe
A causa foi reduzida ao RMSDK e ao Adobe Digital Editions
- O RMSDK é o mecanismo central do Adobe Digital Editions e também é usado em vários dispositivos Kobo e em aparelhos antigos da Sony e da Nook
- Esse mecanismo foi criado por volta de 2010 com foco no EPUB2 e depois recebeu uma atualização leve para EPUB3, sem realmente ser modernizado
- Saber que o Kobo usa RMSDK não resolveu de imediato a divergência entre o
epubcheck e o resultado no Kobo, mas deu uma direção para o debugging
- Ao colocar o livro no Adobe Digital Editions, como esperado, o carregamento falhou, e nenhuma mensagem de erro foi exibida
- Ao tentar importar de novo, apareceu uma mensagem dizendo que o livro já havia sido adicionado, mas a tela permanecia em branco
- Depois disso, foram criadas várias versões modificadas do arquivo para teste, e todas continuavam passando no
epubcheck
- Foram testados: reorganização da estrutura de pastas, remoção de metadados, remoção de atributos de idioma, geração de novo UUID, achatamento de diretórios, mudança de extensão, recriação do ZIP e alteração do
manifest
- Mesmo com todas essas tentativas, a falha de carregamento no Adobe Digital Editions continuou
A causa real: uma linha válida de CSS
- Ao desativar a folha de estilos, o livro de repente passou a carregar, o que restringiu o problema à stylesheet
- Depois de criar mais várias versões aplicando apenas partes da folha de estilos, foi identificada a linha exata que causava o problema
.copyright img {
max-width: min(150px, 30vw);
}
- Esse código é um código totalmente válido de CSS level 4, mas o RMSDK não consegue suportá-lo
- Ao trocar o código por uma forma mais antiga,
max-width: 150px;, o livro passou a abrir normalmente no Adobe Digital Editions
- O parser CSS do RMSDK está parado aproximadamente no estado de 2013 e não suporta flexbox, grid, funções matemáticas nem propriedades personalizadas
- Ao encontrar um CSS que não reconhece, ele falha silenciosamente em vez de usar fallback ou exibir um erro claro
- O
epubcheck faz uma verificação básica de CSS, mas não tem como validar CSS contra renderizadores específicos que são fundamentalmente quebrados
A lição sobre validar compatibilidade com Kobo
- Mesmo em 2026, o Kobo ainda usa o RMSDK como base da renderização dos livros, o que faz com que uma única linha válida de CSS possa transformar um EPUB válido inteiro em “corrupted file”
- Nesse caso, o Kobo não consegue abrir o livro inteiro, sem mensagem de erro clara nem fallback
- Para evitar o problema, foi distribuída uma nova versão, e foram tomadas medidas para que os leitores não passem pelo mesmo erro novamente
- Num cenário ideal, o RMSDK deixaria para trás esse estado antiquado do CSS ou ao menos ofereceria tratamento de erros, mas por enquanto o problema continua
- Para garantir compatibilidade com Kobo, só o
epubcheck não basta; é preciso verificar se o arquivo realmente carrega no Adobe Digital Editions
- O EPUB é um excelente padrão aberto para e-books, mas muitas implementações revelam falhas fundamentais dentro de uma estrutura que prioriza restrições de acesso
1 comentários
Comentários do Hacker News
A Adobe sempre foi assim. Jogou fora a enorme participação de mercado do Flash, quando a alternativa era só gastar alguns milhões de dólares em QA, e no fim fez todos os fabricantes de navegadores concordarem que “é melhor a web seguir sem um parceiro tão pouco confiável”
Lancei algumas coisas em Flash antigamente, mas era um software horrível, cheio de travamentos aleatórios e de heisenbugs em que mudar uma área quebrava funções não relacionadas em outros módulos. Custava uns 800 dólares, mas o suporte era praticamente inexistente; reportei vários bugs facilmente reproduzíveis, inclusive com casos de teste reduzidos, e só recebi respostas automáticas dizendo “talvez tenha sido corrigido”, então eu deveria comprar uma licença pelo preço cheio para conferir depois do próximo lançamento
Também existia o MusicWorks, e os dois eram exclusivos de Mac lá no comecinho. Só de contar isso já estou entregando a idade
A estrutura em camadas dos sistemas de build em JavaScript e os “padrões web” são muito mais difíceis do que simplesmente desenhar alguma coisa, escrever algumas funções simples e gerar um arquivo estático que pode ser embutido em qualquer lugar ou baixado. Se você usa alternativas ao Flash, gasta tempo demais com configuração, e esses “padrões” também são piores
Não gosto nem de Steve Jobs por matar o Flash, nem da Adobe por administrar tão mal uma das tecnologias mais incríveis da web. As crianças de hoje não sabem o quão mágico o Flash era. Era como um Roblox ou Minecraft da web
Os sites até hoje são piores do que o Flash do começo dos anos 2000. Décadas se passaram e ainda só imitam uma parte do poder dele, sem chegar nem perto da facilidade
Passei bastante tempo tentando fazer um software leitor de e-books e, no fim, tentei subir em cima do RMSDK, meio que fazendo um pacto com o diabo
Só que não existe nenhuma forma de conseguir acesso. Não é só que o licenciamento seja caro demais para um desenvolvedor independente, embora isso também seja verdade; simplesmente não há com quem falar. O e-mail no site não responde absolutamente nada, nem sequer um “obrigado pelo interesse” ou “entraremos em contato novamente”
Perguntei a um ex-colega que tinha trabalhado lá sobre o processo para obter acesso ao RMSDK, e ele disse que procurou documentos internos mas não encontrou nada. A mesma coisa aconteceu quando procurei no LinkedIn pessoas que pareciam ter relação com o RMSDK e fui perguntar
Enquanto isso, as editoras distribuem a maioria dos livros apenas por meio de um dos fornecedores de DRM conhecidos, como Apple, Amazon ou Adobe, e os dois primeiros são completamente fechados. Se isso não é uma prática monopolista anticompetitiva, não sei o que é
Pelo que sei, dispositivos Kobo usam um motor de renderização mais avançado quando o nome do arquivo é
.kepub.epub. Parece ser baseado em ePub 3, embora eu não saiba se isso corrigiria o problema aquiPessoalmente, antes de mandar para o Kobo, eu converto meus ePubs com o kepubify(https://pgaskin.net/kepubify/try/)
https://standardebooks.org/help/how-to-use-our-ebooks#kobo-f...
Gosto muito do Kobo Clara Colour, e acho que seria perfeito se desse para remover só o leitor da Adobe. Também experimentei o KOReader, mas gosto dos livros de biblioteca via OverDrive e da Kobo Store, então não troquei completamente
Infelizmente, epub e o epubcheck não são um padrão excelente e sem controvérsias, como o autor diz. Quando a W3C, Inc. assumiu a manutenção da especificação por volta do ePub 3.1, ela passou a referenciar diretamente o HTML do WHATWG e as especificações de navegador cada vez maiores([1])
Esses “padrões vivos” não têm versionamento nem QA. Como resultado, por se basear numa versão de HTML que redefiniu cabeçalhos e seccionamento, o ePub 3.2 acabou tornando ePubs antigos não conformes. É por isso que o Calibre e outras ferramentas ainda recomendam 3.1, ou melhor ainda, 2
O caso da rejeição da função CSS
min()também mostra como importar especificações de CSS excessivamente complexas por inteiro não ajuda muito. Leitores de e-book não são navegadores que ficam sempre atualizados[1]: https://news.ycombinator.com/item?id=41326179
Em problemas de compatibilidade com EPUB, CSS deve ser sempre o primeiro suspeito. Usar recursos de CSS “modernos” e reclamar da falta de flexbox ou grid é coisa de mentalidade de desenvolvedor web
Só porque o EPUB compartilha parte da stack com a web não significa que os dois se sobreponham totalmente, nem que precisem fazê-lo. A maioria dos leitores embarcados em dispositivos com tela e-ink não usa um navegador para renderização; eles gravam no firmware uma toolchain de parsing/renderização de HTML/CSS específica para o propósito e a atualizam só muito raramente. Se tiver curiosidade, vale olhar o crengine do KOReader ou o Crosspoint reader rodando em ESP32
O post do blog em questão tem um cheiro forte demais de prosa de IA excessivamente confiante, mas não se deixe enganar
Para quem estiver procurando um dispositivo, também existe o PineNote
https://pine64.org/devices/pinenote/
É mais caro e tem menos software pronto para uso imediato, mas é muito mais direto em relação à propriedade do dispositivo e ao que você pode executar nele, com bem menos restrições
Também há textos bem organizados sobre a experiência de uso do PineNote
https://shom.dev/posts/20250308_pinenote-day-one/
https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...
A Kobo também não limita o que você pode fazer. Dá para fazer sideload de leitores de e-book alternativos, como o KOReader, e melhorar os recursos do leitor embutido
A Kobo está realmente reescrevendo completamente o software do leitor de e-books, e na UE já dá para baixar a versão beta. Quase certamente ele não é mais baseado em RMSDK
A Adobe foi ruim como administradora e, depois, ao vender isso para um terceiro que também atrapalhou a migração e irritou ainda mais usuários finais e plataformas, praticamente entregou o mercado de DRM para EPUB de bandeja ao LCP. As plataformas estão se afastando da Adobe mais rápido do que nunca
Ao ler o trecho “eu tinha medo do momento de apertar o botão de validação em um livro que levei meses para terminar, porque ele sempre encontrava alguma coisa para implicar”, lembrei de um mestrando quase chorando ao tentar compilar um rascunho de artigo em LaTeX
Ele levou ao pé da letra demais o conselho “escreva primeiro e pense na formatação depois”, então só estava tentando compilar pela primeira vez quando o prazo já estava em cima
Embora eu não saiba que efeito o prazo iminente teve nessa percepção ;-P
Já é sorte se o leitor estiver usando um leitor de ePub que suporte algo como
max-width, ou pelo menos ignore isso :-PPessoalmente, usando leitores de ePub, às vezes precisei corrigir manualmente arquivos que não funcionavam ou eram exibidos de forma estranha por causa de estilos desnecessários. Também já ouvi dizer que arquivos que não davam problema nenhum para mim eram ilegíveis para outras pessoas, e isso me faz pensar que, a menos que haja uma formatação elaborada realmente necessária, é melhor ficar no HTML mais básico possível, algo que até o IE4 não renderizaria de forma muito errada
Por isso às vezes penso em criar uma ferramenta de reconstrução de epub que refaça um ePub usando o HTML/CSS mais simples possível. Idealmente, isso deveria ser configurável para máxima compatibilidade
Muitas vezes pensei que seria bom definir um subconjunto que funcionasse rápido em qualquer computador e usar só isso nas páginas que eu crio. Se alguém delimitasse algo assim também para ePub, isso seria muito mais útil
Adobe Digital Editions e o RMSDK foram vendidos recentemente para a Wipro Engineering: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...
Entendo a frustração do autor, mas quantos leitores ainda usam leitores de ePub antigos, sem atualização ou impossíveis de atualizar? Se o autor quer que sua obra chegue a todos os leitores, precisa mirar no mínimo denominador comum
Se isso for alguma coisa de 2013, é uma pena, mas essa é a realidade do mercado