Pdf.js: As fórmulas são pintadas muito grandes.

Esqueci de mencionar: estou usando o PDF Viewer 0.7.1 com Firefox 18.0.1 no Ubuntu Linux.

Parece que afeta apenas o Linux

No entanto, o Windows também exibe um erro no registro:
[16: 59: 53.199] Erro ao analisar o valor de 'font-size'. Declaração descartada. @ http://arxiv.org/pdf/0707.3195v1.pdf
[16: 59: 53.569] Erro ao analisar o valor de 'fonte'. Declaração descartada. @ http://arxiv.org/pdf/0707.3195v1.pdf

@dabbeljuh , você acha que está relacionado?

@yurydelendik : Parece que não, usei o stepper e os dois avisos aparecem na primeira página (o primeiro ao definir o arXiV-nr vertical à esquerda, o segundo ao terminar a página).

@yurydelendik Acho que podemos fechar isso. Não consigo replicar o problema no desenvolvimento do Arch Linux x64, Firefox 22 e pdf.js. Também não há problemas no Windows 7 x64.

Eu apenas verifiquei duas vezes. O problema ainda persiste em minhas máquinas.
(Ubuntu Linux 12.04, Firefox 22, Pdf.js 0.8.1)

Talvez esteja corrigido no pdf.js de desenvolvimento, eu não sei.

Deixe-me saber se você quiser que eu teste alguma coisa.

Talvez esteja corrigido no pdf.js de desenvolvimento, eu não sei.
Deixe-me saber se você quiser que eu teste alguma coisa.

@kaymes Por favor, tente baixar o arquivo e abri-lo (clicando no botão abrir arquivo, localizado no lado direito da barra de ferramentas PDF.js) no visualizador da web: http://mozilla.github.io/pdf.js /web/viewer.html.
Ele sempre usa a versão mais recente do PDF.js, então tente fazer isso e veja se o arquivo é exibido corretamente.

Acabei de experimentar o visualizador online em
http://mozilla.github.io/pdf.js/web/viewer.html. Ainda fica errado
com todas as chaves tornadas muito grandes. Era mais um computador
mas também um rodando Ubuntu 12.04 com Firefox 22. Portanto, o problema pode ser
Específico do Linux (ou mesmo do Ubuntu), mas aparece em pelo menos três
máquinas diferentes.

Hmm, estranho. Nesse caso, acho que seria específico do Ubuntu, porque não há problemas aqui no Arch Linux. Aprendendo algo novo todo dia :-)

Acabei de testar se é culpa de algum addon. Eu comecei o firefox
no modo de segurança e abriu o documento usando o visualizador online. o
o problema ainda persiste. Portanto, os addons podem ser descartados.

E fiz mais um teste: baixei o Firefox diretamente do Mozilla. então
todos os patches / modificações do Ubuntu sumiram. E então eu comecei este
no modo de segurança. O problema ainda está lá.

Também vejo isso no Ubuntu 13.04

[18:42:43.639] "PDF 8d10792f8d2028a66825b6ce6ab5b3c1 [1.4 GPL Ghostscript GIT PRERELEASE 9.05 / dvips(k) 5.95a Copyright 2005 Radical Eye Software] (PDF.js: 0.8.510)

Isso ainda é um problema com a última versão de desenvolvimento do PDF.js em http://mozilla.github.io/pdf.js/web/viewer.html? Não consigo reproduzir isso no Arch Linux.

O problema ainda prevalece (Ubuntu 12.04, FF26).

No Linux Mint baseado no Ubuntu, esse bug também pode ser reproduzido no Google Chrome 34 (e no Firefox 32.0a1), portanto, não é um problema exclusivo do Firefox. O Opera 12.16 é renderizado corretamente.

Vou usar as palavras TeX, LaTeX e matemática neste comentário para que as pessoas possam encontrar esse bug.

Isso parece estar relacionado ao antialiasing: eu uso o gnome 3.14 em uma máquina Debian Jessie, Firefox 33.0.2. Tanto no anti-serrilhamento RGB quanto em tons de cinza, quando a opção de ligeira sugestão é selecionada (na ferramenta Gnome Tweak), tenho o mesmo problema. Quando eu mudo para qualquer uma das outras opções de sugestão (Completa, Média ou Nenhuma), parece como deveria ser.

Observe que, no Firefox, você deve pelo menos atualizar a guia para ver a mudança.

Para mim (Arch Linux), esse bug aparece se eu usar um fontconfig / freetype com patch de infinalidade . Usar os pacotes vanilla não mostra esse bug.

Não sei se está relacionado aos patches ou à configuração enviada com os pacotes com patch.

