Discussion:
Unnötige eingebettete Schriften entfernen, Codierung erhalten
(zu alt für eine Antwort)
Tilmann Reh
2015-10-20 06:07:11 UTC
Permalink
Guten Morgen,

ich bekomme immer wieder PDFs, bei denen unnötigerweise etliche
Schriften vollständig mit eingebettet sind - und die dadurch mehr als
zehnmal so groß sind wie sie sein müßten (einseitiger Text z.B. 175k
statt 16k).

Wenn ich diese Dateien mit PDFCreator "drucke", ohne die Schriften
einzubetten, ist der ganze Wasserkopf weg - aber dann werden im Dokument
anstelle der Umlaute irgendwelche anderen Zeichen angegeben - offenbar
verwenden die eingebetteten Schriften irgendwelche abweichenden
Zeichentabellen. :-(
In den Dokumenteigenschaften zeigt der Adobe Reader z.B. die Schriften
Arial und Arial Bold jeweils mit "Kodierung: Mitgeliefert", daneben aber
auch Arial Italic mit "Kodierung: Standard".

Gibt es eine (frei verfügbare) Möglichkeit, von den eingebetteten
Schriften nur die "unnötigen" Inhalte zu löschen oder die
"mitgelieferte" Codierung zu erhalten (oder auf "Standard" zu ändern")?

Ich weiß, daß das eigentlich an der Quelle am einfachsten behoben werden
könnte, aber darauf habe ich leider keinen Einfluß... :-(

Danke,
Tilmann
tlvp
2015-10-20 19:06:44 UTC
Permalink
Post by Tilmann Reh
Guten Morgen,
ich bekomme immer wieder PDFs, bei denen unnötigerweise etliche
Schriften vollständig mit eingebettet sind - und die dadurch mehr als
zehnmal so groß sind wie sie sein müßten (einseitiger Text z.B. 175k
statt 16k).
Wenn ich diese Dateien mit PDFCreator "drucke", ohne die Schriften
einzubetten, ist der ganze Wasserkopf weg - aber dann werden im Dokument
anstelle der Umlaute irgendwelche anderen Zeichen angegeben - offenbar
verwenden die eingebetteten Schriften irgendwelche abweichenden
Zeichentabellen. :-(
In den Dokumenteigenschaften zeigt der Adobe Reader z.B. die Schriften
Arial und Arial Bold jeweils mit "Kodierung: Mitgeliefert", daneben aber
auch Arial Italic mit "Kodierung: Standard".
Gibt es eine (frei verfügbare) Möglichkeit, von den eingebetteten
Schriften nur die "unnötigen" Inhalte zu löschen oder die
"mitgelieferte" Codierung zu erhalten (oder auf "Standard" zu ändern")?
Ich weiß, daß das eigentlich an der Quelle am einfachsten behoben werden
könnte, aber darauf habe ich leider keinen Einfluß... :-(
Danke,
Tilmann
Anstatt mindestens froh zu sein dass es als Text und nicht als Grafik
angekommen ist ... :-) . Tschuess, -- tlvp
--
Avant de repondre, jeter la poubelle, SVP.
Tilmann Reh
2015-10-21 06:00:41 UTC
Permalink
Post by tlvp
Anstatt mindestens froh zu sein dass es als Text und nicht als Grafik
angekommen ist ... :-) . Tschuess, -- tlvp
Im Ernst: früher [tm] kamen diese Dokumente als Fax. Die PDFs aus
Fritz-Fax waren - trotz Vollgrafik - erheblich kleiner als die Bläh-PDFs
heute. (Und mit ca. 20k nur wenig größer als die geschrumpften PDFs.)

Ich bin trotzdem weiter an einer "optimalen" Lösung interessiert...

Tilmann
Wilfried
2015-10-21 12:37:33 UTC
Permalink
Post by Tilmann Reh
Post by tlvp
Anstatt mindestens froh zu sein dass es als Text und nicht als Grafik
angekommen ist ... :-) . Tschuess, -- tlvp
Im Ernst: früher [tm] kamen diese Dokumente als Fax. Die PDFs aus
Fritz-Fax waren - trotz Vollgrafik - erheblich kleiner als die Bläh-PDFs
heute. (Und mit ca. 20k nur wenig größer als die geschrumpften PDFs.)
Ich bin trotzdem weiter an einer "optimalen" Lösung interessiert...
Aus den Header-Zeilen Deines Postings schließe ich dass Du ein
Windows-System benutzt.

Hast Du mal PDF-XChange Editor ausprobiert?
Da gibt es einen Befehl
"Datei" "optimierte Kopie speichern"
und unter den Optionen gibt es
"Eingebettete Schriftarten entfernen" mit der Default-Einstellung, dass
nur die Standard-Schriftarten entfernt werden, die auf jedem System
vorhanden sein müssten, und - vielleicht für Dich interessant -:
"Schriftart-Teilmengen verschmelzen"

Eine Optimierung soll auch mit der Acrobat Vollversion (die ich nicht
habe und deshalb nicht ausprobieren kann) möglich sein, wenn man bei
"Speichern unter" den Dateityp "Adobe PDF Optimiert" (oder so ähnlich)
wählt.

Schließlich soll eine gewisse Optimierung auch mit Ghostscript möglich
sein, siehe
http://stackoverflow.com/questions/10450120/optimize-pdf-files-with-ghostscript-or-other

Zitat von vorgenannter Webseite:
gs \
-o output.pdf \
[...other options...] \
-dEmbedAllFonts=false \
-dSubsetFonts=true \
-dConvertCMYKImagesToRGB=true \
-dCompressFonts=true \
-c ".setpdfwrite <</AlwaysEmbed [ ]>> setdistillerparams" \
-c ".setpdfwrite <</NeverEmbed [/Courier /Courier-Bold /Courier-Oblique \
/Courier-BoldOblique /Helvetica /Helvetica-Bold /Helvetica-Oblique \
/Helvetica-BoldOblique /Times-Roman /Times-Bold /Times-Italic \
/Times-BoldItalic /Symbol /ZapfDingbats /Arial]>> setdistillerparams" \
-f input.pdf

Grüße
--
Wilfried Hennings
bitte in der Newsgruppe antworten, die Mailadresse ist ungültig
Tilmann Reh
2015-10-22 08:30:37 UTC
Permalink
Post by Wilfried
Aus den Header-Zeilen Deines Postings schließe ich dass Du ein
Windows-System benutzt.
Richtig. Sorry, hätte ich erwähnen können.
Post by Wilfried
Hast Du mal PDF-XChange Editor ausprobiert?
Da gibt es einen Befehl
"Datei" "optimierte Kopie speichern"
und unter den Optionen gibt es
"Eingebettete Schriftarten entfernen" mit der Default-Einstellung, dass
nur die Standard-Schriftarten entfernt werden, die auf jedem System
"Schriftart-Teilmengen verschmelzen"
Danke für den Hinweis - den hatte ich bisher noch nicht ausprobiert.

Allerdings:
- trotz ausdrücklicher Anweisung, die Schriften zu entfernen, sind sie
in der ausgegebenen Datei immer noch drin. :-(
- natürlich ist das "Optimieren" eine PRO-Funktion und damit nicht im
kostenlosen Funktionsumfang (OK, wenn sie wenigstens funktionieren
würde, könnte man trotzdem drüber nachdenken, das Programm ist ja
wenigstens nicht teuer).

Ich werde die vielleicht mal anmailen...
Post by Wilfried
Eine Optimierung soll auch mit der Acrobat Vollversion (die ich nicht
habe und deshalb nicht ausprobieren kann) möglich sein, wenn man bei
"Speichern unter" den Dateityp "Adobe PDF Optimiert" (oder so ähnlich)
wählt.
Acrobat habe ich nicht - ist dafür auch etwas teuer...
Post by Wilfried
Schließlich soll eine gewisse Optimierung auch mit Ghostscript möglich
sein, siehe
http://stackoverflow.com/questions/10450120/optimize-pdf-files-with-ghostscript-or-other
Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
bricht dann ab.
Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
angegeben ist oder beide.

Lasse ich testhalber beide weg, läuft GS ohne Fehlermeldung durch und
bearbeitet laut Konsolenausgabe angeblich die eine Dokumentenseite, aber
ich finde anschließend nirgends die gewünschte Ausgabedatei (die ich
natürlich sicherheitshalber auch mit vollständigem Pfad angegeben habe).

Es ist zum fortlaufen. :-(

Danke trotzdem.

Tilmanm
Christian Zietz
2015-10-23 06:20:22 UTC
Permalink
Post by Tilmann Reh
Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
bricht dann ab.
Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
angegeben ist oder beide.
Das spricht dafür, dass Du an der Stelle an der "[...other options...]"
steht, eben nicht die anderen benötigten Optionen, insbesondere
-sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
*nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
der im Beispiel "[...other options...]" steht.

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA
Tilmann Reh
2015-10-23 07:09:40 UTC
Permalink
Post by Christian Zietz
Post by Tilmann Reh
Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
bricht dann ab.
Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
angegeben ist oder beide.
Das spricht dafür, dass Du an der Stelle an der "[...other options...]"
steht, eben nicht die anderen benötigten Optionen, insbesondere
-sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
*nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
der im Beispiel "[...other options...]" steht.
Ich ahnte nicht, daß eine an dieser Stelle zwingend notwendige Option
hier nicht genannt war - und dachte bei "other options" an Dinge, die
man "sonst noch so" hätte einstellen können.

Mit der Angabe von -sDEVICE=pdfwrite wird nun tatsächlich eine
Ausgabedatei erzeugt.
ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut Adobe
Reader als "Eingebettete Untergruppe", genau wie beim Original), obwohl
ich sie definitiv in der Never-Embed-Liste stehen habe. Allerdings
schrumpft die Datei von 174k auf 67k - die Größe ist aber bis aufs Byte
exakt gleich, egal ob die Arial-Schriften in der Never-Embed-Liste
stehen oder nicht...
Post by Christian Zietz
20.10.2015 07:50 174.624 input.pdf
23.10.2015 08:40 67.926 output.pdf
name type emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
AOEUOL+Arial CID TrueType yes yes yes 8 0
IWUSEV+Arial,Bold CID TrueType yes yes yes 9 0
RMHACJ+Arial,Italic CID TrueType yes yes yes 12 0
name type emb sub uni object ID
------------------------------------ ----------------- --- --- --- ---------
XMZYYF+Arial,Italic CID TrueType yes yes yes 22 0
OWDJRV+Arial,Bold CID TrueType yes yes yes 18 0
UHSVOA+Arial CID TrueType yes yes yes 14 0
Das ist wirklich alles merkwürdig. :-\

Tilmann
Thomas Kaiser
2015-10-23 09:54:02 UTC
Permalink
Post by Tilmann Reh
ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut Adobe
Reader als "Eingebettete Untergruppe", genau wie beim Original),
obwohl ich sie definitiv in der Never-Embed-Liste stehen habe.
Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"? Falls
Letzteres, dann deutet meine Frage jetzt evtl. schon auf die Problematik
-- Font-Subsetting, also Untergruppe nicht mit vollständigem sondern
benutzerdefiniertem Zeichenvorrat/-Encoding -- hin?

Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
vorher, weil die Glyphen-Zuordnung im Eimer ist.

Gruss,

Thomas
Tilmann Reh
2015-10-23 12:05:54 UTC
Permalink
Post by Thomas Kaiser
Post by Tilmann Reh
ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut Adobe
Reader als "Eingebettete Untergruppe", genau wie beim Original),
obwohl ich sie definitiv in der Never-Embed-Liste stehen habe.
Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
Das stand in dem Teil, den Du weggeschnitten hast...

Adobe Reader zeigt unter "Eigenschaften/Schriften" in allen Fällen nur
"Arial" etc., niemals die vorangestellten Buchstaben wie pdffonts.exe.
Post by Thomas Kaiser
Falls
Letzteres, dann deutet meine Frage jetzt evtl. schon auf die Problematik
-- Font-Subsetting, also Untergruppe nicht mit vollständigem sondern
benutzerdefiniertem Zeichenvorrat/-Encoding -- hin?
Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
vorher, weil die Glyphen-Zuordnung im Eimer ist.
Näheres dazu hatte ich im OP geschrieben.

Offenbar verwenden die Original-PDFs irgendeine "spezielle" Codierung
oder Zuordnung. Nach dem vollständigen Entfernen der eingebetteten
Schriften ist der größte Teil des Textes einwandfrei, nur ein paar
Sonderzeichen und die Umlaute werden nicht mehr korrekt angezeigt -
stattdessen erscheinen irgendwelche anderen Zeichen.

Am schönsten wäre es, wenn man die Codierung im PDF auf "Standard"
zurechtbiegen könnte - alternativ dürfen meinetwegen die paar nicht der
Standardcodierung entsprechenden Zeichen weiterhin als "eingebettete
Untergruppe" im Dokument bleiben. Aber eben nicht das ganze Alphabet in
drei verschiedenen Schriften.

Tilmann
Thomas Kaiser
2015-10-23 13:55:31 UTC
Permalink
Post by Tilmann Reh
Post by Thomas Kaiser
Post by Tilmann Reh
ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut
Adobe Reader als "Eingebettete Untergruppe", genau wie beim
Original), obwohl ich sie definitiv in der Never-Embed-Liste stehen
habe.
Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
Das stand in dem Teil, den Du weggeschnitten hast...
Ach ja, Dein "Nachtrag" mit der Kommandozeile. Da stand halt "Arial" und
nicht der Schriftname, der im PDF verwendet wurde.
Post by Tilmann Reh
Adobe Reader zeigt unter "Eigenschaften/Schriften" in allen Fällen nur
"Arial" etc., niemals die vorangestellten Buchstaben wie pdffonts.exe.
Und jetzt? Der Reader kennt halt auch die Konvention mancher PDF-
Erzeuger, wie die Font-Subsets benennen und zeigt nicht den
Originalnamen sondern den Namen des Fonts, auf dem das Subset basiert,
an.
Post by Tilmann Reh
Näheres dazu hatte ich im OP geschrieben.
Na, dann.
Post by Tilmann Reh
Offenbar verwenden die Original-PDFs irgendeine "spezielle" Codierung
oder Zuordnung.
"Speziell"? Wie schon versucht zu erläutern gibt es diverse Standard-
Encodings und bei Untergruppen in jedem Fall Custom Encoding. Ich
verstehe ja nach wie vor nicht, warum Du so ein Gewese mit der Herkunft
der PDFs machst. Poste doch mal die Ausgabe von pdfinfo.exe -- aktuell
vermute ich stark, dass es bei Producer "Mac OS X ... Quartz PDFContext"
stehen dürfte (Font-Untergruppen, Truetype/CID und Unicode, wo's nur
irgend geht -- das riecht zumindest nach Apple)
Post by Tilmann Reh
Nach dem vollständigen Entfernen der eingebetteten Schriften ist der
größte Teil des Textes einwandfrei, nur ein paar Sonderzeichen und die
Umlaute werden nicht mehr korrekt angezeigt - stattdessen erscheinen
irgendwelche anderen Zeichen.
Ja mei, das klappt natürlich nicht, einen Zeichenvorrat, der in Unicode
beschrieben ist, als WinAnsi zu interpretieren.
Post by Tilmann Reh
Am schönsten wäre es, wenn man die Codierung im PDF auf "Standard"
zurechtbiegen könnte
Die ist Standard. Weil weder Windows noch dort gebräuchliche und sehr
beschränkte Gammel-Encodings wie das dort übliche ANSI (basiert AFAIK
auf ANSI 1252) sind die _einzigen_ Standards. Es gibt durchaus zeit-
gemäße wie die auf Unicode basierenden.

Gruss,

Thomas
Tilmann Reh
2015-10-23 14:34:34 UTC
Permalink
Post by Thomas Kaiser
Post by Tilmann Reh
Post by Thomas Kaiser
Post by Tilmann Reh
ABER: Diese enthält immer noch alle drei Fonts eingebettet (laut
Adobe Reader als "Eingebettete Untergruppe", genau wie beim
Original), obwohl ich sie definitiv in der Never-Embed-Liste stehen
habe.
Was hast Du da drin stehen? "AOEUOL+Arial" oder "Arial"?
Das stand in dem Teil, den Du weggeschnitten hast...
Ach ja, Dein "Nachtrag" mit der Kommandozeile. Da stand halt "Arial" und
nicht der Schriftname, der im PDF verwendet wurde.
Ich hatte Deine Frage anders verstanden und nicht auf meine
Kommandozeile bezogen.

Also müßte ich zum Entfernen konkret "AOEUOL+Arial" in der
Never-Embed-Liste für GS angeben? (Gibt es einklich dafür keine
Wildcards? Also so, daß einfach *alles* entfernt wird?)
Post by Thomas Kaiser
Post by Tilmann Reh
Adobe Reader zeigt unter "Eigenschaften/Schriften" in allen Fällen nur
"Arial" etc., niemals die vorangestellten Buchstaben wie pdffonts.exe.
Und jetzt? Der Reader kennt halt auch die Konvention mancher PDF-
Erzeuger, wie die Font-Subsets benennen und zeigt nicht den
Originalnamen sondern den Namen des Fonts, auf dem das Subset basiert,
an.
Das hilft mir als "normalem Anwender" aber leider nicht weiter. Ich sehe
dort eben "Arial" und halte das (offenbar fälschlicherweise...) für
"Arial". :-\
Post by Thomas Kaiser
Post by Tilmann Reh
Offenbar verwenden die Original-PDFs irgendeine "spezielle" Codierung
oder Zuordnung.
"Speziell"? Wie schon versucht zu erläutern gibt es diverse Standard-
Encodings und bei Untergruppen in jedem Fall Custom Encoding. Ich
verstehe ja nach wie vor nicht, warum Du so ein Gewese mit der Herkunft
der PDFs machst. Poste doch mal die Ausgabe von pdfinfo.exe -- aktuell
vermute ich stark, dass es bei Producer "Mac OS X ... Quartz PDFContext"
stehen dürfte (Font-Untergruppen, Truetype/CID und Unicode, wo's nur
irgend geht -- das riecht zumindest nach Apple)
Author: Quadira BV
Creator: FormPipe Software, LaserNet Output Management 6.5.11.release
Producer: FormPipe Software, LaserNet Output Management 6.5.11.release
CreationDate: 10/20/15 05:11:02
ModDate: 10/20/15 07:50:09
Tagged: no
Form: none
Pages: 1
Encrypted: no
Page size: 595.276 x 841.89 pts (A4)
File size: 174624 bytes
Optimized: yes
PDF version: 1.4
Post by Tilmann Reh
Nach dem vollständigen Entfernen der eingebetteten Schriften ist der
größte Teil des Textes einwandfrei, nur ein paar Sonderzeichen und die
Umlaute werden nicht mehr korrekt angezeigt - stattdessen erscheinen
irgendwelche anderen Zeichen.
Ja mei, das klappt natürlich nicht, einen Zeichenvorrat, der in Unicode
beschrieben ist, als WinAnsi zu interpretieren.
Daher meine Frage, ob man
a) die Codierung entsprechend anpassen, oder
b) nur die nicht dem Standard (von mir aus ASCII) entsprechenden Zeichen
eben behalten könne.

