ich wollte ein paar alte Bedienungsanleitungen wegwerfen - schließlich gibt es ja viele davon als PDF vom Hersteller, und auf dem PC sind sie aufgrund der schieren Anzahl besser zu finden als im Aktenschrank.
Etliche Dateien sind allerdings riesig (12 MB für 2 Seiten schwarz-weiß):
Okay - an der Passermarken kann man erkennen, dass die Datei mal für die Druckvorstufe gedacht war. Aber was ist daran so riesig? Und kann man das mit Hausmitteln kleiner bekommen?
(Wenn ich die Papier-Version auf den Scanner lege, habe ich ca. 140 kB)
Die Schriftarten sind eingebettet und Grafiken sind Vektorgrafiken.
Diese Datei ist im Prinzip der Druck-Master in entsprechender Qualität.
Und warum soll daß dann 12MB ergeben?
Solch riesige Dateien gibt eigentlich nur, wenn das im pdf einfach eingebettet gescannte Images von Papieroriginalen sind. Nix Vector, keine Schriften, keine Texte, nur ein TIFF o.ä.
Solch riesige Dateien gibt eigentlich nur, wenn das im pdf einfach
eingebettet gescannte Images von Papieroriginalen sind. Nix Vector,
keine Schriften, keine Texte, nur ein TIFF o.ä.
Es sind keine Images. Das Dokument ist frei verfügbar. Du darfst gerne deine forensische Analyse dazu vorstellen.
Okay - an der Passermarken kann man erkennen, dass die Datei mal für die
Druckvorstufe gedacht war. Aber was ist daran so riesig?
Die Pixelgrafiken in Deinem PDF: Diagramme, Logos, Fotografien und so weiter. Monitore haben üblicherweise zwischen 72 und 100 dpi (dots per inch), in der Druckvorstufe sind 300 dpi üblich. Bei einer sechzehnfachen Menge an Rohdaten hilft auch die beste Komprimierung leider nur teilweise.
die 300dpi sind gewollt recht hoch... gerade bei /prepress könnte man weiter sparen. damit kommen aber schöne PDFs raus die eine erträgliche größe haben.
Update... von 11,9MB wirds damit 3,7MB Groß... da ginge sicher noch viel mehr - mit dem preset ist das aber selbst beim zoom am pc noch scharf... und das ist mir bei dem script wichtig.
Die Pixelgrafiken in Deinem PDF: Diagramme, Logos, Fotografien und so
weiter. Monitore haben üblicherweise zwischen 72 und 100 dpi (dots per
inch), in der Druckvorstufe sind 300 dpi üblich. Bei einer
sechzehnfachen Menge an Rohdaten hilft auch die beste Komprimierung
leider nur teilweise.
Die Größe von mit geeignetem Verfahren komprimierten (echten) Bilder wächst etwa linear mit der Auflösung, nicht quadratisch.
Okay - an der Passermarken kann man erkennen, dass die Datei mal für die
Druckvorstufe gedacht war. Aber was ist daran so riesig?
Die Pixelgrafiken in Deinem PDF: Diagramme, Logos, Fotografien und so
weiter.
Die Pixelgrafiken in diesem PDF sind, wie schon erwähnt, völlig belanglos, das sind nur ein paar Bytes.
Monitore haben üblicherweise zwischen 72 und 100 dpi (dots per
inch), in der Druckvorstufe sind 300 dpi üblich. Bei einer
sechzehnfachen Menge an Rohdaten hilft auch die beste Komprimierung
leider nur teilweise.
Falsch. Hier geht es um Schwarz-Weiß-Text und -Zeichnungen. Wenn man die mit RLE komprimiert, wächst die Größe bei einer Vervierfachung der Auflösung etwa um Faktor 4, nicht Faktor 16. Daß die Rohdaten die 16fache Größe haben, ist belanglos. Die Anzahl der Farbwechsel pro Scanline bleibt gleich, unabhängig von der Auflösung. Es werden nur ein paar Bits mehr für Kodierung der Run Lengths gebraucht, da die Zahlen größer werden.
Ihr trolligen Menschen. Zoom doch einfach mal in Figure 6 rein und zähle
wie viele Linien die Aufschrift auf dem Batteriedeckel hat.
Du hast "Vektorgrafik" nicht verstanden. Da kannst Du beliebig weit (im Rahmen der Fähigkeiten Deines PDF-Anschauers) rein-zoomen und es kommen immer neue Scanlines hinzu.
Es gibt in der Tat eine alternative Erklärung, nämlich die, daß derjenige, der das Dokument mit Adobe Illustrator erstellte, alle Glyphe in Pfade hat umwandeln lassen.
Es gibt in der Tat eine alternative Erklärung, nämlich die, daß
derjenige, der das Dokument mit Adobe Illustrator erstellte, alle Glyphe
in Pfade hat umwandeln lassen
Das Dokument ist nicht gescannt. Das Dokument enthält Verktorgeafiken, die aus einen CAD exportiert wurden.
Es gibt in der Tat eine alternative Erklärung, nämlich die, daß
derjenige, der das Dokument mit Adobe Illustrator erstellte, alle Glyphe
in Pfade hat umwandeln lassen
Das Dokument ist nicht gescannt. Das Dokument enthält Verktorgeafiken,
die aus einen CAD exportiert wurden.
Okay - an der Passermarken kann man erkennen, dass die Datei mal für die
Druckvorstufe gedacht war. Aber was ist daran so riesig? Und kann man
das mit Hausmitteln kleiner bekommen?
Rastergrafiken macht man eben mindestens so hoch aufgelöst, wie es der Drucker kann.
Hausmittel... für ghostscript habe ich oben mein Script hergezeigt, mit dem ich meine Messprotokolle schrumpfe. Da kommen Prüfaufbauten vom Handy fotografiert ins PDF und Ghostscript schrumpft die Auflösung dann passend zur tatsächlichen Größe im PDF.
rein-zoomen und es kommen immer neue Scanlines hinzu.
Nein, offensichtlich hast du es nicht verstanden.
Da habe ich Trottel dich mißverstanden. Ich hatte herausgelesen, daß du behauptest, die Anzahl der Linien sei unbegrenzt. Daher mußte ich davon ausgehen daß du mit "Linie" eine "Scanline" meinst.
Ich habe hier Software, die beliebig tief zoomen kann und auch den zugehörigen Quellcode aus dem Content Stream anzeigen kann, daher könnte ich die Linien exakt zählen, wenn ich wollte.
Das war wohl mal dreidimensional, siehe Ausschnittsvergrößerung.
Aber was ist daran so riesig? Und kann man
das mit Hausmitteln kleiner bekommen?
Ich habe eben mal ein Test gemacht, eine eingescannte
Textseite als GIF gespeichert 444,1 kB. Dann diese Datei
mit LibreOffice in PDF exportiert, hat dann eine Größe
von 458,0 kB. Ist also nicht viel größer geworden.
Eine Grafik ist dann in PDF immer noch eine Grafik.
Pixel belegen eben viel Platz. Man muß daraus mit einer
OCR-Software einen Text machen, dann wird weniger
Speicherplatz belegt.
Ich habe eben mal ein Test gemacht, eine eingescannte
Textseite als GIF gespeichert 444,1 kB. Dann diese Datei
mit LibreOffice in PDF exportiert, hat dann eine Größe
von 458,0 kB.
Man muß daraus mit einer
OCR-Software einen Text machen, dann wird weniger
Speicherplatz belegt.
Im Internet findet man Zeitschriften als pdf, z.B. die c't. Das Heft 3/2026 hat als durchsuchbares pdf 16.1 Mb und steht parallel mit 165.5 Mb da, wo alles als Bild umgewandelt wurde.
Statt jpg ein Bitmap kann auch beachtliche Größen einnehmen. Es gibt viele Möglichkeiten, ein pdf aufzublähen. Man kann z.B. auch Bilder verschiedener Größe einbinden oder eindampfen, exotische Schriftarten mitliefern usw. ...
Ich finde die Frage durchaus berechtigt und ich habe auch keine gute Erklärung dafür.
Es sind keine großen Bitmaps oder Schriften eingebettet.
Wenn ich das einfach als PDF drucke, kommt ein 3.8 MB PDF raus. Auch Fig 6 sieht danach im extrem gezoomten Vergleich absolut gleich aus.
Mein Verdacht, dass da nichts deflate komprimiert wurde, hat sich nicht bestätigt.
Klar kommt das aus der Druckvostufe, da spielt das keine Rolle. Ja es waren Stümper, die das so ins Netz gestellt haben. Aber die Frage warum also "technisch warum" ist damit nicht beantwortet.
Und dann sind da auch noch private Daten von Adobe Illustrator
(page-piece dictionaries) drin. Bin zu faul, das aufzusummieren.
Das wäre durchaus interessant, wie groß die sind...
edit Kann natürlich sein, dass alle Koordinaten im Original mit 20 Nachkommastellen gespeichert wurden und bei mir nach dem Druck nur noch 8 da sind... hinter den deflate streams ist doch reiner Text oder?
Habe diese Datei kurz getestet. Es waren wirklich 12 MB, die sich kaum durch 7z verkleinern ließen. Also bereits komprimierte Daten, erstellt mit Corel PDF Engine Version 14.0.0.701. Wahrscheinlich wirklich für Druck od. andere großflächige Messeanwendungen? Sorry, kleiner Tippfehler im Bild. MB!
Blödsinn oder maximal dann, wenn der Erzeuger des pdf zu dämlich ist.
Ach ja, dann nehme dich mal das Programm, das bei OCR den Bildinhalt entfernt und durch Text ersetzt. Wie sieht das dann aus bei Fehlerkennung?
Ich glaube, da spricht ein Blinder von Farben.
Bei OCR in einem PDF werden die erkannten Buchstaben hinter dir Grafik
gelegt. Das Ergebnis ist eine größere Datei.
Bei einem Byte pro Zeichen explodiert die Dateigröße dann natürlich
extrem.
Oliver
Was an größer verstehst du nicht? Niemand außer dir spricht von explodieren. Und 1 Byte pro Zeichen ist ein bisschen wenig oder lebst du in der IT-Steinzeit?
Bei einem Byte pro Zeichen explodiert die Dateigröße dann natürlich
extrem.
Oliver
Was an größer verstehst du nicht?
Hier in diesem Thread gehts um mehrer MB. Was interessiert da Kleimkram?
Niemand außer dir spricht von
explodieren. Und 1 Byte pro Zeichen ist ein bisschen wenig oder lebst du
in der IT-Steinzeit?
Mach mal eine statistische Analyse der Texte in englischsprachigen pdfs, um die es hier geht. Was meinst du wohl, was da als Durchschnittsbytegröße pro Zeichen rauskommt. UTF8 ist halt erst einmal ASCII, und die paar Sonderzeichen, die mehr als ein Byte brauchen, gehen in der Masse unter.
Besorge er sich eine Demo-Version von Adobe Acrobat Pro oder Callas PDF Toolbox. Damit kann man das PDF techisch bis ins Detail sezieren und du erfährst, warum das so groß ist.
PDF ist ein objektorienterter hierarchisch aufgebauter Container, der Fonts, ICC-Farbprofile, Texte, Vektor- und Pixelgrafik u.v.a enthalten kann. Meist sind übermäßig hoch aufgelöste oder verrauschte Pixelgrafiken der Übeltäter, wenn die Datei zu groß wird.
Aber: PDF bettet Pixelgrafiken nicht einfach im Originalformat ein, sondern wandelt sie beim Import in einen eigenen Datenstrom mit ZIP- oder JPEG-Kompression um. Der "Kompressions-Erfolg" hängt in hohem Maße von der Entropie ab und die wird bei Bilden maßgeblich vom Rauschen beeinflusst. D.h. ein verrausches Bild lässt sich deutlich schlechter komprimieren als ein "glattes", was z.B. bei optimalen Lichtverhältnissen erstellt wurde ...
UTF8 ist halt erst einmal ASCII, und die paar Sonderzeichen, die mehr
als ein Byte brauchen, gehen in der Masse unter.
Die Aussage ist auch einfach falsch. Braucht man nicht Diskutieren.
Die Ursache habe ich ganz oben erläutert, aber Oliver labert trotzdem
weiter Quak.
Nein, sie ist nicht (komplett) falsch. UTF-8 heisst so, weil die Standardzeichen mit 8 Bit codiert werden, wie bei ASCII. Lediglich den Sonderzeichen werden quasi "Umschaltcodes" vorangestellt.
Dass sieht man z.B daran, dass wenn man mal Text in UTF-8-Codierung als ASCII öffnet, alle Zeichen, ausser den Sonderzeichen, ganz normal zu lesen sind. Anstelle der Sonderzeichen sieht man immer zwei "Kryptos", den Umschalt-Code und den Code für das eigentliche Zeichen, die im ASCII-Umfeld natürlich "befremdlich" aussehen ...
Nein, sie ist nicht (komplett) falsch. UTF-8 heisst so, weil die
Standardzeichen mit 8 Bit codiert werden, wie bei ASCII
Es ist falsch, da in dem Dokument u.a. chinesische Zeichen sind. Was soll dieses schwachsinnige diskutieren? Dabei war fast im Tor? War er aber nicht! Ende.
Mach mal eine statistische Analyse der Texte in englischsprachigen pdfs,
um die es hier geht. Was meinst du wohl, was da als
Durchschnittsbytegröße pro Zeichen rauskommt. UTF8 ist halt erst einmal
ASCII, und die paar Sonderzeichen, die mehr als ein Byte brauchen, gehen
in der Masse unter.
Das Dokument, um das es hier geht, ist aber PDF 1.6, da kann UTF-8 gar nicht verwendet werden. Wohl aber UTF-16.
Nein, sie ist nicht (komplett) falsch. UTF-8 heisst so, weil die
Standardzeichen mit 8 Bit codiert werden, wie bei ASCII. Lediglich den
Sonderzeichen werden quasi "Umschaltcodes" vorangestellt.
Nein, in UTF-8 gibt es weder "Umschaltcodes" noch quasi solche. Shift-JIS hingegen hat Umschaltcodes (nicht nur quasi) und kann schon länger in PDF verwendet werden. Ist aber zugunsten von UTF-16 aus der Mode gekommen. UTF-8 geht seit PDF 2.0.
Es geht im vorliegenden Fall aber nicht um Pixelgrafik, es geht um
Vektorgrafik. Und die Vektorgrafik hat sehr viele Vektoren.
Hat sie das?
Ich habe auf der Arbeit pdfs mit „sehr vielen“ Vektoren. Das sind umgewandelte 2D-CAD-Zeichnungen, wofür der Konverter halt Murks ist.
Das „sehr viele“ erkennt man daran, daß der Bildaufbau im Acrobat Reader erkennbar lange dauert. Man kann dem Aufbau des Bildes Linie für Linie zuschauen.
Es geht im vorliegenden Fall aber nicht um Pixelgrafik, es geht um
Vektorgrafik. Und die Vektorgrafik hat sehr viele Vektoren.
Hat sie das?
Wenn ich mich recht erinniere (ich habe gerade keinen Zugriff aufs Werkzeug): allein die zweite Seite hat etwa 450000 Pfade, wobei jeder Pfad aus mehreren Vektoren und Bögen besteht. Vielleicht täuscht die Erinnerung und es sind "nur" 45000. Morgen kann ich genau nachschauen.
Die Datei des TO hat nur ein paar Vektoren.
Oliver
Oh bitte, extrahiere doch mal den Datenstream und laber nicht rum. Wo die zu finden sind im pdf habe ich auch schon beschreiben. Hättest du es verstanden, hättest du nicht den dummen 2d Vergleich gebracht.
Natürlich trog mein Gedächtnis. Habe nachgezählt: Für beide Seiten zusammen 134671 l-Operatoren (lineto),184168 c-Operatoren (curveto) und 3223 re-Operatoren (Rechtecke). Dazu kommen möglicherweise ein paar lineto, die durch das Schließen der Pfade durch Fülloperatoren entstehen.
Man kann übrigens recht einfach mit pdftk die Streams einer PDF-Datei dekomprimieren, dann kann man mit einem gewöhnlichen Texteditor nachsehen.
Ich habe eben mal ein Test gemacht, eine eingescannte Textseite als GIF
gespeichert 444,1 kB. Dann diese Datei mit LibreOffice in PDF exportiert,
hat dann eine Größe von 458,0 kB. Ist also nicht viel größer geworden.
Wenn man schon beim Einscannen solche banalen Fehler macht, weil man nicht weiß für was GIF-Dateien gedacht sind, oder welchen Platz die ggn. über TIFF oder PNG brauchen, dann kann man alles weitere von dir probierte unter den gleichen Status Bastelei durch Versuch und Irrung einstufen.
Text als Bild in eine PDF- oder Word-Datei ist schon mal Nonsens hoch 5, wenn man sie nicht gleich mit OCR Texterkennung einscannt.
Noch dazu scannt man das mit extra Einstellungen am Gerät auf sw/ws Text und nicht als Bild, bei ca. 450 kB Dateigröße für 1 Seite ohne Grafik war das welche Auflösung? Wenn man so eine Zeitschrift wie die c't mit über mehr als 50 Seiten so scannen würde, wären das schon ohne Bilder dann 25 MB.
Den Test kannst du damit also vergessen, ich habe eine A4 TextSeite mit ca. 45 kB in png in ein OO-Writer-Dokument eingefügt als Bild, da war diese Datei dann ca 62 kB groß, durch Umwandeln oder Exportieren in ein pdf dann aber nur noch 35 kB. Ob das Sinn macht sei dahingestellt, man kann darin dann nicht mehr nach Wörtern suchen. Bilder kann man aber auch gleich über die Druckfunktion in ein PDF umwandeln, auch wenn das wieder wenig Sinn macht, wie man ja hier im Forum oft erkennt.
Zum eigentlichen Thema wird die Original-PDF-Datei wohl nicht mal zum Beschauen gebracht?
Wenn man schon beim Einscannen solche banalen Fehler macht, weil man
nicht weiß für was GIF-Dateien gedacht sind, oder welchen Platz die ggn.
über TIFF oder PNG brauchen
Was ost das für ein Schwachsinn? GIF ist die logische Weiterentwicklung von PNG und TIFF kann alles und nichts sein.
Was ost das für ein Schwachsinn? GIF ist die logische Weiterentwicklung
von PNG und TIFF kann alles und nichts sein.
Nein, GIF ist keine Weiterentwiclung von PNG. Schon gar keine logische. PNG entstand lange nach GIF. Ich werde mich nicht auf dein Niveau hinabbegeben und daher diese Gelegenheit nicht für eine Retourkutsche für eine deiner obigen Beleidungen benutzen.
Text als Bild in eine PDF- oder Word-Datei ist schon mal Nonsens hoch 5,
wenn man sie nicht gleich mit OCR Texterkennung einscannt.
Muß man nicht. Nicht jeder hat einen Scanner mit OCR wenn der
schon etwas älter ist. Und wenn man keine OCR-Software auf
seinen Computer hat, gibt es auch noch Online-OCR.
Eine Buchseite in GIF eingescannt, 436 kB.
Dann mit OnlineOCR in TXT umgewandelt 5,6kB.
Dann nachbearbeiten, ab und zu sind mal ein paar
Buchstaben bei, die nicht richtig erkannt wurden.
Dann nachbearbeiten mit LibreOffice, Schriftbild,
Fettdruckzeilen, Kursiveschriftzeilen, daß macht
ja OCR auch nicht. Ich weis nicht, ob es schon
OCR-Software gibt, die sowas kann.
Dann exportieren in PDF, 16,2kB.
Vielleicht auch noch in ODT speichern, 24 kB.
Also es ist möglich PDF-Dateien selber anzufertigen,
die nicht riesig sind.
Eine Buchseite in GIF eingescannt, 436 kB.
Dann mit OnlineOCR in TXT umgewandelt 5,6kB.
Dann nachbearbeiten, ab und zu sind mal ein paar
Buchstaben bei, die nicht richtig erkannt wurden.
Dann nachbearbeiten mit LibreOffice, Schriftbild,
Fettdruckzeilen, Kursiveschriftzeilen, daß macht
ja OCR auch nicht.
Wieviel € müsste ein MB Speicher kosten, dass sich der Aufwand für einen Westeuropäer lohnen könnte?
Dann exportieren in PDF, 16,2kB.
Vielleicht auch noch in ODT speichern, 24 kB.
Also es ist möglich PDF-Dateien selber anzufertigen,
die nicht riesig sind.
Warum nicht gleich abtippen? Geht bestimmt schneller.
Wie immer: Nur, wenn der Ersteller seinen Job versteht und auf die
Datenmenge achtet.
Die wenigsten Ersteller von PDF werden umgekehrt proportional zur Datenmenge bezahlt. Das PDF wurde offensichtlich für den Austausch mit der Druckerei erzeugt und für Leute die den Druck verlegt haben online gestellt.
Wieviel € müsste ein MB Speicher kosten, dass sich der Aufwand für einen
Westeuropäer lohnen könnte?
Manchmal kommt man um den Aufwand nicht drum rum, auch
wenn die MB noch so billig sind. Zum Beispiel wenn
man mit ältere Mikrocontroller experimentiert und
die Assemblerprogramme aus Zeitschriften braucht.
Der Assembler kann mit GIF TIF und PNG nichts anfangen,
der braucht TXT.
Zum Beispiel wenn
man mit ältere Mikrocontroller experimentiert und
die Assemblerprogramme aus Zeitschriften braucht.
Der braucht ein minimal kleines pdf mit korrektem Satz von kursiv und fett? Ich glaube nicht. Da reicht es das PDF in Graustufen zu scannen und OCR drüber laufen zu lassen. Am besten macht das sicher die KI und nicht Writer oder Word.
Shift-JIS hingegen hat Umschaltcodes (nicht nur quasi) und kann schon
länger in PDF verwendet werden. Ist aber zugunsten von UTF-16 aus der
Mode gekommen. UTF-8 geht seit PDF 2.0.
Ich hab gerade mal geguckt, wie bei mir die Zeichen codiert werden... keine Ahnung wie, aber bei PDF1.5 wird bei mir nur 1 Byte pro (normalem) Zeichen verwendet. ä wird dagegen z.B. als \344 kodiert. War jetzt der Export von Inkscape (PDF 1.5).
Scribus ... keine Ahnung. Ich finde den Text im (dekomprimierten) PDF nicht wieder.
Der Drucken Dialog in Firefox speichert ASCII Buchstaben auch mit einem Byte (PDF 1.7).
Weil Text eigentlich immer als FlateDecode stream gespeichert wird, sind real also durchaus <1 Byte pro Zeichen möglich. Wahrscheinlich sind es meistens aber dennoch mehr, weil noch viel drumherum mitgespeichert wird. Positionierung, Kerning und so. Nur in absoluten Trivialfällen konnte ich <=1 Byte pro extra Zeichen hinbekommen.
Das produziert bei mir ein ähnlich großes PDF (3.7MB) wie einfach als PDF drucken (3.6MB). Tatsächlich sind bei 10.000% Vergrößerung beim einfachen Drucken doch geringe Rundungsfehler sichtbar. Dein gs Befehl erzeugt ein PDF, das auch bei 10k% alle Linien noch exakt am gleichen Platz hat. Dennoch sind minimale Unterschiede im Antialiasing der Haarlinien sichtbar.
Für mich ist die Frage immernoch nicht ganz beantwortet. Sind das jetzt 8MB praktisch unnütze Nachkommastellen oder woher kommt der Unterschied?
edit
Re D. schrieb im Beitrag #8009342:
Entschuldige, ich habe es falsch herum getippt. PNG ist die logische
Weiterentwicklung von GIF.
Na ja auch nicht ganz. Animation fehlt (in den meisten Implementationen) und es gibt zwei konkurrierende Standards.
es gibt durchaus APNG und MNG. APNG wird (entgegen meiner
geradigen Aussage) inzwischen von 96% der Browser unterstützt.
Dann zeig mal bitte solche Bilddateien, die habe ich noch nirgends gesehen.
Jpg wird nach pip in manchen Browsern geändert, die neuesten Bildformate sind webp, die können auch gif-Funktionen als bewegte Bildinhalte als wäre es ein Video.
Ahnungsloser Quark, Gif hat Fähigkeiten die PNG nicht hat, oder schon
mal animierte Grafiken, also bewegte Bilder, als PNG gesehen? super
Leuchte
Du bist die Leuchte. Zu der Zeit als PNG entwickelt wurde, war es logisch für bewegte Bilder andere Formate zu nutzen. Du scheinst nicht zu wissen, dass sowohl PNG als auch GIF hauptsächlich Bilder darstellen. Und nach gleichen Prinzipien Arbeiten (Farbtabelle, verlustfreie Kompression arbeiten. Eigentor!
Der braucht ein minimal kleines pdf mit korrektem Satz von kursiv und
fett? Ich glaube nicht. Da reicht es das PDF in Graustufen zu scannen
und OCR drüber laufen zu lassen. Am besten macht das sicher die KI und
nicht Writer oder Word.
Was quasselst du eigentlich für einen Unsinn, ein pdf in einen µC reinladen?
Das war es nun wonach man dich hier als unfähigen Troll einstufen kann.
Mit tiff oder png hast du es nicht versucht, was dabei für Dateigrößen und Qualität dabei rumkommt? Bei Gif meckert doch schon Paint dass man das sich vorher überlegt > Beim Speichern in diesem Format kann es zum Verlust von Farbinformationen kommen < bei reinem Text eigentlich egal oder gar der Vorteil. Ich habe jetzt über Paint das PNG Text-Bild nach unter GIF gespeichert, da belegt es statt der 45 kB nun 68 kB, also kann es das nicht ganz sein. Das müsste man dann noch mal mit einem Scanner versuchen, das war aber glaube ich genau der Punkt warum man gif dafür nicht nimmt. Als Tiff Datei werden es auch wieder mehr, nämlich 58 kB.
Mit tiff oder png hast du es nicht versucht, was dabei für Dateigrößen
und Qualität dabei rumkommt?
Qualität kommt das rum, was man vorher einstellt. Aber das blickst du scheinbar nicht. Es hat aber auch überhaupt nichts mit der ursprünglichen Fragestellung zu tun.
Jpg wird nach pip in manchen Browsern geändert, die neuesten Bildformate
sind webp, die können auch gif-Funktionen als bewegte Bildinhalte als
wäre es ein Video.
webp ist lange nicht mehr das neueste. avif wird inzwischen von jedem Browser unterstützt. Jpeg-XL steht jetzt tatsächlich doch wieder vor der Tür.
Was meinst du mit zwei Standards? Animationen brauchte man zur Zeit von
PNG nicht, das ist nur logisch dass es entfallen ist
MNG wurde von der PNG Development group 2001 veröffentlicht, fand aber praktisch keinen Anklang. APNG wurde 2004 von Mozilla veröffentlicht und wird inzwischen in jedem Browser unterstützt.
Die Größe von PDF-Dateien ist vor allem deshalb interessant, weil sie in die Ladezeit und Blätterdauer eingeht. Und in die Zeit, bis in einem Verzeichnis alle Thumbnails sichtbar sind; die einem helfen, die richtige Datei überhaupt zu finden.
Ich hab gerade mal geguckt, wie bei mir die Zeichen codiert werden...
keine Ahnung wie, aber bei PDF1.5 wird bei mir nur 1 Byte pro (normalem)
Zeichen verwendet. ä wird dagegen z.B. als \344 kodiert. War jetzt der
Export von Inkscape (PDF 1.5).
344 oktal für ä ist wahrscheinlich WinAnsiEncoding. Man kann aber in PDF fast beliebige Codierungen definieren, z.B. um naive Textextraktions-Software zu verwirren. Der Weg vom Zeichencode im Show String zum Glyphen in der Schrift ist ziemlich komplex.
Die Größe von PDF-Dateien ist vor allem deshalb interessant, weil sie in
die Ladezeit und Blätterdauer eingeht.
Dafür gibt es Linearized PDF. Damit kann z.B. die erste Seite angzeigt werden, bevor die ganze PDF-Datei heruntergeladen wurde. Auch sollte man es vermeiden, alle Objekte in einen einzigen großen Object Stream (einer für alle Seiten) zu packen. Das richtig zu machen, ist wichtiger als die reine Dateigröße.
Der PDFs nur mit Vorschaubildchen findet, dem ist wohl nicht mehr zu
helfen.
Apropos Vorschaubildchen: Das Dokument, um das es hier geht, enthält RLE-komprimierte 8-Bit-Indexed-Vorschaubildchen, eines pro Seite. Die hatte ich bisher nicht explizit erwähnt, weil sie sehr klein sind (128x96 Pixel WIMRE). Die sind aber nur für Adobe Illustrator.
MNG wurde von der PNG Development group 2001 veröffentlicht, fand aber
praktisch keinen Anklang. APNG wurde 2004 von Mozilla veröffentlicht und
wird inzwischen in jedem Browser unterstützt.
APNG ist seit ein paar Monaten offiziell in PNG drin.
Zurück zum Thema: Hier noch zwei Werkzeuge zum Reinschauen in PDF:
Bei einer Anleitung hatte ich gefühlte hundert Seiten an Warnhinweisen bevor die eigentliche Gerätebeschreibung und Bedienungsanleitung begann.
Eine pdf kann sehr lange werden. Wenn bei einer Smartwatch die gedruckte Anleitung im Umfang eines Telefonbuches der Stadt München beigelegt werden müßte, jeder hier dem Gesetzgeber, der dies verlangt hätte, einen V....(gelöscht) zeigen.
