Tenho muito interesse na interseção entre e-books, segurança e a web LowJS, então este tema me parece importante
Precisamos de um formato de e-book portátil em um único arquivo, mas PDF não é a resposta, porque não permite refluxo de texto
HTML+CSS em 2024 consegue reproduzir quase qualquer mídia impressa e ainda permitir refluxo de texto
Não acho que JavaScript deva ser obrigatório. Um e-book deve ser um livro cujo tamanho possa ser alterado de forma significativa, e as funcionalidades básicas como livro devem funcionar mesmo com JavaScript desativado. Se interação ou aprimoramentos forem necessários, tudo bem usar JavaScript, mas se ele não funciona como livro sem JavaScript, eu considero isso um bug
Acho um erro colocar todos os estilos inline, porque isso pode quebrar a CSP de alguns usuários. Os estilos deveriam ser separados como recursos com caminhos relativos em relação ao HTML, e o e-book deveria proibir o carregamento de recursos de outros domínios
Por fim, basta distribuí-lo como um arquivo zip. Imagino que e-books já não funcionem assim?
A ideia de que “e-books já funcionam como zip” é correta até certo ponto. Ferramentas de unzip conseguem extrair arquivos EPUB e, se necessário, basta mudar a extensão de .epub para .zip
Mas o contrário não é necessariamente verdade. Mesmo que o mesmo conjunto de arquivos fosse um EPUB válido antes de ser extraído, se você compactá-lo de novo de qualquer jeito, ele pode deixar de ser um EPUB válido
O arquivo mimetype dentro do zip EPUB é especial: precisa ser o primeiro item do arquivo, seu conteúdo deve ser apenas application/epub+zip, e ele deve ser armazenado sem compressão
Surpreendentemente, muitas ferramentas de zip tornam isso incômodo, seja porque alteram a ordem dos arquivos ou porque dificultam salvar apenas alguns arquivos sem compressão. Programas zip de linha de comando geralmente conseguem fazer isso com flags, mas em bibliotecas zip é bem sofrido. Digo isso por experiência criando software de geração de EPUB
É importante distinguir um arquivo zip comum de um e-book. Basta usar a extensão .epub
O que foi descrito é o formato ePub, em que arquivos HTML, CSS e imagens ficam dentro de um arquivo zip
E que tal um ZIP autoextraível? Por exemplo, como esta página: https://gildas-lormeau.github.io/
Ela também inclui CSP para torná-lo seguro
Não gosto muito da abordagem de colocar tudo em um zip
Uma coisa de que eu gostava nos antigos arquivos .doc, em comparação com .docx, era poder buscar uma palavra específica muito rapidamente em uma pasta com centenas ou milhares de arquivos. Com o formato zip, isso não funciona
Acabei de salvar como .doc e abrir em um editor hexadecimal, e o conteúdo real estava lá em texto puro. Formatos zip ou arquivos PDF são difíceis de pesquisar com grep, e também fico em dúvida se compressão é realmente necessária para um texto de apenas alguns milhares de caracteres
Se a afirmação é que “HTML+CSS em 2024 consegue reproduzir quase qualquer mídia impressa”, isto também vale uma olhada: https://www.princexml.com/samples/
É um texto muito bem estruturado escrito pelo desenvolvedor do Nota, tentando elevar o formato EPUB ao mesmo nível do PDF. Ele já criou um visualizador, e o próprio texto está sendo exibido por uma porta WASM desse visualizador baseada em navegador
Um dos problemas é até que ponto o EPUB, que na prática é XHTML, consegue reproduzir layouts com precisão. O critério do texto original é que o documento pareça “convincente”, mas a nuance é que, para se equiparar ao PDF, o HTML precisaria de novos recursos de layout, pelo menos na parte de quebras de linha
Vejo dois caminhos para avançar. Um é os navegadores oferecerem mais ferramentas tipográficas; dizem que text-wrap: pretty ajuda, mas em um teste rápido não me pareceu melhorar a qualidade das quebras de linha. O outro é calcular previamente as quebras de linha, mas isso só é possível em renderização de layout fixo
O autor também menciona anotações, mas não sei bem como pretende implementá-las
O autor também aborda EPUB de layout fixo. O EPUB pode especificar paginação básica, quebras de linha, fontes, tamanho de fonte, tamanho de página, posição de imagens etc., para que tudo seja renderizado da mesma forma em todos os lugares
Isso já é possível no EPUB3, mas tem a desvantagem de não ficar bom em telas como as de celulares. Dependendo do leitor, é possível sobrescrever os padrões, mas aí você precisa esperar que o leitor reconstrua o documento de uma forma agradável
A alternativa é o EPUB especificar várias renderizações para tipos comuns de tela. Não é perfeito, mas parece um bom compromisso: o produtor do documento cria padrões, e o usuário pode sobrescrevê-los se quiser
PDF não tem recurso de quebra de linha. Ele é mais próximo de um formato de desenho, parecido com SVG, e é mais rígido, então coisas como refluxo de texto não funcionam
O que um formato de e-book precisa é de marcação semântica que se adapte ao dispositivo em que está sendo renderizada. HTML+CSS foi criado originalmente para esse propósito
Portanto, o diagramador do livro precisa conscientemente entregar ao leitor parte do controle sobre a aparência do livro. Um pouco de imperfeição visual é um preço aceitável a pagar. Se for necessária perfeição visual, use PDF
Claro que isso fica mais difícil quando entram elementos interativos. Elementos interativos grandes deveriam abrir em uma visualização dedicada quando necessário, enquanto os pequenos poderiam aceitar o refluxo
Tenho a impressão de que CSS basicamente já oferece suporte a recursos de layout para mídia paginada. Talvez bastasse o leitor EPUB implementar um modo tradicional de exibição de “visualização de impressão”
Ironicamente, o próprio exemplo de anotação dado pelo autor não funciona corretamente no meu ambiente. No Firefox para Android com tela sensível ao toque, um toque longo mostra um link em vez de um pop-up
Anotações e referências já não fazem parte da especificação EPUB, ou talvez até da especificação HTML?
Também não concordo que pressionar e segurar para abrir um pop-up seja melhor do que uma âncora de hiperlink comum. Se o recurso de “voltar” do leitor funcionar direito, ou se referências bidirecionais tiverem um link de “voltar”, a navegação é bem menos intrusiva
Antigamente existia algo chamado XSL Formatting Objects(XSL-FO). Ele mirava algo como PDF baseado em XML, mas em um nível mais alto, então também permitia refluxo de texto
A ideia era distribuir um documento XML junto com uma folha de estilo XSL, transformá-lo em FO para renderização e permitir várias folhas de estilo para o mesmo documento, conforme o dispositivo de destino ou o tamanho da página
No Firefox, uso o add-on SinglePage para salvar o DOM da página atual como um arquivo HTML independente. Ele coloca CSS e URLs data: para imagens inline e remove dependências e scripts
Não é perfeito, e não confio que os navegadores sempre vão manter compatibilidade retroativa, mas prefiro isso a salvar uma página como PDF ou como vários arquivos
Curiosamente, uma das poucas páginas em que esse add-on falhou foi justamente este texto sobre EPUB portátil. Parece que há mágica demais ali para acertar a formatação. A página salva até era legível, mas o estilo não tinha nada a ver com o original
Gosto do fato de o fbreader no Android exibir todos os livros do mesmo jeito, conforme as configurações do app, em vez de seguir o estilo do arquivo EPUB. Nunca o vi aplicar CSS ou tentar executar scripts incluídos no arquivo, e espero que continue assim. Carregar dependências externas é uma ideia ainda pior, e eu nem sabia que isso era permitido para começo de conversa
Acho que você quer dizer SingleFile
Já que tocamos no assunto, o sistema de permissões dos add-ons do Firefox é estranho. Para fazer qualquer coisa interessante, você acaba tendo que pedir praticamente todas as permissões, e o resultado é um mercado natural de agentes mal-intencionados procurando add-ons para adquirir
Por exemplo, o add-on SingleFile precisa mesmo de acesso, já que tem que inspecionar o DOM renderizado e salvá-lo em um arquivo. Mas por que ele precisa acessar tudo? Não daria para conceder só permissões como snapshot DOM once, write to a single file?
Acho que um dos meus primeiros comentários no HN, uns 10 anos atrás, foi sobre querer salvar páginas HTML da web como HTML, não como PDF
Na época eu provavelmente não sabia explicar bem o motivo, nem entendia direito, mas trataram isso como um desejo absurdo. Vendo agora, fico contente em perceber que eu só estava uns 10 anos fora de sintonia com a época
Outros comentários explicam bem por que esta página é difícil de parsear. É um texto do desenvolvedor do Nota sobre levar EPUB ao mesmo nível do PDF, e o próprio texto está sendo exibido por um visualizador baseado em WASM no navegador
O FBReader usa o CSS do documento por padrão. Se me lembro bem, dá para desativar isso em uns quatro passos
O KOReader é menos amigável, mas oferece mais controle. Você pode escolher um arquivo específico entre vários arquivos CSS fornecidos ou até escrever o seu próprio
Entre as vantagens do KOReader também estão o excelente suporte a OPDS e um servidor de sincronização auto-hospedado fácil de usar
Este texto tem um botão para baixar o EPUB
Com esse recurso, páginas que usam este sistema dispensam o SinglePage
Vi essa parte e fui olhar de novo. É o trecho: “Portanto, decidi criar o Bene, um sistema mais leve de leitura de EPUB. É isso que vocês estão usando agora. Este documento é um EPUB, e pode ser baixado pelo botão no canto superior direito”
Ao ler em um navegador de desktop, eu não tinha percebido nada disso até me avisarem diretamente. No celular, o cabeçalho ocupa mais espaço da tela e fica mais visível, mas, fora isso, ele se comporta quase como uma página web comum
Provavelmente é um bom sinal
Ao contrário do que alguns comentários disseram, não vi, ou pelo menos não percebi, um spinner ao carregar o documento pela primeira vez. No celular eu vi, mas passou bem rápido. Não sei se aquilo era o carregamento do programa WASM ou se só acontece no primeiro carregamento
O que o spinner fica esperando principalmente é o download do arquivo .epub. Como esse arquivo tem 4,77 MB, ele é bem grande sem uma conexão rápida. Depois de descompactado, a maior parte do tamanho é ocupada por imagens, algo como 99%
Diferentemente de uma página web comum ou de um PDF, parece que a renderização não começa até que todos os ativos, ou seja, o ePub inteiro, sejam baixados
Uma diferença que achei que o texto abordaria, mas não abordou, é o desempenho. PDFs podem ser otimizados para que as páginas sejam bastante independentes, permitindo renderização progressiva, acesso aleatório e alto paralelismo
No celular, não percebi nada disso até ler o texto. Achei que fosse apenas uma página web comum explicando o projeto
O simples fato de o navegador não conseguir abrir EPUB já faz o projeto parecer meio fadado ao fracasso. Quando você linka um PDF, há até uma pequena troca de contexto, mas o navegador abre e exibe
Pelo que foi descrito, EPUB é basicamente HTML, então é estranho o navegador não abrir; mas convencer os burocratas do Chrome/Mozilla não deve ser fácil
Outro ponto desanimador é que HTML e CSS ficaram tão enormes e inchados que quase ninguém consegue implementar um “leitor” para EPUB/HTML. Na prática, vira “implemente um novo navegador”. No longo prazo, parece mais promissor usar algo como Djot, um Markdown fácil de parsear, com um pouco de capacidade de renderização por cima
Minha solução provisória pessoal é colocar CSS, SVG, scripts e até imagens em base64 tudo em um único arquivo HTML. É parecido com EPUB, meio inchado e feio, mas funciona com um pouco de cuidado e o navegador consegue abrir naturalmente
Só que o usuário não tem como saber que “dá para baixar esta página web e guardá-la offline”. Seria bom existir uma extensão como .htmls para indicar que é um HTML sem recursos externos
Até pouco tempo atrás, navegadores também não conseguiam abrir PDF. Hoje todos os navegadores incluem um leitor de PDF escrito em ASM/JS
Não vejo motivo para os navegadores não fazerem o mesmo com EPUB. Já existem extensões de navegador que fazem exatamente isso. A questão é se o formato EPUB vai ganhar popularidade
HTML era originalmente hipertexto. Alguns links, figuras/imagens, talvez tabelas
Depois, designs e layouts no estilo revista passaram a ser “necessários”, mas ainda era baseado em documentos, então era bastante aceitável
Em seguida tentaram encaixar HTML à força como plataforma de distribuição de aplicações. O layout CSS atual finalmente ficou mais próximo de um motor de layout tradicional de aplicações
Acho que os últimos 20 anos foram desperdiçados em grande parte por não haver uma forma adequada de distribuir aplicações multiplataforma. Exceto Java
Então parece que este próprio artigo é um EPUB aberto em um visualizador de EPUB em WASM
O maior obstáculo parece ser o escopo de implementação de HTML/CSS. O autor diz “princípio de geração de HTML portátil: sempre que possível, um sistema que gera EPUB portátil deve emitir HTML portátil”, mas não acho que isso vá longe o suficiente
Para esse formato funcionar de maneira reproduzível em qualquer lugar, ele precisa ser padronizado, e também precisa ser fácil implementar novos motores de renderização. Depender de webviews não parece ser o caminho adiante
A beleza do PDF é que ele é muito confiável. Um PDF de 10 anos atrás ainda renderiza hoje exatamente como antes
Para esse esforço dar certo, acho que seria preciso reduzir bastante o escopo do documento. O subconjunto permitido de XHTML deveria ser muito restrito, priorizando a capacidade de renderizar com a mesma aparência em qualquer lugar. Primeiro, layout fixo com tamanho de página fixo; depois, documentos refluidificáveis. Também seria necessário um padrão com documentos de teste abrangentes e saídas de renderização incluídas
O navegador não oferece uma UI conveniente para abrir EPUB, mas não deveria haver problema em renderizar os arquivos HTML de cada capítulo dentro dele
Sem suporte do navegador, não seria tão difícil escrever um proxy no lado do servidor que transformasse EPUB em um site navegável, com controles para trocar de capítulo e opções simples de layout
Claro que o suporte a DRM necessário para ver a maioria dos e-books comerciais por esse proxy provavelmente seria juridicamente muito problemático
Pensando bem, suporte de navegador a EPUB com DRM aprovado pelas editoras está tecnicamente a meio passo de suporte a DRM para páginas web comuns, o que é uma perspectiva bem terrível
Acho PDF um formato legado horrível, com complexidade desnecessária. Como a maior parte dos usos de PDF não tem relação com impressão, a lógica de composição tipográfica também não me convence
Na grande maioria dos casos de uso, ser fácil de ler em celular, tablet e computador é muito mais importante
Fiquei surpreso quando o autor disse que o iBooks não oferece visualização com rolagem, então conferi pessoalmente. O iBooks no macOS não permite rolar arquivos ePub, mas no iOS e no iPadOS permite. Uma decisão muito estranha da Apple https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
A especificação de PDF é irritante, mas não há absolutamente nada que a substitua
Nunca vi documentação técnica distribuída em um formato que não fosse PDF e que fosse confortável de ler e pesquisar. No celular também não
Não quero documentos cuja aparência mude de acordo com um estado transitório, como o dispositivo de leitura ou o tamanho da janela. Quero um documento com layout fixo, bem projetado pelo autor
Mesmo ao ler em uma tela ou janela pequena, se não for um documento de texto simples, quero um leitor inteligente com zoom e navegação rápidos, não mudança de layout. Nada daquele comportamento idiota de alguns leitores Android em que a rolagem vertical ou Page Up/Page Down também desloca a posição horizontal e dificulta ler colunas de texto
Só seguir a recomendação tradicional de largura máxima de colunas de texto já basta para ler confortavelmente no celular. A leitura no celular só fica ruim quando o autor cria colunas largas demais e quebra regras tradicionais de tipografia
O motivo para querer documentos de layout fixo não é apenas impressão. É porque fixar o layout do documento é mais importante do que telas pequenas
Não sei sobre este caso específico, mas alguns leitores podem fazer isso por consistência com dispositivos de papel eletrônico. Em papel eletrônico, a rolagem é limitada pelo hardware por causa da baixa taxa de atualização, processadores fracos e economia de bateria
Por isso, acho uma má ideia tentar criar um único padrão que sirva para tudo. Seria melhor ter dois padrões de documentos digitais: um formato com multimídia e interatividade completas, exceto rede; e outro como subconjunto dele, em preto e branco, sem multimídia, com interatividade limitada principalmente a hiperlinks dentro do documento
E praticamente esses dois formatos já existem: HTML, MHTML=EML e EPUB
Claro, também é necessário um terceiro formato para arquivamento físico e para os raros documentos digitais de layout fixo, e o PDF/A já parece cumprir esse papel bem o bastante
Se você realmente precisa imprimir algo, PDF é o caminho mais confiável e portátil
Talvez SVG multipágina também fosse possível, mas para imprimir várias páginas corretamente parece que no fim seria preciso exportar primeiro para PDF. Estou dizendo isso olhando para o Inkscape
Fico curioso sobre o que um leitor de EPUB oferece que um navegador não tem. Do jeito que vejo agora, há exatamente uma resposta, e ela é trivial: arquivos .epub, ou seja, tratar arquivos zip como diretórios
Se a diferença entre um leitor de EPUB e um subconjunto de navegador for realmente só isso, a abordagem mais simples e que exige menos esforço seria esta:
Fazer navegadores existentes tratarem arquivos zip como diretórios sob certas condições
Definir uma restrição de HTML verificável mecanicamente que garanta ativos totalmente locais, como o texto original menciona. Talvez baste exigir que todas as URLs, exceto links, sejam caminhos relativos
Declarar arquivos zip que satisfaçam essa restrição como “EPUBs portáteis”
Esquecer todos os leitores de EPUB dedicados, existentes ou novos
Concordo. Isso soa como a solução de verdade
Sobre ativos totalmente locais, eu gostaria de ver a exigência de que todo objeto tenha uma opção de fallback disponível localmente. Algo como usar uma fonte padrão se não for possível obter aquela fonte. Pode não ficar perfeito, mas, se limitado ao escopo do fallback, deveria funcionar de forma razoável
Há um modo de falha que ainda não foi tratado o suficiente: imagens que não funcionam bem. Fundamentalmente, imagens não refluem. Em grande parte isso poderia ser resolvido usando SVG, mas não no caso de imagens raster reais. No fim, acho que a única saída é oferecer algumas resoluções
Também já enfrentei um problema relacionado e ainda não vi uma boa resposta: um SVG que tenha consciência da resolução e, quando houver resolução suficiente, busque uma imagem mais detalhada. Desenhar linhas subpixel as deixa borradas, mas, se a mesma imagem for ampliada, essas linhas se tornam úteis. Ícones do Windows reconhecem isso ao poder incluir várias resoluções e usar a adequada para a situação
O autor é pesquisador de pós-doutorado orientado por Shriram Krishnamurthi. Shriram Krishnamurthi é autor de Programming Languages: Application and Interpretation(PLAI) e um dos autores de Data-Centric Introduction to Computing(DCIC)
Estou lendo tanto PLAI quanto DCIC agora, e fico realmente impressionado com o cuidado minucioso que os autores dedicaram para transformá-los em obras de arte educacionais. Isso é amor de verdade https://willcrichton.net/
PDFs podem incluir fontes, mas frequentemente não incluem e dependem das fontes do sistema. Um dos motivos é que colocar fontes no PDF pode aumentar bastante o tamanho do arquivo. Em alguns casos, uma única fonte pode ser maior que todo o restante do arquivo
Já implementei incorporação de fontes em software que gera PDF, e foi surpreendentemente difícil descobrir como fazer isso funcionar de forma confiável
A ideia de que PDFs são renderizados de forma consistente também não é tão verdadeira quanto parece. Já vi várias vezes o mesmo PDF ser renderizado de modo diferente dependendo do visualizador de PDF usado. Normalmente as diferenças são sutis, mas às vezes há casos de borda com diferenças bem grandes. Também já vi a mesma versão do Acrobat Reader renderizar PDFs de modo diferente dependendo do sistema operacional
Há apenas algumas fontes padrão do sistema que podem ser omitidas de um arquivo PDF, e o documento presume que a fonte usada na renderização tenha as mesmas métricas de tipos tradicionais como Times, Helvetica e Courier
Portanto, se for usada uma fonte de sistema compatível, o layout do documento renderizado não deveria mudar. Claro, há casos de fontes de sistema que se anunciam como compatíveis em métricas com as antigas fontes Adobe PostScript, mas ainda têm diferenças sutis
Exceto por esse pequeno conjunto de fontes padrão do sistema, documentos PDF normalmente incluem apenas um subconjunto de glifos correspondente aos caracteres realmente usados no texto, não a fonte inteira
Depois de mais de 20 anos achando que PDFs eram renderizados de forma consistente, só descobri que fontes podiam estar ausentes quando, em uma entrevista, me disseram que meu documento estava aparecendo estranho
Foi um The Daily WTF da vida real
Fico me perguntando se existe software que minimize fontes removendo os pontos de código que não são usados no documento
1 comentários
Opiniões no Hacker News
Tenho muito interesse na interseção entre e-books, segurança e a web LowJS, então este tema me parece importante
Precisamos de um formato de e-book portátil em um único arquivo, mas PDF não é a resposta, porque não permite refluxo de texto
HTML+CSS em 2024 consegue reproduzir quase qualquer mídia impressa e ainda permitir refluxo de texto
Não acho que JavaScript deva ser obrigatório. Um e-book deve ser um livro cujo tamanho possa ser alterado de forma significativa, e as funcionalidades básicas como livro devem funcionar mesmo com JavaScript desativado. Se interação ou aprimoramentos forem necessários, tudo bem usar JavaScript, mas se ele não funciona como livro sem JavaScript, eu considero isso um bug
Acho um erro colocar todos os estilos inline, porque isso pode quebrar a CSP de alguns usuários. Os estilos deveriam ser separados como recursos com caminhos relativos em relação ao HTML, e o e-book deveria proibir o carregamento de recursos de outros domínios
Por fim, basta distribuí-lo como um arquivo zip. Imagino que e-books já não funcionem assim?
Mas o contrário não é necessariamente verdade. Mesmo que o mesmo conjunto de arquivos fosse um EPUB válido antes de ser extraído, se você compactá-lo de novo de qualquer jeito, ele pode deixar de ser um EPUB válido
O arquivo mimetype dentro do zip EPUB é especial: precisa ser o primeiro item do arquivo, seu conteúdo deve ser apenas
application/epub+zip, e ele deve ser armazenado sem compressãoSurpreendentemente, muitas ferramentas de zip tornam isso incômodo, seja porque alteram a ordem dos arquivos ou porque dificultam salvar apenas alguns arquivos sem compressão. Programas zip de linha de comando geralmente conseguem fazer isso com flags, mas em bibliotecas zip é bem sofrido. Digo isso por experiência criando software de geração de EPUB
O que foi descrito é o formato ePub, em que arquivos HTML, CSS e imagens ficam dentro de um arquivo zip
Ela também inclui CSP para torná-lo seguro
Uma coisa de que eu gostava nos antigos arquivos .doc, em comparação com .docx, era poder buscar uma palavra específica muito rapidamente em uma pasta com centenas ou milhares de arquivos. Com o formato zip, isso não funciona
Acabei de salvar como .doc e abrir em um editor hexadecimal, e o conteúdo real estava lá em texto puro. Formatos zip ou arquivos PDF são difíceis de pesquisar com grep, e também fico em dúvida se compressão é realmente necessária para um texto de apenas alguns milhares de caracteres
É um texto muito bem estruturado escrito pelo desenvolvedor do Nota, tentando elevar o formato EPUB ao mesmo nível do PDF. Ele já criou um visualizador, e o próprio texto está sendo exibido por uma porta WASM desse visualizador baseada em navegador
Um dos problemas é até que ponto o EPUB, que na prática é XHTML, consegue reproduzir layouts com precisão. O critério do texto original é que o documento pareça “convincente”, mas a nuance é que, para se equiparar ao PDF, o HTML precisaria de novos recursos de layout, pelo menos na parte de quebras de linha
Vejo dois caminhos para avançar. Um é os navegadores oferecerem mais ferramentas tipográficas; dizem que
text-wrap: prettyajuda, mas em um teste rápido não me pareceu melhorar a qualidade das quebras de linha. O outro é calcular previamente as quebras de linha, mas isso só é possível em renderização de layout fixoO autor também menciona anotações, mas não sei bem como pretende implementá-las
Isso já é possível no EPUB3, mas tem a desvantagem de não ficar bom em telas como as de celulares. Dependendo do leitor, é possível sobrescrever os padrões, mas aí você precisa esperar que o leitor reconstrua o documento de uma forma agradável
A alternativa é o EPUB especificar várias renderizações para tipos comuns de tela. Não é perfeito, mas parece um bom compromisso: o produtor do documento cria padrões, e o usuário pode sobrescrevê-los se quiser
O que um formato de e-book precisa é de marcação semântica que se adapte ao dispositivo em que está sendo renderizada. HTML+CSS foi criado originalmente para esse propósito
Portanto, o diagramador do livro precisa conscientemente entregar ao leitor parte do controle sobre a aparência do livro. Um pouco de imperfeição visual é um preço aceitável a pagar. Se for necessária perfeição visual, use PDF
Claro que isso fica mais difícil quando entram elementos interativos. Elementos interativos grandes deveriam abrir em uma visualização dedicada quando necessário, enquanto os pequenos poderiam aceitar o refluxo
Anotações e referências já não fazem parte da especificação EPUB, ou talvez até da especificação HTML?
Também não concordo que pressionar e segurar para abrir um pop-up seja melhor do que uma âncora de hiperlink comum. Se o recurso de “voltar” do leitor funcionar direito, ou se referências bidirecionais tiverem um link de “voltar”, a navegação é bem menos intrusiva
A ideia era distribuir um documento XML junto com uma folha de estilo XSL, transformá-lo em FO para renderização e permitir várias folhas de estilo para o mesmo documento, conforme o dispositivo de destino ou o tamanho da página
No Firefox, uso o add-on SinglePage para salvar o DOM da página atual como um arquivo HTML independente. Ele coloca CSS e URLs
data:para imagens inline e remove dependências e scriptsNão é perfeito, e não confio que os navegadores sempre vão manter compatibilidade retroativa, mas prefiro isso a salvar uma página como PDF ou como vários arquivos
Curiosamente, uma das poucas páginas em que esse add-on falhou foi justamente este texto sobre EPUB portátil. Parece que há mágica demais ali para acertar a formatação. A página salva até era legível, mas o estilo não tinha nada a ver com o original
Gosto do fato de o fbreader no Android exibir todos os livros do mesmo jeito, conforme as configurações do app, em vez de seguir o estilo do arquivo EPUB. Nunca o vi aplicar CSS ou tentar executar scripts incluídos no arquivo, e espero que continue assim. Carregar dependências externas é uma ideia ainda pior, e eu nem sabia que isso era permitido para começo de conversa
Já que tocamos no assunto, o sistema de permissões dos add-ons do Firefox é estranho. Para fazer qualquer coisa interessante, você acaba tendo que pedir praticamente todas as permissões, e o resultado é um mercado natural de agentes mal-intencionados procurando add-ons para adquirir
Por exemplo, o add-on SingleFile precisa mesmo de acesso, já que tem que inspecionar o DOM renderizado e salvá-lo em um arquivo. Mas por que ele precisa acessar tudo? Não daria para conceder só permissões como
snapshot DOM once,write to a single file?Na época eu provavelmente não sabia explicar bem o motivo, nem entendia direito, mas trataram isso como um desejo absurdo. Vendo agora, fico contente em perceber que eu só estava uns 10 anos fora de sintonia com a época
O KOReader é menos amigável, mas oferece mais controle. Você pode escolher um arquivo específico entre vários arquivos CSS fornecidos ou até escrever o seu próprio
Entre as vantagens do KOReader também estão o excelente suporte a OPDS e um servidor de sincronização auto-hospedado fácil de usar
Com esse recurso, páginas que usam este sistema dispensam o SinglePage
Vi essa parte e fui olhar de novo. É o trecho: “Portanto, decidi criar o Bene, um sistema mais leve de leitura de EPUB. É isso que vocês estão usando agora. Este documento é um EPUB, e pode ser baixado pelo botão no canto superior direito”
Ao ler em um navegador de desktop, eu não tinha percebido nada disso até me avisarem diretamente. No celular, o cabeçalho ocupa mais espaço da tela e fica mais visível, mas, fora isso, ele se comporta quase como uma página web comum
Provavelmente é um bom sinal
Ao contrário do que alguns comentários disseram, não vi, ou pelo menos não percebi, um spinner ao carregar o documento pela primeira vez. No celular eu vi, mas passou bem rápido. Não sei se aquilo era o carregamento do programa WASM ou se só acontece no primeiro carregamento
Diferentemente de uma página web comum ou de um PDF, parece que a renderização não começa até que todos os ativos, ou seja, o ePub inteiro, sejam baixados
Uma diferença que achei que o texto abordaria, mas não abordou, é o desempenho. PDFs podem ser otimizados para que as páginas sejam bastante independentes, permitindo renderização progressiva, acesso aleatório e alto paralelismo
O simples fato de o navegador não conseguir abrir EPUB já faz o projeto parecer meio fadado ao fracasso. Quando você linka um PDF, há até uma pequena troca de contexto, mas o navegador abre e exibe
Pelo que foi descrito, EPUB é basicamente HTML, então é estranho o navegador não abrir; mas convencer os burocratas do Chrome/Mozilla não deve ser fácil
Outro ponto desanimador é que HTML e CSS ficaram tão enormes e inchados que quase ninguém consegue implementar um “leitor” para EPUB/HTML. Na prática, vira “implemente um novo navegador”. No longo prazo, parece mais promissor usar algo como Djot, um Markdown fácil de parsear, com um pouco de capacidade de renderização por cima
Minha solução provisória pessoal é colocar CSS, SVG, scripts e até imagens em base64 tudo em um único arquivo HTML. É parecido com EPUB, meio inchado e feio, mas funciona com um pouco de cuidado e o navegador consegue abrir naturalmente
Só que o usuário não tem como saber que “dá para baixar esta página web e guardá-la offline”. Seria bom existir uma extensão como
.htmlspara indicar que é um HTML sem recursos externosNão vejo motivo para os navegadores não fazerem o mesmo com EPUB. Já existem extensões de navegador que fazem exatamente isso. A questão é se o formato EPUB vai ganhar popularidade
Depois, designs e layouts no estilo revista passaram a ser “necessários”, mas ainda era baseado em documentos, então era bastante aceitável
Em seguida tentaram encaixar HTML à força como plataforma de distribuição de aplicações. O layout CSS atual finalmente ficou mais próximo de um motor de layout tradicional de aplicações
Acho que os últimos 20 anos foram desperdiçados em grande parte por não haver uma forma adequada de distribuir aplicações multiplataforma. Exceto Java
Para esse formato funcionar de maneira reproduzível em qualquer lugar, ele precisa ser padronizado, e também precisa ser fácil implementar novos motores de renderização. Depender de webviews não parece ser o caminho adiante
A beleza do PDF é que ele é muito confiável. Um PDF de 10 anos atrás ainda renderiza hoje exatamente como antes
Para esse esforço dar certo, acho que seria preciso reduzir bastante o escopo do documento. O subconjunto permitido de XHTML deveria ser muito restrito, priorizando a capacidade de renderizar com a mesma aparência em qualquer lugar. Primeiro, layout fixo com tamanho de página fixo; depois, documentos refluidificáveis. Também seria necessário um padrão com documentos de teste abrangentes e saídas de renderização incluídas
Sem suporte do navegador, não seria tão difícil escrever um proxy no lado do servidor que transformasse EPUB em um site navegável, com controles para trocar de capítulo e opções simples de layout
Claro que o suporte a DRM necessário para ver a maioria dos e-books comerciais por esse proxy provavelmente seria juridicamente muito problemático
Pensando bem, suporte de navegador a EPUB com DRM aprovado pelas editoras está tecnicamente a meio passo de suporte a DRM para páginas web comuns, o que é uma perspectiva bem terrível
Acho PDF um formato legado horrível, com complexidade desnecessária. Como a maior parte dos usos de PDF não tem relação com impressão, a lógica de composição tipográfica também não me convence
Na grande maioria dos casos de uso, ser fácil de ler em celular, tablet e computador é muito mais importante
Fiquei surpreso quando o autor disse que o iBooks não oferece visualização com rolagem, então conferi pessoalmente. O iBooks no macOS não permite rolar arquivos ePub, mas no iOS e no iPadOS permite. Uma decisão muito estranha da Apple
https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...
Nunca vi documentação técnica distribuída em um formato que não fosse PDF e que fosse confortável de ler e pesquisar. No celular também não
Não quero documentos cuja aparência mude de acordo com um estado transitório, como o dispositivo de leitura ou o tamanho da janela. Quero um documento com layout fixo, bem projetado pelo autor
Mesmo ao ler em uma tela ou janela pequena, se não for um documento de texto simples, quero um leitor inteligente com zoom e navegação rápidos, não mudança de layout. Nada daquele comportamento idiota de alguns leitores Android em que a rolagem vertical ou Page Up/Page Down também desloca a posição horizontal e dificulta ler colunas de texto
Só seguir a recomendação tradicional de largura máxima de colunas de texto já basta para ler confortavelmente no celular. A leitura no celular só fica ruim quando o autor cria colunas largas demais e quebra regras tradicionais de tipografia
Por isso, acho uma má ideia tentar criar um único padrão que sirva para tudo. Seria melhor ter dois padrões de documentos digitais: um formato com multimídia e interatividade completas, exceto rede; e outro como subconjunto dele, em preto e branco, sem multimídia, com interatividade limitada principalmente a hiperlinks dentro do documento
E praticamente esses dois formatos já existem: HTML, MHTML=EML e EPUB
Claro, também é necessário um terceiro formato para arquivamento físico e para os raros documentos digitais de layout fixo, e o PDF/A já parece cumprir esse papel bem o bastante
Talvez SVG multipágina também fosse possível, mas para imprimir várias páginas corretamente parece que no fim seria preciso exportar primeiro para PDF. Estou dizendo isso olhando para o Inkscape
Há 8 dias, houve “Portable Web Documents – An Alternative to PDF Based on HTML5 (2019)”, que recebeu 134 pontos
https://news.ycombinator.com/item?id=39036774
https://news.ycombinator.com/item?id=39037135
Fico curioso sobre o que um leitor de EPUB oferece que um navegador não tem. Do jeito que vejo agora, há exatamente uma resposta, e ela é trivial: arquivos .epub, ou seja, tratar arquivos zip como diretórios
Se a diferença entre um leitor de EPUB e um subconjunto de navegador for realmente só isso, a abordagem mais simples e que exige menos esforço seria esta:
Fazer navegadores existentes tratarem arquivos zip como diretórios sob certas condições
Definir uma restrição de HTML verificável mecanicamente que garanta ativos totalmente locais, como o texto original menciona. Talvez baste exigir que todas as URLs, exceto links, sejam caminhos relativos
Declarar arquivos zip que satisfaçam essa restrição como “EPUBs portáteis”
Esquecer todos os leitores de EPUB dedicados, existentes ou novos
Sobre ativos totalmente locais, eu gostaria de ver a exigência de que todo objeto tenha uma opção de fallback disponível localmente. Algo como usar uma fonte padrão se não for possível obter aquela fonte. Pode não ficar perfeito, mas, se limitado ao escopo do fallback, deveria funcionar de forma razoável
Há um modo de falha que ainda não foi tratado o suficiente: imagens que não funcionam bem. Fundamentalmente, imagens não refluem. Em grande parte isso poderia ser resolvido usando SVG, mas não no caso de imagens raster reais. No fim, acho que a única saída é oferecer algumas resoluções
Também já enfrentei um problema relacionado e ainda não vi uma boa resposta: um SVG que tenha consciência da resolução e, quando houver resolução suficiente, busque uma imagem mais detalhada. Desenhar linhas subpixel as deixa borradas, mas, se a mesma imagem for ampliada, essas linhas se tornam úteis. Ícones do Windows reconhecem isso ao poder incluir várias resoluções e usar a adequada para a situação
O autor é pesquisador de pós-doutorado orientado por Shriram Krishnamurthi. Shriram Krishnamurthi é autor de Programming Languages: Application and Interpretation(PLAI) e um dos autores de Data-Centric Introduction to Computing(DCIC)
Estou lendo tanto PLAI quanto DCIC agora, e fico realmente impressionado com o cuidado minucioso que os autores dedicaram para transformá-los em obras de arte educacionais. Isso é amor de verdade
https://willcrichton.net/
https://rust-book.cs.brown.edu/
PDFs podem incluir fontes, mas frequentemente não incluem e dependem das fontes do sistema. Um dos motivos é que colocar fontes no PDF pode aumentar bastante o tamanho do arquivo. Em alguns casos, uma única fonte pode ser maior que todo o restante do arquivo
Já implementei incorporação de fontes em software que gera PDF, e foi surpreendentemente difícil descobrir como fazer isso funcionar de forma confiável
A ideia de que PDFs são renderizados de forma consistente também não é tão verdadeira quanto parece. Já vi várias vezes o mesmo PDF ser renderizado de modo diferente dependendo do visualizador de PDF usado. Normalmente as diferenças são sutis, mas às vezes há casos de borda com diferenças bem grandes. Também já vi a mesma versão do Acrobat Reader renderizar PDFs de modo diferente dependendo do sistema operacional
Portanto, se for usada uma fonte de sistema compatível, o layout do documento renderizado não deveria mudar. Claro, há casos de fontes de sistema que se anunciam como compatíveis em métricas com as antigas fontes Adobe PostScript, mas ainda têm diferenças sutis
Exceto por esse pequeno conjunto de fontes padrão do sistema, documentos PDF normalmente incluem apenas um subconjunto de glifos correspondente aos caracteres realmente usados no texto, não a fonte inteira
Foi um The Daily WTF da vida real