Apontamento sobre as versão v0.99.3

[farribeiro]

Quero congratular o Tio @Patola pela elaboração do livro!

Entretanto gostaria fazer alguns apontamentos, em especial a versão para o kindle MOBI/AZW3, apresentou erros de exibição dos conteúdos. Ao fazer abertura no Kindle Preview(v2) apresentou falhas na exibição no simulador. Atualizado para o Preview(v3) não abriu simulação para kindle e-ink do arquivo MOBI e não suporte de recursos atuais. Não recomendo o calibre para esta finalidade, prefira gerar a partir do arquivo EPUB no Preview.

Os leitores de EPUB, eu tenho uma versão em software da Sony que veio com o sistema (fora num passado considerado uns dos melhores eReaders para PC), nem chegou a abrir e não tenho o instalado o ADE e futuramente tentarei abrir no Lev que tenho aqui. O Kindle Preview(v2) apontou inúmeras inconsistências, acredito que o software está montando seu EPUB errado, sugiro passar o epubchecker para tentar detectar os problemas.

Atualmente o tamanho dos seus arquivos intimidam, para a maioria dos livros digitais que não passam de 3MBytes! Talvez sejam por fazerem ilustrações a mão livre e acredito que fica melhor ilustrado assim, pode-se otimizar as figuras.

A diagramação, letras, disposições de texto e tabela está visualmente esplêndido porém acredito que está semanticamente pobre, tanto para leitura humana e até para SEO

Vou mandar a notícia para o portal. Assim seu comentário vai ficar mais claro para o povo. Não entendi direito o que quis dizer com semanticamente pobre, pode dar exemplos? Agora que a versão "de produção" está online, vou criar um branch devel e começar a aceitar contribuições do asciidoc.
Quais os erros nos formatos? Pode abrir um bug report no github com esses seus comentários? Prometo não fechar enquanto não os resolver.

Semanticamente pobre, refiro ao excesso de tags aninhadas, como tableless, destesta o excesso delas. Fora o uso errado destas tags, lembrando que além de visual tem valor contextual, procura por web semântica.

Enquanto o arquivo for gerado, em atenção ao EPUB eis a fonte, inconsistente para as demais saídas apresentam erros, então passar o validador epubckecker retirando uma a uma do seu arquivo.

https://github.com/IDPF/epubcheck

Enquanto as ilustrações recomendo fortemente troca-lás por desenhos a mão livre, eu gosto dos desenhos estilos bico de pena

[farribeiro]

Tudo bem, mas não adianta muito reclamar de o epub produzido pelo calibre ser “ruim” se não há alternativa, e certamente o uso de programas não-livres para construí-lo não é alternativa viável para um projeto desses.

Não que ele seja ruim, dá para fazer um EPUB de qualidade com calibre, mas de forma semi-braçal, utilizando o seu próprio editor de códigos do calibre.

Afinal, como eu coloquei na página de downloads, o asciidoctor-epub3 tem dois bugs que impedem que o epub seja renderizado corretamente —e nem procurei ainda renderizadores de docbook pra mobi e azw3.

A minha recomendação é utilizar conversores oficiais para a finalidade.

Lembrando ainda que passar o epubcheck é passar um verificador em algo derivado, pois o fonte é asciidoctor, não sei se ajuda muito. Mais útil seriam receitas para o asciidoc gerar um epub menos defeituoso.

A intenção é ter um arquivo valido.

Por exemplo, você falou em tableless, mas como colocaria as categorias tabuladas de impressoras por eixos no capítulo de tecnologia FFF? Tem jeito melhor que as tabelas de colocar isso?

Sou todo ouvidos, e se seu PR for melhor e mais portável que as tabelas tenha certeza que vou aceitá-lo.

Para falar verdade, fica uma m**** tabelas em qualquer formato ebook que não seja PDF

Para seu caso, acharia melhor que o asciidoctor devolvesse o HTML, semelhante ao markdown, só em parágrafos, enfatizados, enfatizado forte, tags code, anotações e tabelas, nada da estrutura HTML e CSS você abre no calibre e cola o conteúdo. O que poderia fazer a parte, customizando, eliminando redundâncias otimizando a estética igualmente como faz um site, ao estilo tableless, conteúdo no HTML e estética no CSS

Onde você viu muitas tags aninhadas no documento? Pode dar algum exemplo?

Eu não vi o documento inteiro, uma previa que mostrei num issue, cada paragrafo tinha a sua div. Nem imagino o resto do documento

E imagens —são mais de 400. Quais ilustrações acha que deviam ser trocadas? Não vale dizer todas, né? Ainda mais que muitas são fotos.

Ao menos otimizadas.

Atualização: o uso do epubcheck não adiantou muito… Olha só a saída dele: https://imgur.com/a/u9Hf8

O epubcheck é um validador, ele somente faz apontamentos onde deve corrigir no seu arquivo para ser um EPUB valido. Que não é pouca coisas

[farribeiro]

A minha recomendação é utilizar conversores oficiais para a finalidade.

O asciidoctor-epub3 é o renderizador oficial do projeto asciidoctor. O asciidoctor não tem conversores -- tem renderizadores, inclusive podendo aplicar folhas de estilo.

Acredito eu é apenas uma ponte para seu trabalho final, (HTML, EPUB, MOBI e entre outros), ficando a cargo das ferramentas como calibre e afins o seu acabamento.