(Alles, was es schon im ASCII gibt, wird offenbar auch nach stumpfer
Entfernung der Schriften noch richtig angezeigt.)
Post by Thomas Kaiser
Post by Tilmann Reh
Am schönsten wäre es, wenn man die Codierung im PDF auf "Standard"
zurechtbiegen könnte
Die ist Standard. Weil weder Windows noch dort gebräuchliche und sehr
beschränkte Gammel-Encodings wie das dort übliche ANSI (basiert AFAIK
auf ANSI 1252) sind die _einzigen_ Standards. Es gibt durchaus zeit-
gemäße wie die auf Unicode basierenden.
Ich halte ANSI durchaus für einen (zumindest nicht un-) üblichen
Standard. Und ansonsten ist es mirauch egal, ob die Zeichen im PDF jetzt
nach ANSI oder Unicode zugeordnet werden... Es muß halt nur stimmen. :-)

Tilmann
Thomas Kaiser
2015-10-23 14:50:46 UTC
Permalink
Post by Tilmann Reh
Ich halte ANSI durchaus für einen (zumindest nicht un-) üblichen
Standard. Und ansonsten ist es mirauch egal, ob die Zeichen im PDF
jetzt nach ANSI oder Unicode zugeordnet werden... Es muß halt nur
stimmen. :-)
Klar, nur es wird halt unter Garantie nicht stimmen, wenn das Encoding
im PDF ein anderes ist, als das, was Dein PDF-Schrumpfer dann am Ende
reinschreibt.

