[okfn-br] dados abertos burilados, num PDF!?...

Peter Krauss ppkrauss em gmail.com
Quarta Abril 29 12:57:44 UTC 2015


Oi Raniere, bem pertinentes e consistentes todos os comentários, vamos lá
(!)...
(respondendo no framento de corpo da mensagem)

Em 29 de abril de 2015 08:31, Raniere Silva <raniere em riseup.net> escreveu:

> > *Explicando melhor.*
> > O Banco Mundial, os órgãos do governo, e dezenas de outros não podem
> ficar
> > só na visualização instantânea. Precisam de uma "foto oficial" e deixar
> > essa foto registrada.
> > Nas faculdades (teses), nas revistas (artigos), e nos Diários Oficiais
> > (atos)... Todos precisam de uma versão PDF bem diagramada, que fica
> > oficialmente registrada.
> > ... O PDF, neste cenário, é a "a cara do resultado". Sem um bom PDF a
> > divulgação oficial dos resultados não é boa.
>
> Não precisamos de PDF.
> Infelizmente ainda estamos na transição entre papel e bytes.
>
> > Não podemos fugir da demanda por *relatórios PDF bem diagramados:*  a
> lei,
> > a tradição, e eventualmente até o bom senso, mandam que se faça assim.
> PDF
> > é ainda um "mal" necessário. EPUB ainda está longe de substituí-lo.
>
> O "problema" com o EPUB é o mesmo com vários outros padrões
> e chama-se "problema do ovo e da galinha".
> Ferramentas para visualizar e editar EPUB não melhoram
> porque ninguém usa o padrão
> e ninguém usa porque as ferramentas são ruins.
>

exato! e tem mais, os e-books poderiam fomentar "o ovo", mas a Amazon não
deixa,
   http://ebooks.stackexchange.com/q/2418/2531


>
> > Quem é programador sabe que "produzir *bom* PDF" não é possível com as
> > bibliotecas que dispomos em Pythom, PHP, Java e cia.
>
> Depende de como você está trabalhando.
> A conversão de HTML para PDF via web browser muitas vezes não é
> satisfatório
> porque seu HTML está "defeituoso", e.g. utilizando tabela para o layout.
> Se você tiver um HTML enxuto a conversão é aceitável.
>

"bom PDF", "bem diagramado" é o ponto-chave e mais complicado/subjetivo!!
tomei o cuidado de citar exemplos porque é onde pega, é o mercado que
define bom e ruim,
não somos eu ou você no nosso aplicativo (e perdemos clientes quando não
ouvirmos eles)...

Consulte o mercado (!) de revistas, de livros, etc. Quantos por cento do
mercado editorial usam
alguma das ferramentas que você cita (Pandoc, LaTex, até MS-Word e cia)
para gerar produtos profissionais?
Pandoc não tem capacidade de gerar produto profissional, CSS2-page (e no
futuro CSS3) tem.

O mercado editorial do Brasil usa, em 80% ou mais dos casos, o *Adobe
InDesign* (e pirata),
e o InDesign é muito ruim para trabalhar com softwares de geração
automática de conteúdo, alem de não ser software aberto.
Softwares como InDesign não permitem por exemplo o uso em cadeia produtiva,
num esquema p.ex. de XML-Publishing.

As editoras digitais brasileiras ainda são artesanais, demandam um
diagramador humano revisando cada página de PDF profissional produzida.
Notadamente os Diários Oficiais dos 5570 municípios brasileiros são caros
(temos pago caro por isso!) por passarem por todo esse processo
artesanal... quando não precisariam.

Desde as revistas das bancas, até revistas científicas da USP, relatórios
da UNESCO e panfletos da Cocacola, é tudo InDesign... E o público desses
PDFs é refratário a "diagramação ruim" (!), não dá para "quebrar o galho"
com Pandoc.

... na minha visão, e do que conheço do mercado, essa é a realidade com a
 qual precisamos conviver ainda hoje e talvez ainda em 2016.


Peter
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150429/e1241716/attachment-0005.html>


Mais detalhes sobre a lista de discussão okfn-br