Eu não vi o documento inteiro, uma previa que mostrei num issue, cada paragrafo tinha a sua div. Nem imagino o resto do documento

Acho que nesse caso eu tinha renderizado com o backend html. No caso do html novo a partir do qual gerei o epub e outros, usei o xhtml5. Tem outro renderizador html pra ele e ainda posso renderizar pra docbook pra converter pra html. Depois vou tentar esses caminhos. Aí vai ser só mudar no makefile, se der certo.

A vontande, foi só sugestão. espero que tenha compreendido

O epubcheck é um validador, ele somente faz apontamentos onde deve corrigir no seu arquivo para ser um EPUB valido. Que não é pouca coisa

Eu entendi mas estou falando que o epub não é o fonte, é apenas uma renderização, então achar erros nele não informa muito. É como querer passar um verificador de PDF pra pegar erros de um documento word renderizado pra PDF. Não faz muito sentido.

Não é, mas... é o fonte para o MOBI/AZW3, então por isso peço renderizações válidas, mas fica a seu critério.

E imagens —são mais de 400. Quais ilustrações acha que deviam ser trocadas? Não vale dizer todas, né? Ainda mais que muitas são fotos.

Ao menos otimizadas.

Otimizadas? Como assim? São todas comprimidas como é comum em png e jpegs. Como seriam mais otimizadas? Ainda acho que seria melhor dar um exemplo. Tem umas 2 ou 3 imagens que pode dizer como ficariam melhor para ilustrar?

Melhor deixar como está, se dará muito trabalho, feito sugestão.

[Patola]

Nossa. lol. Você colocou toda a discussão do br-linux aqui. Vou deixar um ponteiro pra ela no bug report: https://br-linux.org/2017/01/conferencia-sobre-kernel-no-brasil-ultimos-dias-para-chamada-de-trabalhos.html#comment-3547835616

[farribeiro]

Acredito eu é apenas uma ponte para seu trabalho final, (HTML, EPUB, MOBI e entre outros), ficando a cargo das ferramentas como calibre e afins o seu acabamento.

Naaaa verdade, o asciidoc(tor) tem o objetivo de ser um padrão completo que não precise de retoques nas renderizações, até porque para alguns dos backends (PDF por exemplo) não faz muito sentido; o estilo e detalhes seriam feitos pelas folhas de estilo mesmo. O fato de eu no momento precisar refazer o TOC no calibre para confecção do epub até coloquei como um dos bugs a serem extirpados.

Não é, mas... é o fonte para o MOBI/AZW3, então por isso peço renderizações válidas, mas fica a seu critério.

Acho que fui eu que não fui muito claro aqui. É lógico que consistência de documentos é importante. Mas dado que todos os formatos são gerados a partir de um único código, eu me preocupo 10 vezes mais com a boa prática do asciidoc do que dos vários backends finais. Inclusive eu procurei adotar todas as boas práticas do asciidoc, inclusive dividir o documento com deslocamento de cabeçalhos e deixar o documente-mestre apenas como uma "espinha". Pode ver também que o início do fonte está repleto de metadados. Se no final o asciidoc gerar um epub ou html ou qualquer outro formato que fique com o código "feio", eu considero isso ruim também, mas considero uma tarefa para o desenvolvedor do backend renderizador resolver, não do autor da obra ou colaboradores. Um bug a ser aberto no software pra que ele renderize melhor, não algo a ser mudado no fonte asciidoc, que já é feito seguindo boas práticas.

Otimizadas? Como assim? São todas comprimidas como é comum em png e jpegs. Como seriam mais otimizadas? Ainda acho que seria melhor dar um exemplo. Tem umas 2 ou 3 imagens que pode dizer como ficariam melhor para ilustrar?

Melhor deixar como está, se dará muito trabalho, feito sugestão.

Ok, deixa eu ser um pouco mais claro, novamente. Suas sugestões são muito boas, pois são de alguém com uma visão "externa" do projeto que eu não tenho. São sugestões do tipo que eu realmente preciso, e devo até pedir desculpas do modo como respondo algumas -- esse livro é "meu bebê", tenho realmente apego emocional a ele, não nego, então sugestões que ele pode não ser lindo e maravilhoso realmente de início me causam contrariedade, e você sabe como expresso meu mau humor com palavras, né? lol. Mas isso não quer dizer que eu não as leve em conta, levo sim mesmo quando as nego, pois fico pensando se no futuro ainda posso fazer algo pelo relatado.

No caso das imagens, eu realmente não entendi o que você queria. Independentemente se forem todas ou 1% delas, eu não consegui compreender como é o que preferiria. Talvez seja uma boa sugestão e factível, mas pra saber discernir isso, eu preciso imaginar como seria com ela implementada.

[farribeiro]

E aí @Patola , aplicou todas as praticas que te expliquei? Cadastrou o ISBN?

Quero reforçar este ponto:

No caso das imagens, eu realmente não entendi o que você queria. Independentemente se forem todas ou 1% delas, eu não consegui compreender como é o que preferiria. Talvez seja uma boa sugestão e factível, mas pra saber discernir isso, eu preciso imaginar como seria com ela implementada.

Ilustrações, ao invés de fotos, eu adoro estilo bico de pena ou esboço de lápis... eu babo literalmente. É o sonho de ver meu livro ilustrado assim.

[Patola]

Ainda não cadastrei o ISBN :-/