Mal anders gefragt und weil Du Faksimile bereits erwähntest. Wenn Du
auch damit zufrieden wärst, das Ganze als ultrakleines Bilddokument
weiterzuverwenden (wozu auch immer), würde ich eher in die Richtung
"Inhalt rendern und mit Maximalkompression als nur ein Bild enthaltenes
PDF aufbewahren" denken. Wozu dann überhaupt noch PDF als Container?
Weil PDF JBIG2 kann. JBIG2 ist hocheffizient für monochrome Bildobjekte
(zigmal effizienter als die bei Fax übliche CCITT Group 4 Kompression)
aber wenn man's übertreibt kann man auch prima auf die Fresse damit
fliegen:

http://heise.de/-1930941

Gruss,

Thomas

Tilmann Reh
2015-10-23 12:50:44 UTC
Permalink
Post by Thomas Kaiser
Eine vollumfänglich eingebettete Arial kann man risikofrei entfernen und
nicht mal die Anzeige wird anschl. großartig leiden, weil diese Sch***-
schrift ja auf jedem System vorausgesetzt werden kann. Bei einer
Untergruppe ist das 'ne andere Geschichte. Die bringt ihren eigenen
Zeichenvorrat und ihre eigene Zuordnung Character <--> Glyph mit. Und je
nachdem wie kreativ die erzeugende Anwendung war, kann nach Entfernen
der Schrift und Ersatz der eingebetteten Untergruppe durch die reine
Information "Standard-Arial mit WinAnsiEncoding" ein PDF entstehen, in
dem kein A mehr ein A sondern dann bspw. ein ñ ist. Gilt sinngemäß für
alle verwendeten Zeichen. Die müssen anschl. nicht mehr so aussehen wie
vorher, weil die Glyphen-Zuordnung im Eimer ist.
Nachtrag:

