Auf vielen Windows-Systemen läuft der Adobe PDF-Reader, um entsprechende Dokumente zu öffnen. Problem an dieser Sache ist, dass der Adobe Reader (oder Adobe Acrobat) inzwischen recht fett und fehleranfällig ist. Ein Blog-Leser hat mich vor einigen Tagen auf einen schlanken PDF-Reader hingewiesen, der unter Windows läuft.
Blog-Leser Michael E. schrieb mir dazu: "Ich habe lange nach einem vernünftigen schmalen und passenden PDF-Reader gesucht, nicht diese "fetten" Programme wie Adobe etc. Nach längerem Test habe ich etwas gefunden das vielleicht auch für andere Windows-Nutzer interessant sein könnte."
Das Programm nennt sich KillerPDF und wird auf dieser Webseite zum Download angeboten. Das Windows-Programm umfasst knapp 15 MByte und kommt ohne Installer. Auf der Webseite schreibt der Entwickler:
Ein vollwertiger PDF-Editor zum Anzeigen, Bearbeiten, Erkennen von Text (OCR), Ausfüllen und Signieren … alles über eine einzige native .exe-Datei (~16 MB), ganz ohne Konto und ohne dass Daten an Dritte übermittelt werden.
Der Entwickler bezeichnet sich als Außendiensttechniker und Systemadministrator bei einem großen MSP. Er sei seit 2017 in der IT tätig, hat aber bereits in den 90er-Jahren Websites gebaut und sei etwa sechs Jahre lang als Full-Stack-Entwickler tätig gewesen, bevor er in die IT wechselte. Daher sei er in einem Quellcode-Programm ebenso zu Hause wie in einem Serverraum. Der Mann zeigt sich genervt und schreibt:
Ich hatte es satt, immer wieder dasselbe Adobe-Ticket zu schließen. Also habe ich eine PDF-App geschrieben, die einfach funktioniert, als eine einzige EXE-Datei ausgeliefert wird und den Nutzer niemals auffordert, sich anzumelden.
Er skizziert seinen Arbeitstag als Administrator in der IT, den einige Leser sicher kennen: "Ein fester Bestandteil meiner Arbeitstage war schon immer derselbe: Ein Nutzer kann ein PDF nicht ausfüllen, ein Formular lässt sich nicht flachstellen, eine Lizenz lässt sich nicht aktivieren, ein Viewer gibt bei einer Datei, die sich eigentlich einfach öffnen sollte, eine Fehlermeldung aus. Adobe-Acrobat-Tickets – installieren, reparieren, lizenzieren, Workarounds finden – summierten sich jede Woche zu Stunden, bei denen ich nie das Gefühl hatte, dass sie tatsächlich etwas lösten."
Also hat er selbst einen PDF-Viewer/-Editor geschrieben und diesen KillerPDF genannt. KillerPDF ist ein nativer PDF-Viewer, Annotator und einfacher Editor für Windows, der als einzelne, in sich geschlossene ausführbare Datei bereitgestellt wird. Es ist kein Installationsprogramm, kein Konto, kein Abonnement, kein Lizenzserver, um den man sich kümmern muss, erforderlich. Es reicht die .exe-Datei aufzurufen, und schon kann es losgehen.
Das Programm ist bewusst für die Realität von Außendiensttechnikern überdimensioniert, schreibt der Entwickler: Es öffnet verschlüsselte PDF-Dateien mit defekten Querverweisen sowie gedrehte und beschnittene PDF-Dateien, an denen andere Viewer scheitern . Dies seien genau diese Dateien, die Supportanfragen auslösen. Der Viewer rendert mit PDFium, führt OCR mit Tesseract durch, füllt Formulare aus und signiert sie. Zudem druckt KillerPDF mit 300 DPI – alles lokal, ohne Telemetrie und ohne Werbung.
Ein Großteil der Funktionen wurde von den Nutzern selbst gewünscht. Die GitHub-Issues-Seite steht jedem offen, und die Vorschläge der Nutzer bestimmen maßgeblich die weitere Entwicklung. KillerPDF ist freie Software unter der GPL-3.0-Lizenz. Ausführliche technische Details finden sich auf der Seite Technische Informationen. Danke an den Leser, vielleicht ist das Tool ja was für den einen oder anderen Blog-Leser.
MVP: 2013 – 2016
Ist ja wirklich noch schlanker und schneller als Sumatra-PDF.
Danke für den Hinweis. Mit KillerPDF kann man sogar kleine Änderungen am Text vornehmen :-)
Bisher reicht mir die Browser integrierte PDF Reader Funktion aus. Spare ich mir noch eine 3rd Party App zu patchen :-) Wobei auch der Einsatz von PDF sich in den letzten Jahren stark reduziert hat und ich es im Arbeitsalltag adhoc kaum noch aktiv wahr nehme das ich noch PDF Dateien herunterladen bzw. Online anschaue :-)
Er hat eine schicke UI in C#/-NET für PDFium, PdfSharpCore, Tesseract und pdfpig und alles zusammen vibe-coded, so wie ich den Code sehe (z.b. Abbruchbedingungen mittendrin statt direkt am Anfang von Funktionen etc.) Und hat er – meiner Einschätzung – noch einen weiten Weg vor sich, bis alles stable wird.
Die Entscheidung für WPF überrascht mich etwas. Für ein neues Projekt hätte ich eher MAUI oder Avalonia UI in Betracht gezogen, um die Anwendung von Anfang an plattformübergreifend aufzubauen.
Schade, er hätte mehr erreichen können. So reicht es leider nicht mal für meine Watch-List, da ich auf dieser nur plattform-übergreifende Programme habe.
Die Angaben "nur 15 MB groß" stimmen nur für die Executable, die ganzen Libs und Dependencies drumherum nehmen ein Vielfaches mehr in Anspurch. Alleine die pdfium.dll braucht je nach Ausführung zwischen 15 und 50 MB.
Das Ding als "native Windows-Applikation" zu bezeichnen ist eine dreiste Lüge: .NET ist NICHT "native".
Ausserdem entpackt das Ding ausführbare Dateien nach %LOCALAPPDATA%, d.h. es ist mit SAFER/AppLocker unverträglich — ein , der solchen SCHROTT verbricht, ist keiner!
Ja da habe ich mich auch schon drüber gewundert. Der Nebenwitz der ganzen Geschichte. Da nutzt er schon "managed Code" und greift dann trotzdem auf Win32 Interops zurück.
Das mit SRPs sagt viel aus über das Mindset und die Fähigkeiten.
Komm Mal etwas runter . Niemand zwingt dich das zu verwenden. Du kannst es wenn es doch verwenden willst anpassen. Mach es erstmal besser.
@xx: Thomas Jakobs hat über Jahre hinweg für mich einen sehr wohl und gut dokumentierten Beweis seiner Kompetenz erbracht.
Du hingegen versteckst dich (wie ich) hinter einem Pseudonym (wobei ich für mich herausnehmen möchte, dass ich mich nicht anheischig mache, TJ mit "mach es erstmal besser" herauszufordern, ohne jegliche Beweise meiner eigenen Kompetenz zu liefern!)
Im Übrigen teile ich Stefan Kanthaks Meinung über die doch etwas fragwürdige Programmierung mit verteilten Dateien im Benutzerprofil(?) – (werden die auch jemals wieder "aufgeräumt"?)
Ausserdem bin ich (mit Debian) und qpdf und qpdfview ausserordentlich glücklich – qpdf als Kommandozeilentool mag vielleicht eine etwas hohe Einstiegshürde haben, ist dafür extrem schlank und überaus mächtig!
All the best!
Es wird ".NET Framework 4.8" als TargetFramework benutzt (nicht neuere "NET Desktop").
Das funktioniert auch mit ".NET Framework 4.8.1".
2.
Das Tool "IlSpy" zeigt folgendes bei der Analyse der KillerPDF.exe:
"AssemblyAssociatedContentFile("pdfium.dll")]"
In meinem Pfad finde ich keine pdfium.dll.
Man braucht keine zusätzliche Datei pdfium.dll irgendwo im Pfad.
Eine externe "pdfium.dll" wird nicht benutzt, sondern die pdfium-Funktionen werden direkt in die exe reinkompiliert bzw in die exe gelinkt und die pdfium.dll befindet sich komprimiert mit in der KillerPDF.exe und wird dann im RAM ausgepackt.
Das hat den Nachteil, dass die pdfium.dll nicht eigenständig upgedatet werden kann, falls mal Lücken gefunden werden.
In der KillerPDF.exe findet man:
costura64.pdfium.dll.compressed
110.0.5445.0
pdfium.dll
8BA7A14E6177154D373C07E18791F5AD8376FD65
Also Versionsnummer und sha256
3.
Beweise für vibe-coding habe ich noch keine gefunden.
Die pdfium.dll Datei wird in C:\\Users\\[user]\\AppData\\Local\\Temp\\… geschrieben und von dort verwendet, nicht im RAM.
Stimmt, du hast recht:
c:\Users\USERNAME\AppData\Local\Temp\Costura\F87E632EEF4AFA03CD125121B8E8D133\64\pdfium.dll
Also ein Dropper.
In der exe befinden sich noch mehr dll:
PdfSharp.dll
pdfpig.dll
Tesseract.dll
costura.communitytoolkit.mvvm.dll
und deren Varianten mit ".core." im Dateinamen etc…
Diese werden aber vermutlich erst bei Bedarf ausgepackt, etwa beim Drucken oder bei OCR.
Komprimiert mit DeflateStream (=gzip) aus den Fody/Costura Tools.
*https://github.com/fody/costura
Man muss ja auch nicht selber das Rad neu erfinden, sondern es ist legitim, bereits fertige Routinen zu benutzen.
So ein paar Hinweise:
1. ich sehe viele Enum-Abfragen nach z.B. if(hits.Count > 0)
.Any() wäre da die idiomatischere und IMHO die sicherere Wahl, was ein LLM nicht empfiehlt, weil statistisch jeder Depp und sein dummer Bruder lieber .Count zählt.
2. Er dokumenitert viel und gut, aber dann tauchen plötzlich aus dem Nichts "MagicNumbers" auf, ohne Erklärung, ohne Kommentare (Beispiel: query.Length + 20 in https://github.com/SteveTheKiller/KillerPDF/blob/main/Services/SearchService.cs) WTF wie kommt er auf die 20? Das würde ich mich doch fragen.
3. Dann überall leere Catches { } ohne ein Logging – ist nicht nur fragwürdig sondern wird oft auch von Vibe-Code so ausgeworfen. Als Dev mache ich doch zuerst ein zentrales Logging in meinen Code, damit ich genau weiß, was passiert. Aber gut, er ist halt Windows-Dev und Windows-Admin…
Ja, ich denke der ursprüngliche Code ist vibe-coded und anschliessend manuell überarbeitet – nicht wirklich zum Besseren.
Count vs Any() – da empfiehlt die VisualStudio Code Analysis Regel CA1860 die Count Property (nicht die Count() Methode!) zu verwenden. Ich hatte auch immer Any() genommen und erwartet daß der Compiler sich um die Optimierung kümmert. Anscheinend nicht, weshalb ich mich umgewöhnen muss.
Das kann also auch ein Zeichen sein dass der Autor versucht CA-Warnungen zu vermeiden.
Du hast auch Recht – es kommt wie so oft darauf an.
Die Verwendung von Any ist IMHO deutlich robuster bei späteren Änderungen oder Erweiterungen. Wenn in einem Enum oder Collection Elemente oder Zustände hinzukommen wie z.B. "New" oder "NotSaved", "Inactive" oder "Undefined".
Wer sich an der Compiler Warnung stört, kann diese mit #pragma warning disable und restore CA1860 für diese Abfrage ausschalten.
Blind Code rauszuhauen, nur um keine Warnungen zu bekommen, dafür aber eine crashende App, ist nicht besonders clever.
Den werde ich mir mal als Zusatztool unter die Lupe nehmen, danke für den Tipp. Beworben wird KillerPDF explizit als PDF-Editor. Aber natürlich kann man ihn auch einfach als Viewer verwenden. "Schlank" ist aber wieder relativ.
>>> Größe der Programmdatei:
Adobe Acrobat: 6,9 MB
KillerPDF: 15,6 MB
SumatraPDF: 10,5 MB
>>> Belegter Arbeitsspeicher wenn Programm im Vordergrund, ohne geladene PDF-Datei (linker Wert Task-Manager / rechter Wert Working Set laut Process Explorer):
Adobe Acrobat: 204 MB / 188 MB
KillerPDF: 128 MB / 203 MB
SumatraPDF: 3,6 MB / 28,5 MB
Ja, dem SumatraPDF fehlen einige Funktionen. Aber genau deshalb schätze ich ihn sehr als reinen PDF-Viewer. Er ist so unfassbar schnell und ressourcensparend. Und er kann auch keine aktiven Inhalte anzeigen, was heutzutage ein Sicherheitsfeature ist ¯\_(ツ)_/¯
Falls man mal ein Formular ausfüllen oder Inhalte einer PDF verändern muss, kann man immer noch auf andere kostenlose Tools wie eben KillerPDF, PDFgear, PDF24 umschwenken.
KillerPDF ohne geladenes PDF belegt bei mir 36 MB RAM laut Taskmanager.
Nachdem ich aber ein PDF geladen und wieder geschlossen hatte (Close-Button), zeigt der Taskmanager 209 MB RAM Verbrauch an.
Warum fällt der RAM-Verrbauch nicht auf 36 MB zurück?
Werden nicht alle Handles geschlossen?
Wenn ich das selbe PDF erneut im KillerPDF öffne, dann erhöht sich der RAM-Verbrauch auf 414 MB statt vorher 209 MB.
Memory-Leak?
Zum Vergleich:
SumatraPDF braucht mit diesem PDF nur 15 MB RAM und nach dem Schließen des PDF nur 7 MB RAM.
Das PDF selber hat nur 3 MB.
Du hast die PDF geschlossen oder die ganze App? Die verwendeten Libs/Objekte könnten solange die Anwendung noch offen ist, geladen bleiben, um beim nächsten Zugriff schneller zu sein. Leak wäre es erst, wenn die Anwendung vollständig geschlossen wird.
Nur das PDF wurde geschlossen, die exe blieb offen.
Dass die LIBs im RAM offen bleiben ist ja noch ok, aber warum erhöht sich dann der RAM-Verbrauch um über 200 MB beim erneuten Öffnen des selben PDF?
Eigentlich dürfte sich der RAM-Verbauch dann nur um das entpackte PDF erhöhen, also ca 8 MB wie bei SumatraPDF.
Ja das ist in Tat seltsam… aber Deine Messung mit dem Task Manager ist unzuverlässig. Wäre aber ein Punkt, wo man defintiv optimieren könnte. Normalerweise sollte das einem Dev auffallen, gerade wenn man selbst dieses täglich einsetzt.
Ich hätte mir den Speicherverbrauch wohl doch auch mit geöffneten PDFs anschauen sollen, wenn ich das so lese. Nach all den Hinweisen in den Kommentaren muss man ja leider wirklich von einer vibe gecodeten Anwendung ausgehen, oder zumindest von einer nicht ganz durchdachten Umsetzung.
Wie Tomas weiter bereits geschrieben hat, ist die Anzeige im Task-Manager unzuverlässig bzw. zeigt nur das halbe Bild. Aussagekräftiger ist das "Working Set" (Arbeitssatz) sowie "Private Bytes" (Privat) / "Working Set Private Bytes". Kannst du dir mit Tools wie Process Explorer und teilweise auch mit dem Windows-eigenen Ressourcenmonitor anzeigen lassen.
Hab das eben getestet und mit PDF24 verglichen. KillerPDF ist doch deutlich langsamer als PDF24. Das macht aber nur bei dem Durchsuchen von vielen PDFs per Vorschaufenster einen Unterschied. Zum Öffnen von Einzeldateien oder zum Mitnehmen und Bereithalten eines sich nicht ändernden Readers mit Bearbeitungsfunktion ist KillerPDF allerdings echt eine gute Sache. Ich werde mir davon eine Kopie aufheben.
Adobe Acrobat ist für mich inzwischen nichts weiter als eine reine Belästigungssoftware. Die Nutzung der Gratisversion ist alles andere als erfreulich. Die langen Ladezeiten und fast genauso lange Wartezeit beim Schließen sind schon echt eine Frechheit. Die Krönung sind die bildfüllenden Werkzeugleisten, die man nicht benutzen kann und nur mit langem Suchen teilweise abstellen kann. Die Wartezeit beim Schließen ist meiner Einschätzung nach die Zeit, die Adobe für das Versenden der Daten nach Hause und das Abwarten der Empfangsbestätigung benötigt.
Wenn man bei einem zweispaltigem PDF den Text aus nur einer der beiden Spalten mit der Maus markieren möchte, dann nimmt er leider den Text aus den kompletten Zeilen über beide Spalten hinweg.
SumatraPDF hingegen nimmt nur den Text aus der selben Spalte (korrekt).
Diese spaltenweise Markierung sollte man in KillerPDF einbauen.
2.
Wenn ich den "Select" Button anklicke und dann etwas im PDF selektiere, dann ist die Selektierung sofort wieder verschwunden, sobald ich die Maustaste loslasse, sofern ich bei Beginn der Selektierung nicht exakt einen Buchstaben erwischt hatte. Wenn man also einen Rahmen im freien Bereich um einen Text herum zieht, dann funktioniert es nicht.
Hi, danke für den guten Tipp, auch die anderen Tools von ihm machen einen guten Eindruck!
PDFGear – https://www.pdfgear.com/
Ki-gestützte PDF-Software, really? Sitz in Singapur, läuft im Browser,
Aktuell ist die KI in pdfgear nur durch einen Copilot-Button präsent und kann durch ein Schalter abgeschaltet werden. Bei mir sehr passiv das KI-Gedöns und mir ist das bisher nicht aufgefallen. Dabei funktioniert das Tool ziemlich gut, der einzige kostenfreie PDF-Editor, mit dem ich zurechtkomme.
Bei KillerPDF wird leider die Schriftart und die Schriftgröße zerschossen.
Auch KillerPDF seht mir vibe-coded aus…
Sitz in Singapur?
Meines Wissens (ich mag mich täuschen) hat die Firma Pdf Gear Tech Ltd. ihren Sitz in China, siehe auch:
https://www.dnb.com/business-directory/company-profiles.pdf_gear_tech_ltd.bbcbdfa9110dd665dd17a8e30b8c3ce0.html
ich bezog mich auf die Angaben der Webseite
Ich hab KillerPDF noch nicht getestet, aber gelesen was er unter "Technik" schreibt.
Interessant finde ich den Punkt "Robustheit" – müsste man mal testen, ob er Problem-PDFs, wo andere Reader scheitern, dann wirklich anzeigen kann.
Aber SumatraPDF hat bei mir bisher jede PDF angezeigt, und der läuft bei mir auch auf einem alten Win7 PC einwandfrei.
Die Motivation von Steve the Killer kann ich allerdingt gut verstehen, wenn man sich lang genug mit Adobe Acrobat & Co rumärgern muss, dann ist die Entscheidung was eigenes zu programmieren nur konsequent.
Bug:
Beim Klick auf das Fragezeichen erscheint ein Fenster mit den Tastatur-Kürzeln.
Oben rechts in diesem Fenster ist ein X, aber dieses ist nicht anklickbar.
Also kann man dieses Fenster mit der Maus nicht schließen, sondern nur mit F1 oder ESC-Taste.
2. (kein Bug):
Laut Source-Datei "about.cs" gibt es im About-Dialog (unten rechts, wo die Versionsnummer steht) einen automatischen Update-Check und Auto-Installer-Button.
Dieser nur im Updatefall eingeblendete Button im About-Dialog erzeugt eine Batch-Datei im Temp-Ordner (Dropper, harmlos).
Normalerweise sollte man die Temp-Ordner im Applocker sperren und dann würde diese Updater-Batch nicht mehr starten können.
Diese Batch allerdings hat normalerweise auch gar keine Schreibrechte im "C:\Programm Files" Ordner, falls man als Standardbenutzer arbeitet.
Das Programm geht also davon aus, dass es in einem Ordner gespeichert ist, wo der User auch Schreibrechte hat (siehe auch den Button in der Mitte unten "Install KillerPDF"):
%LocalAppData%\KillerPDF
Aus Sicherheitsgründen sollte man aber Schreibrechte und Ausführungsrechte strikt trennen und nicht für den selben Ordner gelten lassen.
Deshalb speichere ich Programme in "C:\Programm Files", weil der Standardbenutzer dort keine Schreibrechte hat.
Wenn ich Programme außerhalb dieses Ordners speichere, dann whiteliste ich auch nur genau diese aktuelle exe mittels Dateihash im Applocker. Dann funktionieren Updates auch nicht mehr, ohne erneute Freigabe durch einen aktualisierten Dateihash.
Man muss auch darauf vertrauen, dass das runtergeladene-Update auch in Zukunft sauber bleibt (das gilt aber generell für alle anderen Programme ebenso):
*https://github.com/SteveTheKiller/KillerPDF/releases/download/{tag}/KillerPDF.exe
Melde doch die Fragen und Ungereimtheiten an den Entwickler. Ich denke, der wird das dankbar aufgreifen.
Mein "Feldtest" unter WINDOWS 11 Version 26200.8875 ->
KillerPDF direkt nach dem Öffnen: 66 MB belegt laut Task-Manager
KillerPDF nach dem Öffnen einer 80 MB großen PDF: 494 MB belegt laut Task-Manager
KillerPDF nach dem Durchlaufen jeder Seite des 80 MB PDF: 1085 MB belegt laut Task-Manager
KillerPDF nach dem Schliessen des 80 MB PDF: 385 MB belegt laut Task-Manager
PDF-XChangeViewer direkt nach dem Öffnen: 13 MB belegt laut Task-Manager
PDF-XChangeViewer nach dem Öffnen einer 80 MB großen PDF: 34 MB belegt laut Task-Manager
PDF-XChangeViewer nach dem Durchlaufen jeder Seite des 80 MB großen PDF: 918 MB belegt laut Task-Manager
PDF-XChangeViewer nach dem Schließen des 80 MB PDF: 27 MB belegt laut Task-Manager
Eigene persönliche Einschätzung: Ernüchternd!
Obwohl ich die Idee einer einzelnen ausführbaren Datei gar nicht mal so schlimm/schlecht finde, lassen die Vergleiche mit dem doch nun schon betagten PDF-XChangeViewer speichertechnisch gesehen noch viel Potenzial übrig. Auch die bereits beschriebene Restbelegung des Arbeitsspeichers nach Schliessen eines PDF sollte mit den heutigen Speicherbestückungen eigentlich kein Problem mehr darstellen – von einem speicherfreundlichen Programm würde ich dann doch hier nicht schreiben wollen.
Den beschriebenen Fehler mit dem nicht funktionierenden Schliessen-Symbol in den Einstellungen konnte ich mit Version 1.6.6 nicht (mehr) feststellen.
Trotzdem wünsche ich dem Ersteller (auch wenn er es hier vermutlich nicht lesen wird) noch viel Freude und wie schon oben beschrieben sehe ich durchaus Potenzial für dieses Programm.
"nun schon betagten PDF-XChangeViewer"
—
Dessen Nachfolger ist der "PDF-XChange Editor".
Die abgespeckte Variante davon ist "PDF-XChange Lite".
Da ich diesen Beitrag / diese Diskussion quasi angestoßen habe möchte ich ausführen warum ich das Programm schätze.
Hauptsächlich weil es portabel ist, auf einem USB-Stick mit vielleicht noch einigen anderen Tools, kann ich auf fast jedem anderen (Windows-) Rechner PDFs lesen und vor allem bearbeiten und ausfüllen.
Ich helfe (ehrenamtlich) anderen beim Ausfüllen von Formularen, Anträge etc. Wer schon einmal einen deutschen PDF-Wohngeldantrag oder bei der Krankenkasse einen Antrag auf Hilfsmittel ausfüllen musste, weiß wovon ich rede.
Alles gut, du brauchst dich hier in keinster Weise zu rechtfertigen!
Wenn das Programm für dich läuft wie es denn soll, ist das doch fein.
Als Hinweis als mögliche Alternative ist das doch hier gerne gesehen – muß letztendlich jeder für sich entscheiden, welches Programm für denjenigen die nötigen Eigenheiten mitbringt.
Vielen Dank für deinen Hinweis hier!
Danke für deinen wertvollen Hinweis. Endlich mal was produktives!
Solche Hinweise auf Tools schätze ich. Danke für deinen Tipp.
Falls jemand einen First-Level-Viewer-only zu Sicherheit direkt aus der Mailer-App heraus will -> OHNE Script-, Formular-, Druck-, Hyperlink-Support kann man sich mal Sumatra-PDF ansehen (auch als Portable):
https://www.sumatrapdfreader.org/free-pdf-reader
https://www.sumatrapdfreader.org/docs/Configure-for-restricted-use
Von dort aus lässt sich dann wenn direkt ein Acrobat aufrufen, wenn man mehr will.
Kann ich aus dem beruflichen Alltag nicht bestätigen. PDFs oft per Email versendet und auch Faxe werden durch entsprechende Gateways also z.B. Multifunktionsgeräte in PDFs umgewandet. Aber es stimmt schon privat nutze ich auch die PDF-Funktion des Browsers.
Die Browser haben aber ein Problem mit PDFs, die innen mehrere Dokumente enthalten (kommen gerne schon mal von Banken/Versicherungen), da wird dann nur das erste Dokument angezeigt und das Inhaltsmenü mit den weiteren fehlt.
Da brauchts dann doch wieder einen "richtigen" Reader, der das komplett anzeigen kann.
Als PDF-Reader ist in unserer Unternehmungsumgebung nach wie vor der Adobe Acrobat Reader im Einsatz und wird über unsere UEM-Lösung automatisch auf allen Clients verteilt.
Aktuell leider keine Chance diesen loszuwerden, da einige Fachanwendungen diesen nach wie vor zwingend voraussetzen.
Als PDF-Editoren sind im Einsatz:
– PDF24
– BentoPDF
BentoPDF kann ich für Unternehmungsumgebungen empfehlen.
Läuft hier On-Prem auf Basis von Docker ohne Probleme.
Die Lizenzkosten für eine Lifetime-Lizenz liegen bei $79.
Siehe auch:
https://www.bentopdf.com/
https://www.bentopdf.com/de/licensing
Die beiden oben genannten Programme bieten auch die Funktion "Schwärzen", welche von unseren Usern immer wieder angefragt wird und von den meisten "kostenlosen" PDF-Editoren nicht angeboten wird.
Good morning, everyone.
We, too, are looking into alternatives to Adobe Reader, as it is becoming increasingly bloated.
Do you know of any free alternatives that also support the verification of digital signatures on PDF files (specifically PAdES signatures)?
According to the user manual, Foxit Reader supports PAdES.
https://www.foxit.com/pdf-reader/
https://www.foxit.com/resource-hub/user-manuals/foxit-pdf-reader-user-manual/
Thanks for the advice.
The PDF Xchange Editor https://www.pdf-xchange.com/product/pdf-xchange-editor can validate PAdES signatures, but I have not yet tested it, since I did not yet get such a PDF from someone. While there is a paid license for some features in the product, the free edition does have this feature according to forum posts. You just have to set an option in the settings, that signature validation is done when a document is opened, otherwise you get a notice that at least one signature requires validating.
Thanks for the advice.
Check out PDFArranger
https://github.com/pdfarranger/pdfarranger
based on pikePDF…
I like it because it's modern and cross-platform and it looks on all platform the same (GTK).
Zu 3:
Völlig leere "catch { }" Befehle gibt es 66 Stück.
Es gibt noch weitere 15 leere catch Befehle, wo in der Klammer nur Kommentar-Texte drin stehen, aber keine Anweisungen "best-effort" (mit Sternchen Slash vorne und hinten als Kommentar-Markierungen):
"best-effort cleanup"
"settings are best-effort"
"best-effort; leave the XAML default width"
"best-effort; fall through to normal resize handling"
Also übersetzt "nach bestem Bemühen".
Also insegesamt 81 leere catch-Befehle.
Eventuell kennt der Autor des Programms die Exception-Codes der von ihm benutzten Third-Party Routinen nicht und kann deswegen diese Codes nicht auswerten und lässt deshalb den Catch einfach leer.
Vielleicht gab es bei ihm Compiler-Warnungen, weil er vorher gar keinen catch hatte und hat den dann einfach leer eingefügt, um die Compiler-Warnungen zu unterdrücken.
Die leere catch-Anweisung fängt alle Fehler ab und deswegen wird dann gar kein Fehler mehr angezeigt.
Dann wirkt das Programm "stabiler", weil man ja keine Fehlermeldungen mehr sieht.
Früher waren leere catch-Befehle ein Merkmal für Claude Code etc.
Inzwischen markieren die KI-Tools aber solche leere catch Befehle als Schwachstelle.
Ob es sich um vibe-coding handelt oder um eine Eigenart des Programmierers kann man so nicht beweisen.
Sehr schlechter Programmierstil ist es aber auf jeden Fall.
Logging macht die Datei CrashReporter.cs, sofern dort überhaupt noch Exceptions ankommen und diese nicht bereits durch die 81 leeren catch-Befehle ausradiert worden sind.
> Inzwischen markieren die KI-Tools aber solche leere catch Befehle als Schwachstelle.
Wenn dem mittlerweile so ist, dann ist das gut so. Die Arbeitsfrage ist, was wird von div. KI Werkzeugen by Default weiterhin empfohlen? Und ja allein anhand der leeren Catches kann man das nicht bewerten. Die Summe der Dinge macht es wieder aus. An anderen Ecken (gerade bei WPF UI-seitige) sieht man recht viel manuelle Arbeit, die aber inkonsistent wirken (siehe Kommentierungen und "Magic Numbers", siehe Deine Feststellung mit dem CrashReporter, wo nichts ankommt). Das alles grade dann, wenn alles aus der Hand eines Entwicklers ist.
Es ist meine – gewiss streitbare – Meinung.
Kein Anspruch auf Vollständigkeit oder Allgemeingültigkeit, ich denke den Zuatz muss man aber nicht ständig hinzufügen.
Leider nicht zu gebrauchen, unendliche Fehlermeldungen in diversen Unterpunkten wie OCR und eine essentielle Funktion "send via mail" ist nicht vorhanden…. leider nur ein Speilzeug
Ist zwar nichts technisches zum Programm, m. E. aber auch erwähnenswert (zumindest für Normalsterbliche):
Ich wollte KillerPDF als Reader anstelle des PDF24-Reader nutzen, weil letzterer mir
etwas zu spartanisch (Optik, keine Liste der zuletzt genutzten Dokumente, keine
Änderung der Druck-Einstellungen im Programm selbst) ist. Jetzt habe ich aber fest-
gestellt, dass die Schrift auf dem Ausdruck über KillerPDF viel fetter als über den PDF24-Reader ist.
Habe mir die Software ebenso angeschaut und bin durchaus überascht. Scheinbar ist der Entwickler mehr Außendienstmitarbeiter als Administrator – vor allem wohl von kleineren Umgebungen mit "Einzelkämpfern"?
Ansonsten kann ich mir nicht vorstellen, dass da so standardmäßige Entscheidungen wie Installation nach %LOCALAPPDATA% oder das keine Parameter (Automatisierung, unattended) für die Installation zur Verfügung stehen.
Sollen jedoch bestimmte Entscheidung normaler administrativer Umgebungen (die halt "Lücken" haben können) umgangen werden, dann macht das mit %LOCALAPPDATA% durchaus Sinn. Denn da kann jeder Nutzer die App installieren. Sobald Roaming Profile zum Zug kommen, ist das aber schon wieder weniger ideal. Bei Profildisks, wäre es wieder denkbar.
Ansonsten wundert mich, dass man von Portable spricht, aber dann landen ohne Installation auch automatisch Daten im Nutzerverzeichnis. Teilweise ebenso %LOCALAPPDATA%.
Ansonsten weil es in den Kommentaren angesprochen wurde bzgl. Vibe-Coding… – als ich die GUI gesehen habe, habe ich sofort gedacht, dass kommt von einer KI. So ähnlich bei anderen (Versuchs-) Projekten gesehen. Selbst einem eigenen Versuch hat eine KI sowas als mögliches Ergebnis präsentiert.
Wenn ich zurück zum Hintergrund mit Administrator und Co. hernehme, dann wundert mich, warum man da so ein eigentümliches Design gewählt hat. Idealer wäre breite Standards zu bevorzugen, da dann die Einarbeitungszeit der Nutzer und auch bei Nachfragen der Support leichter fällt… … …