Pode reproduzir no Ubuntu 14.04 no Chromium e Firefox. Observe como os artefatos mudam ao dimensionar o documento. Já vi esse bug em dezenas de documentos pdfTeX em pdf.js, por exemplo, índices de soma também são afetados.

Isso realmente parece ser um problema inicial, embora eu não tenha certeza de onde arquivá-lo.

Eu reconstruí o Ubuntu 14.04 freetype / fontconfig sem a maioria dos patches específicos da distribuição, mas o problema persiste.

Também instalei o freetype / fontconfig mais recente do Ubuntu 15.10, mas o problema persiste.

Talvez isso precise ser arquivado como um bug do Firefox (Linux) upstream? Só não tenho certeza se é causado pelo Firefox ou por uma biblioteca de fontes Linux específica.

Aqui está um caso de teste mínimo:

\documentclass{article}
\begin{document}
$$ \sqrt{\frac{1}{2}} $$
\end{document}

Isso é renderizado de maneira diferente no Ubuntu e no Windows:

<style type="text/css">
* { margin:0; padding: 0 }
@font-face { font-family:"g_font_1";src:url(data:font/opentype;base64,T1RUTwAJAIAAAwAQQ0ZGIEG/4oQAAACcAAACWU9TLzJL4jE4AAAC+AAAAGBjbWFwAA0ApQAAA1gAAAAsaGVhZKsnRLAAAAOEAAAANmhoZWEDBvRyAAADvAAAACRobXR4BdwAAAAAA+AAAAAMbWF4cAADUAAAAAPsAAAABm5hbWUiztZPAAAD9AAAAgRwb3N0AAMAAAAABfgAAAAgAQAEBAABAQEOTU5QRUhJK0NNRVgxMAABAQFF+BsA+BwB+B0C+B4D+B8EHgoAH4uLHgoAH4uLDAdzHPRwHAWu+ZgFHQAAAKoPHQAAAAAQHQAAAK8RHQAAABwdAAABYhIABQEBDSAtOkBWZXJzaW9uIDAuMTFTZWUgb3JpZ2luYWwgbm90aWNlTU5QRUhJK0NNRVgxME1OUEVISStDTUVYMTBNZWRpdW0AAAAAAAAAAAADAQEDC62LDhwB9BwAABYOHAPoHABvFhwBYxz3jhUc//8GHP8oHAPqBRz/fRz/MgUc//kc//ccAAAc//4cAAAc//8IHAAAHP/8HAANHP/1HAABHP//CBwARBwAawUcAOcc+88FHAAhHAAAHAADHAAAHAAGHAAaCBwCJhwJHQUcAAIcAAccAAIcAAkcAAAcAAUIHAALHP/4HAAJHP/0Hhz/8BwAABz//Rz/8xz//Rz/8ggOHgoEeW8MCboKuguzkgwMs5IMDYsMDh0AAAAcEwBrAQECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4vMDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5fYGFiY2RlZmdoaWprbAsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLCwsLAAAAAAADAiQB9AAFAAACigK7AAAAjAKKArsAAAHfADEBAgAAAAAGAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAqMjEqAAAAcgByAwT0cABkAwQLkAAAAAAAAAAAAa8AAAAAAHIAAwAAAAEAAwABAAAADAAEACAAAAAEAAQAAQAAAHL//wAAAHL///+QAAEAAAAAAAEAAAAAEAAAAAAAXw889QAAA+gAAAAAngt+JwAAAACeC34nAAD0cA//AwQAAAARAAAAAAAAAAAAAQAAAwT0cAAA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAfQAAAPoAAAAAFAAAAMAAAAAABQA9gABAAAAAAAAABAAAAABAAAAAAABAA0AEAABAAAAAAACAAcAHQABAAAAAAADAAgAJAABAAAAAAAEAA0ALAABAAAAAAAFAAwAOQABAAAAAAAGAAAARQABAAAAAAAHAAcARQABAAAAAAAIAAcATAABAAAAAAAJAAcAUwADAAEECQAAACAAWgADAAEECQABABoAegADAAEECQACAA4AlAADAAEECQADABAAogADAAEECQAEABoAsgADAAEECQAFABgAzAADAAEECQAGAAAA5AADAAEECQAHAA4A5AADAAEECQAIAA4A8gADAAEECQAJAA4BAE9yaWdpbmFsIGxpY2VuY2VNTlBFSEkrQ01FWDEwVW5rbm93bnVuaXF1ZUlETU5QRUhJK0NNRVgxMFZlcnNpb24gMC4xMVVua25vd25Vbmtub3duVW5rbm93bgBPAHIAaQBnAGkAbgBhAGwAIABsAGkAYwBlAG4AYwBlAE0ATgBQAEUASABJACsAQwBNAEUAWAAxADAAVQBuAGsAbgBvAHcAbgB1AG4AaQBxAHUAZQBJAEQATQBOAFAARQBIAEkAKwBDAE0ARQBYADEAMABWAGUAcgBzAGkAbwBuACAAMAAuADEAMQBVAG4AawBuAG8AdwBuAFUAbgBrAG4AbwB3AG4AVQBuAGsAbgBvAHcAbgADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA);}
td { border: 1px solid #ccc; width: 9px; height: 10px; }
</style>
<table cellspacing="0" cellpadding="0" style="border-collapse:collapse;empty-cells:show">
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
<tr><td></td><td></td></tr>
</table>
<div style='font:16px "g_font_1";position:absolute;top:0;left:0'>r</div>

https://bugzilla.mozilla.org/show_bug.cgi?id=1200077

Não se esqueça de que o Chrome também é afetado, então provavelmente não é um bug do Firefox.
Captura de tela: Chrome 44 em (baseado no Ubuntu) Linux Mint.

https://bugs.freedesktop.org/show_bug.cgi?id=91829

@jethrogb Obrigado por

Parece que o pessoal do freedesktop concluiu que isso ainda é em parte um bug do pdfjs. Portanto, provavelmente ainda há algum trabalho a fazer aqui.

Além disso, enquanto isso, há alguma solução alternativa fácil além de aumentar o zoom até que o bug desapareça? Eu uso o sharelatex com freqüência, que parece ter um visualizador de pdfjs embutido.

É uma falha do pdf.js. Resumindo, o pdf.js cria fontes inválidas para esses símbolos matemáticos. Posteriormente, o hinter automático da fonte chega a conclusões erradas que acionam a exibição errada.

Portanto, o pdf.js deve corrigir a maneira como as fontes do pdf são convertidas.

Eu tive esse problema com a extensão atom pdf view , apenas como prova adicional de que não é um problema do Firefox. Capturas de tela de como ele se parece no atom , em PDF.js e como deveria ser .

Posso confirmar que esse problema existe no Chrome no Ubuntu 15.10.

Este bug agora deve ser corrigido com uma biblioteca Freetype atualizada instalada (> = 2.6.2)

Não, o verdadeiro bug está na conversão de Tipo 1 para OpenType de pdf.js que cria glifos de fonte inválidos, e AFAIK isso ainda não foi corrigido.

Oh, eu interpretei mal o bug do upstream. Desculpe pela má informação.
A propósito, não detectei esse bug em minhas duas máquinas Debian (Jessie e Stretch).

o mesmo aqui: sem problemas!
Arch Linux x86_64 e fontes corrigidas com infinalidade [*], firefox 45.0.2
(o mesmo acontece com o cromo 50.0.2661.75-1)

[*] cairo-infinalidade-final 1.14.6-1
fontconfig-infinality-ultimate 2.11.95-4
freetype2-infinality-ultimate 2.6.3-2

Peço desculpas se isso for inapropriado, mas vou oferecer uma recompensa de $ 500 por esse bug ser corrigido.

No ShareLaTeX, usamos PDF.js para renderizar o PDF produzido a partir de documentos LaTeX dos usuários e, portanto, nossos usuários provavelmente encontram esse bug com mais frequência do que o usuário médio.

Não consegui encontrar nenhum precedente ou comentário sobre oferecer uma recompensa por bugs para este projeto, então espero que esteja tudo bem. Sinta-se à vontade para entrar em contato comigo em [email protected]. Se você preferir, podemos configurar a recompensa em garantia com algo como https://www.bountysource.com/ , ou se alguém quiser adicionar à recompensa.

BTW: isso foi corrigido upstream no freetype https://bugs.freedesktop.org/show_bug.cgi?id=91829

Isso não tem nada a ver com o FreeType, como as pessoas vivem dizendo e como é amplamente discutido no problema do FreeType que você vinculou, há um bug no conversor Type1 para OpenType do pdf.js.

Isso não tem nada a ver com FreeType ... há um bug no conversor Type1 para OpenType do pdf.js.

Na verdade, é um problema relacionado ao FreeType porque apenas este mecanismo apresenta o problema. Pode haver um problema com o conversor do pdf.js e será útil entender por que isso está acontecendo. Infelizmente, o link acima não fornece explicações detalhadas. Mais informações dos especialistas em FreeType acelerariam a resolução desse bug.

Um arquivo de fonte convertido por pdf.js
O arquivo de fonte original embutido no PDF

Citações de escolha do relatório de bug FreeType:

A fonte em questão tem um sinal de raiz na letra 's'.

A fonte contém um cmap que mapeia a posição r' (not s ', BTW) para um glifo chamado .notdef'. Since the auto-hinter accesses a font not by glyph names but by a Unicode mapping (either a real one or a synthesized), it believes that glyph r' está presente

Os cmaps de fontes não devem mentir para o auto-hinter!

Provavelmente, também é parcialmente culpa do pdf.js, talvez o falso cmap esteja compilando do pdf.js, não da fonte original. Alguém precisa verificar.

O arquivo original cmex10.pfb' (version 003.002) as delivered with TeXLive has a correct encoding vector, using glyph name radicalbigg 'na posição 0x72. O arquivo subconjunto `CMEX10.pfb 'no relatório de bug do FireFox também possui o nome de glifo correto.

Correção provisória em # 7482. Não tenho recursos para examinar mais isso se o teste falhar, mas pode ser simples. A fonte no pdf é um pouco estranha, pois tem uma fonte simbólica, mas também possui mapeamentos Unicode para alguns dos símbolos. Normalmente, para fontes simbólicas, movemos todos os glifos para a área de uso privado se houver apenas um mapeamento Unicode de identidade.

Posso reproduzir # 7482 corrige o problema para mim pelo menos na segunda página do PDF com link no primeiro post.

@brendandahl Incrível, obrigado. Vou verificar se o seu patch corrige o mais rápido possível. É capaz de mesclar? (Parece que alguns testes estão falhando?)

É capaz de mesclar? (Parece que alguns testes estão falhando?)

Isso é esperado com este tipo de patch. No entanto, precisamos inspecionar as diferenças antes de fazer uma ligação.

Bom progresso! Fiz alguns testes mais extensos e encontrei uma complicação - a correção funciona para a saída produzida por dvips + ghostscript, mas não para a saída produzida por pdftex - se eu pegar a fonte do caso de teste acima e compilar com pdflatex, a saída é renderizada incorretamente .

Em anexo está um caso de teste mais exaustivo, incluindo uma das equações quebradas do arquivo 0707.3195v1.pdf original.

O primeiro arquivo pdf é produzido diretamente por pdflatex e a mesma saída é produzida por latex->dvips->ps2pdf . As capturas de tela são a renderização de pdf.js com a solicitação de pull aplicada - não resolve o problema com a saída de pdftex, mas corrige para a conversão do ghostscript.

Presumivelmente, há algo diferente na forma como a fonte é incorporada na saída pelo pdftex que faz com que o bug ainda ocorra.

test-pdftex.pdf - ainda quebrado

test-ps2pdf.pdf - corrigido

Fonte original de látex test.tex.txt

Olá @jpallen , só quero que você saiba que parece que o problema no Sharelatex foi corrigido quando eu mudo o compilador para o XeLatex.

Fizemos mais pesquisas sobre isso no ShareLaTeX, e parece que o patch acima (https://github.com/mozilla/pdf.js/pull/7482 por @brendandahl) está nas linhas certas em termos de mover personagens para a área de uso privada, mas não cobre todos os casos necessários. Os PDFs gerados pelo ps2pdf funcionam, mas os gerados diretamente pelo pdflatex ainda apresentam esse problema de renderização.

Se nós ingenuamente movermos _tudo_ para a área de uso privado (por exemplo, https://github.com/brendandahl/pdf.js/compare/move-non-unicode-glyphs...briangough:put-all-symbolic-chars-in- private-use-area), então ele renderiza corretamente. No entanto, este é apenas um exemplo de depuração, pois presumo que não seja uma boa ideia.

Neste ponto o nosso conhecimento chega ao limite e não sabemos como identificar os símbolos corretos para colocar na área de uso privado. Então, há algo que podemos fazer para ajudar a avançar?

Se nós ingenuamente movermos tudo para a área de uso privada (por exemplo, brendandahl @ move-non-unicode-glyphs ... briangough: put-all-symbolic-chars-in-private-use-area), então ele renderiza corretamente. No entanto, este é apenas um exemplo de depuração, pois presumo que não seja uma boa ideia.

Sem ter testado o acima, suspeito que fazer isso poderia realmente levar a uma renderização pior em _muitos_ arquivos PDF, uma vez que pode (basicamente) fazer com que as dicas sejam desabilitadas para _todas_ as fontes simbólicas em certos renderizadores de fontes. (Observe que muitas fontes afirmam ser simbólicas, mesmo quando na verdade não são.)

Neste ponto o nosso conhecimento chega ao limite e não sabemos como identificar os símbolos corretos para colocar na área de uso privado. Então, há algo que podemos fazer para ajudar a avançar?

Visto que os casos problemáticos usam fontes Type1 normais, ainda acho que a solução correta _pode_ ser garantir que fornecemos informações Charset / Encoding adequadas ao converter fontes Type1 em Type1Font_wrap .

@jpallen acho que precisamos reconhecer as fontes que são geradas pelo látex e essas fontes são símbolos (por exemplo, pelo nome ou a forma como são criadas), mas não devem ser reconhecidas como tal no restante dos casos.

Não mover _todos_ os caracteres para a área privada nos dá algumas vantagens, por exemplo, possibilidade de usar fontes em controles de entrada, melhor instrumentação e capacidade do mecanismo de descartar glifos ou fontes inválidos e ainda obter texto legível. Portanto, saber se o glifo é um símbolo é a chave aqui.

Uma ideia provisória, baseada em PR # 7482, poderia ser mover caracteres para o PUA quando não podemos confiar que os dados toUnicode estão corretos; por exemplo, algo assim: https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus : issue-2594.

Ótimo! Eu tentei o novo patch no Snuf fleupagus: issue-2594 e parece funcionar bem para o meu caso de teste e vários documentos pdflatex que experimentei. : +1:

Como um teste, implantei em produção no visualizador de pdf em

Testamos este patch (https://github.com/mozilla/pdf.js/compare/master...Snuffleupagus:issue-2594) em produção nas últimas 3 semanas e corrigiu os problemas de renderização de fontes LaTeX para nós, sem outros problemas aparecendo. Seria ótimo se pudesse ser incluído, obrigado. : +1:

Comecei a revisar # 7705 e comecei a me perguntar por que meu patch original também não corrigiu test-pdftex.pdf . Apenas olhando para os dados da fonte, parece que o pdf.js deve mover a maioria dos glifos de DVFZZA+CMEX10 para a área de uso privado, pois a maioria deles não tem nome de glifo válido para valores Unicode. Por exemplo, um dos glifos problemáticos (charcode = 110 name = 'braceleftBig') não tem um valor Unicode, mas estava sendo mapeado para 'n'. O problema parece vir de quando construímos um mapa Unicode, ele contém corretamente 68 valores com glifos que têm valores Unicode correspondentes, mas depois de construí-lo, adicionamos de volta todos os valores de codificação originais, portanto, 110 é preenchido com 'n'.

Não tenho certeza de qual é a correção certa aqui, porque se removermos o código para adicionar de volta os valores de codificação, nossa seleção de texto regredirá de https://github.com/mozilla/pdf.js/commit/325f7afcca30c891ec7be06a5178c012a052bd55

Talvez @Snuffleupagus tenha algumas ideias ...

_Como https://github.com/mozilla/pdf.js/issues/2594#issuecomment -254289210 sugere, a versão anterior do PR # 7705 continha uma solução que era muito simplista._

Portanto, eu montei uma nova (e provavelmente final) tentativa de consertar isso, que pode ser testada com: http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html.
Seria muito útil se as pessoas atualmente afetadas por esse problema testassem a versão mais recente do PR # 7705 e relatassem se é suficiente para corrigir o problema!

Funciona bem no test-pdftex.pdf, vamos tentar implantá-lo em produção em www.ShareLaTeX.com esta semana e ver se há algum problema relatado.

Funciona bem no test-pdftex.pdf, vamos tentar implantá-lo em produção em www.ShareLaTeX.com esta semana e ver se há algum problema relatado.

Conforme discutido no IRC, consulte http://logs.glob.uno/?c=mozilla%23pdfjs&s=21+Nov+2016&e=21+Nov+2016#c54315 , gostaríamos de avançar com PR # 7705 .
@briangough Você já obteve algum resultado do teste do patch em produção no ShareLaTeX?

Conforme mencionado anteriormente em https://github.com/mozilla/pdf.js/issues/2594#issuecomment -259930252, seria muito útil se as pessoas atualmente afetadas por este problema pudessem ajudar a testar a solução proposta, o que pode ser feito usando por exemplo, a visualização em http://107.21.233.14 : 8877 / 768d76e3834ac61 / web / viewer.html, e informe se corrige esses problemas!

Gostaríamos de pousar o PR # 7705, mas realmente precisamos da confirmação da correção antes de fazer isso.

Desculpe o atraso. O patch está funcionando bem - sem reclamações de nossos usuários, obrigado.

Fechamento corrigido por # 7705, graças a @Snuffleupagus e @brendandahl!