ein solches fremdes Bläh-PDF zeigt im Adobe Reader unter Schriften:

Arial (Eingebettete Untergruppe)
Typ: TrueType (CID)
Kodierung: Identity-H

Die Angaben in dem mit GS etwas verkleinerten PDF sind identisch.
Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
nicht den tatsächlich benutzten.

Bei der mittels PDFCreator erzeugten kompakten Version ohne jede
eingebettete Schriften (aber mit kaputten Umlauten und Sonderzeichen) steht:

Arial
Typ: TrueType
Kodierung: Mitgeliefert
Originalschrift: ArialMT
Originalschrifttyp: TrueType

Ein von mir selbst mit pdfFactory erstelltes PDF ohne eingebettete
Schriften (völlig anderes Dokument natürlich) zeigt dagegen:

Arial
Typ: TrueType
Kodierung: Ansi
Originalschrift: ArialMT
Originalschrifttyp: TrueType


Es hat den Anschein, als ob das "Mitliefern" der Codierung der
eigentliche Knackpunkt ist bzw. dabei etwas schiefläuft.

Tilmann
Thomas Kaiser
2015-10-23 14:07:30 UTC
Permalink
Post by Tilmann Reh
Die Angaben in dem mit GS etwas verkleinerten PDF sind identisch.
Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
nicht den tatsächlich benutzten.
Aha, d.h. Du hast jetzt auf einmal doch Acrobat Pro auf dem Rechner,
dort das PDF geöffnet, bist in die Preflight-Funktion rein und dort
schön versteckt in den PDF-Objektbrowser? Oder wie kommst Du auf die
Idee, GS hätte an den Schriften rumgemacht? Bzw. woher willst Du wissen,
_was konkret_ im PDF jetzt weniger Platz verbraucht?

