<p>pdf.js depende de urls para conter a extensão 'pdf'</p>

@timvandermeij

alguma atualização disso? Está aberto há mais de dois anos. Como meu parâmetro de arquivo é uma chamada de servidor que envia um arquivo pdf de volta, o visualizador de pdf não consegue detectar o nome do arquivo porque parece estar procurando por uma extensão .pdf e, portanto, estou preso em "document.pdf "durante o download e" untitled.pdf "na barra da janela durante a visualização.

Seria útil se também pudéssemos especificar um "título" no URI, bem como o "arquivo", como ... / pdf-viewer / viewer.html? File = "..." & title = "... "

Eu sei que atualmente o trabalho está sendo feito no # 7554 para oferecer suporte ao cabeçalho Content-Disposition , que é uma maneira de resolver esse problema. Eu concordo, entretanto, que document.pdf não é o melhor nome possível e podemos precisar melhorar a função para obter o nome (do arquivo). Patches para isso são bem-vindos, então estou rotulando isso como um bom bug para iniciantes, pois não deve ser muito difícil de implementar.

@timvandermeij Excelente, obrigado, acredito que apoiar Content-Disposition resolveria meu problema.

Eu concordo, conforme eu estava examinando o código, percebi que não deveria ser muito difícil simplesmente adicionar outro parâmetro de URL para o nome do arquivo. Vou tentar nos próximos dias, obrigado.

Patches para isso são bem-vindos, então estou rotulando isso como um bom bug para iniciantes, pois não deve ser muito difícil de implementar.

@timvandermeij Lembre-se de que no PR # 4956, propositadamente deixamos de permitir que vários parâmetros hash afetassem o visualizador (a menos que a depuração esteja ativada, consulte https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js) .
Portanto, não acho que devemos tornar possível especificar title usando um parâmetro hash!

Especialmente considerando que seria fora do padrão (no contexto de http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_open_parameters.pdf) e comparado com Content-Disposition abordagem em PR # 7554, realmente não agrega muito valor.

Desculpe, eu deveria ter sido mais claro. Eu quis dizer que os patches são bem-vindos para melhorar a função que determina o nome do arquivo a partir do URL. Acho que podemos fazer melhor lá, em vez de depender apenas da extensão do arquivo. Concordo que não devemos adicionar mais parâmetros de hash.

Qual é a situação desse problema? Ainda está aberto?

Qual é a situação desse problema? Ainda está aberto?

@anirudhrb ainda aberto, houve uma tentativa de implementar isso em # 7554, gostaria de contribuir para isso?

@yurydelendik Sim, gostaria de contribuir. O que é esperado em um PR para este problema?

@anirudhrb , você pode apenas tomar o PR acima como base, já que ele tem remoting de dados certo - esperaríamos um pequeno patch com testes de unidade. Não precisamos de análise de Disposição de Conteúdo de especificação, mas o suficiente para obter o nome do arquivo.

@yurydelendik Comecei a trabalhar nisso. Esta é minha primeira tentativa de contribuir para um projeto de código aberto. Vou precisar de algum tempo para me familiarizar com a base de código. :)

@yurydelendik , @timvandermeij Posso abordar esse problema se estiver tudo bem para todos vocês?

Há uma solicitação pull acima que parece ser a direção certa, mas não houve mais atividade para ela. Se você está interessado em consertar isso, parece bom. Vou perguntar se o autor original ainda está planejando trabalhar nisso.

Corrigido em # 9379.