<p>pdf.js se basa en URL para contener la extensión 'pdf'</p>

@timvandermeij

¿Algún avance en esto? Lleva abierto más de dos años. Debido a que mi parámetro de archivo es una llamada al servidor que envía un archivo pdf de vuelta, el visor de pdf no puede detectar el nombre del archivo porque parece estar buscando una extensión .pdf y por eso estoy atascado con "document.pdf "al descargar y" untitled.pdf "en la barra de la ventana durante la visualización.

Sería útil si también pudiéramos especificar un "título" en el URI así como el "archivo" como ... / pdf-viewer / viewer.html? File = "..." & title = "... "

Sé que actualmente se está trabajando en # 7554 para admitir el encabezado Content-Disposition , que es una forma de resolver este problema. Sin embargo, estoy de acuerdo en que document.pdf no es el mejor nombre posible y es posible que necesitemos mejorar la función para obtener el nombre (archivo). Los parches para esto son bienvenidos, así que lo etiqueto como un buen error para principiantes, ya que no debería ser demasiado difícil de implementar.

@timvandermeij Excelente, gracias, creo que apoyar Content-Disposition realmente solucionaría mi problema.

Estoy de acuerdo, mientras revisaba el código, noté que no debería ser demasiado difícil simplemente agregar otro parámetro de URL para el nombre del archivo. Lo intentaré en los próximos días, gracias.

Los parches para esto son bienvenidos, así que lo etiqueto como un buen error para principiantes, ya que no debería ser demasiado difícil de implementar.

@timvandermeij Recuerde que en PR # 4956 nos alejamos intencionalmente de permitir que varios parámetros hash afecten al espectador (a menos que la depuración esté habilitada, consulte https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js) .
Por lo tanto, no creo que debamos hacer posible especificar title usando un parámetro hash.

Especialmente considerando que no sería estándar (en el contexto de http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_open_parameters.pdf), y en comparación con el Content-Disposition Enfoque

Lo siento, debería haber sido más claro. Quise decir que los parches son bienvenidos para mejorar la función que determina el nombre del archivo a partir de la URL. Creo que podemos hacerlo mejor allí en lugar de depender solo de la extensión del archivo. Estoy de acuerdo en que no deberíamos agregar más parámetros hash.

¿Cuál es el estado de este problema? ¿Esto todavía está abierto?

¿Cuál es el estado de este problema? ¿Esto todavía está abierto?

@anirudhrb aún está abierto, hubo un intento de implementar eso en el # 7554, ¿le gustaría contribuir a eso?

@yurydelendik Sí, me gustaría contribuir. ¿Qué se espera en un PR para este problema?

@anirudhrb , puede tomar el PR anterior como base, ya que tiene la comunicación remota de datos algo correcta; esperaríamos un pequeño parche con pruebas unitarias. No necesitamos análisis de disposición de contenido específico, pero lo suficiente para obtener el nombre del archivo.

@yurydelendik He empezado a trabajar en esto. Este es mi primer intento de contribuir a un proyecto de código abierto. Necesitaré algo de tiempo para sentirme cómodo con el código base. :)

@yurydelendik , @timvandermeij ¿Podría abordar este tema si está de acuerdo con todos ustedes?

Hay una solicitud de extracción arriba que parece la dirección correcta, pero no ha habido más actividad para ella. Si está interesado en arreglar eso, suena bien. Preguntaré si el autor original todavía planea trabajar en él.

Corregido en # 9379.