Ich würde ja eher zu MuPDF <http://mupdf.com/docs/> greifen. Zumindest
haben mir das mal Artifex-Leute nahegelegt, dass dessen Engine
verlustfreier PDF optimieren könne. Mittels mutool [1]

mutool -s -g -g -g

kriegt man PDFs schön klein ohne sie kaputt zu machen. Aber grad weder
Zeit noch Lust, bzgl. Font-Handling zu gucken.

Gruss,

Thomas

[1] https://www.mankier.com/1/mutool
Tilmann Reh
2015-10-23 14:23:10 UTC
Permalink
Post by Thomas Kaiser
Post by Tilmann Reh
Die Angaben in dem mit GS etwas verkleinerten PDF sind identisch.
Demnach entfernt GS zwar durchaus einen guten Teil der Schriften, aber
nicht den tatsächlich benutzten.
Aha, d.h. Du hast jetzt auf einmal doch Acrobat Pro auf dem Rechner,
dort das PDF geöffnet, bist in die Preflight-Funktion rein und dort
schön versteckt in den PDF-Objektbrowser? Oder wie kommst Du auf die
Idee, GS hätte an den Schriften rumgemacht? Bzw. woher willst Du wissen,
_was konkret_ im PDF jetzt weniger Platz verbraucht?
Nein, ich habe nach wie vor kein Acrobat Pro.

