<p>pdf.js verwendet URLs, um die Erweiterung 'pdf' zu enthalten</p>

@ Timvandermeij

Gibt es hierzu Neuigkeiten? Es ist seit mehr als zwei Jahren geöffnet. Da mein Dateiparameter ein Serveraufruf ist, der eine PDF-Datei zurücksendet, kann der PDF-Viewer den Namen der Datei nicht erkennen, da er nach einer PDF-Erweiterung zu suchen scheint und ich daher bei "document.pdf" stecke "beim Herunterladen und" untitled.pdf "in der Fensterleiste beim Anzeigen.

Es wäre praktisch, wenn wir auch einen "Titel" in der URI sowie die "Datei" angeben könnten, z. B. ... / pdf-viewer / viewer.html? File = "..." & title = "... ""

Ich weiß, dass derzeit in # 7554 daran gearbeitet wird, den Header Content-Disposition zu unterstützen. Dies ist eine Möglichkeit, dieses Problem zu lösen. Ich stimme jedoch zu, dass document.pdf nicht der bestmögliche Name ist und wir möglicherweise die Funktion zum Abrufen des (Datei-) Namens verbessern müssen. Patches hierfür sind willkommen, daher bezeichne ich dies als einen guten Anfängerfehler, da es nicht zu schwer zu implementieren sein sollte.

@timvandermeij Ausgezeichnet, danke, ich glaube, die Unterstützung von Content-Disposition würde mein Problem tatsächlich beheben.

Ich stimme zu, als ich den Code durchging, bemerkte ich, dass es nicht allzu schwierig sein sollte, einfach einen weiteren URL-Parameter für den Dateinamen hinzuzufügen. Ich werde es in den nächsten Tagen versuchen, danke.

Patches hierfür sind willkommen, daher bezeichne ich dies als einen guten Anfängerfehler, da es nicht zu schwer zu implementieren sein sollte.

@timvandermeij Bitte denken Sie daran, dass wir in PR # 4956 absichtlich davon Abstand genommen haben, dass verschiedene Hash-Parameter den Viewer beeinflussen (sofern das Debuggen nicht aktiviert ist, siehe https://github.com/mozilla/pdf.js/wiki/Debugging-pdf.js). .
Daher denke ich nicht, dass wir es ermöglichen sollten, die title mit einem Hash-Parameter anzugeben!

Besonders wenn man bedenkt, dass es nicht dem Standard entspricht (im Kontext von http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/pdf_open_parameters.pdf) und mit dem Content-Disposition verglichen wird

Entschuldigung, ich hätte klarer sein sollen. Ich meinte, dass Patches willkommen sind, um die Funktion zu verbessern, die den Dateinamen aus der URL bestimmt. Ich denke, wir können es dort besser machen, anstatt uns nur auf die Dateierweiterung zu verlassen. Ich bin damit einverstanden, dass wir keine weiteren Hash-Parameter hinzufügen sollten.

Wie ist der Status dieses Problems? Ist das noch offen?

Wie ist der Status dieses Problems? Ist das noch offen?

@anirudhrb noch geöffnet, es gab einen Versuch, das bei # 7554 zu implementieren. Möchten Sie dazu beitragen?

@yurydelendik Ja, ich möchte einen Beitrag leisten. Was wird in einer PR für dieses Problem erwartet?

@anirudhrb , Sie können einfach die oben genannte PR als Basis nehmen, da das Remoting von Daten etwas richtig ist - wir würden einen kleinen Patch mit einem Unit-Test erwarten. Wir brauchen kein spezielles Content-Disposition-Parsing, aber genug, um den Dateinamen zu erhalten.

@yurydelendik Ich habe angefangen daran zu arbeiten. Dies ist mein erster Versuch, zu einem Open-Source-Projekt beizutragen. Ich brauche etwas Zeit, um mich mit der Codebasis vertraut zu machen. :) :)

@yurydelendik , @timvandermeij Könnte ich dieses Problem aufgreifen , wenn es für Sie alle in Ordnung ist?

Es gibt eine Pull-Anfrage, die wie die richtige Richtung aussieht, aber es wurde keine Aktivität mehr dafür ausgeführt. Wenn Sie daran interessiert sind, dieses Problem zu beheben, klingt das gut. Ich werde fragen, ob der ursprüngliche Autor noch vorhat, daran zu arbeiten.

In # 9379 behoben.