Aber der PDF-XChange-Editor kann mir - auch wenn er die Schriften nicht
aus dem Dokument 'rauskriegt - zumindest anzeigen, was wieviel
Speicherplatz belegt.
Und da sehe ich dann, daß in dem von GS auf 67k geschrumpften PDF eben
nur noch 51k für Schriften belegt sind, gegenüber 154k für Schriften im
Original.

Ich gehe davon aus, daß das Original einfach den /kompletten/
Schriftsatz mit massenhaft ungenutzten Zeichen/Glyphen enthält.
Post by Thomas Kaiser
Ich würde ja eher zu MuPDF <http://mupdf.com/docs/> greifen. Zumindest
haben mir das mal Artifex-Leute nahegelegt, dass dessen Engine
verlustfreier PDF optimieren könne. Mittels mutool [1]
mutool -s -g -g -g
kriegt man PDFs schön klein ohne sie kaputt zu machen. Aber grad weder
Zeit noch Lust, bzgl. Font-Handling zu gucken.
Ich kanns ja mal ausprobieren...

Danke,
Tilmann
Tilmann Reh
2015-10-23 07:53:08 UTC
Permalink
Post by Christian Zietz
Post by Tilmann Reh
Klingt gut, hat aber auch Probleme: GS meldet grundsätzlich einen Fehler
zu den -c Optionen: "Error: /undefined in /setdistillerparams" und
bricht dann ab.
Das passiert unabhängig davon, ob nur eine dieser beiden Optionen
angegeben ist oder beide.
Das spricht dafür, dass Du an der Stelle an der "[...other options...]"
steht, eben nicht die anderen benötigten Optionen, insbesondere
-sDEVICE=pdfwrite angegeben hast. (Diesen Kommandozeilenparameter
*nicht* ans Ende stellen, sondern wirklich an der Stelle einfügen, an
der im Beispiel "[...other options...]" steht.
"c:\Program Files\gs\gs9.16\bin\gswin64c"^
-o output.pdf^
-sDEVICE=pdfwrite^
-dEmbedAllFonts=false^
-dSubsetFonts=true^
-dConvertCMYKImagesToRGB=true^
-dCompressFonts=true^
-c ".setpdfwrite <</AlwaysEmbed [ ]>> setdistillerparams" ^
-c ".setpdfwrite <</NeverEmbed [/Courier /Courier-Bold /Courier-Oblique /Courier-BoldOblique /Helvetica /Helvetica-Bold /Helvetica-Oblique /Helvetica-BoldOblique /Times-Roman /Times-Bold /Times-Italic /Times-BoldItalic /Symbol /ZapfDingbats /Arial /Arial-Bold /Arial-Italic]>> setdistillerparams" ^
-f input.pdf
Tilmann
Loading...