Problem mit epstopdf (rotiert ein Bild)
Harald Harders
ich habe ein Problem mit epstopdf, nämlich die Tatsache, dass es mir
eine EPS-Datei bei der Umwandlung in PDF rotiert.
Ich weiß nun natürlich nicht, wo genau der Fehler liegt. Ist es
epstopdf oder gs?
Bei der EPS-Datei handelt es sich um eine von gnuplot erzeugte Datei,
in der relativ viel vertikaler Text enthalten ist. Reduziere ich diesen,
behebt sich das Problem. Nur kann ich ja nicht auf notwendige Inhalte
verzichten, um eine korrekte Umwandlung zu ermöglichen.
Ich verwende folgende Programmversionen:
epstopdf 2.7
gs 7.22 und 6.53
Unter http://pc52.ifw.ing.tu-bs.de/~harders/latex/epstopdf/ habe ich die
beteiligten Dateien zum Download abgelegt. Die dort angelegte Datei
epstopdf zeigt im Unterschied zur normalen Version an, welche gs-Version
verwendet wird.
Ich bin für jeden Hinweis dankbar, wie ich das Problem beheben bzw.
lokalisieren kann.
Viele Grüße
Harald
--
Harald Harders Langer Kamp 8
Institut für Werkstoffe D-38106 Braunschweig
Technische Universität Braunschweig Germany
E-Mail: h.ha...@tu-bs.de Tel: +49 (0)5 31 - 3 91 - 30 62
WWW : http://www.tu-bs.de/institute/ifw/ Fax: +49 (0)5 31 - 3 91 - 30 58
Rolf Niepraschk
> Moin moin,
>
> ich habe ein Problem mit epstopdf, nämlich die Tatsache, dass es mir
> eine EPS-Datei bei der Umwandlung in PDF rotiert.
> Ich weiß nun natürlich nicht, wo genau der Fehler liegt. Ist es
> epstopdf oder gs?
>
> Bei der EPS-Datei handelt es sich um eine von gnuplot erzeugte Datei,
> in der relativ viel vertikaler Text enthalten ist. Reduziere ich diesen,
> behebt sich das Problem. Nur kann ich ja nicht auf notwendige Inhalte
> verzichten, um eine korrekte Umwandlung zu ermöglichen.
>
> Ich verwende folgende Programmversionen:
>
> epstopdf 2.7
> gs 7.22 und 6.53
>
> Unter http://pc52.ifw.ing.tu-bs.de/~harders/latex/epstopdf/ habe ich die
> beteiligten Dateien zum Download abgelegt. Die dort angelegte Datei
> epstopdf zeigt im Unterschied zur normalen Version an, welche gs-Version
> verwendet wird.
>
> Ich bin für jeden Hinweis dankbar, wie ich das Problem beheben bzw.
> lokalisieren kann.
>
Hatte das Problem letztens auch. Die Programme sind einfach "zu
intelligent" ;-( Heiko hatte (wie so oft) die Lösung:
Aufruf (zumindest unter Unix):
GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
...Rolf
--
|| Rolf Niepraschk c/o Physikalisch-Technische Bundesanstalt ||
|| Abbestr. 2-12; D-10587 Berlin, Germany ||
|| Tel/Fax: ++49-30-3481-316/490, email: niepr...@ptb.de ||
Harald Harders
> Harald Harders wrote:
>> Moin moin,
>>
>> ich habe ein Problem mit epstopdf, nämlich die Tatsache, dass es mir
>> eine EPS-Datei bei der Umwandlung in PDF rotiert.
>> Ich weiß nun natürlich nicht, wo genau der Fehler liegt. Ist es
>> epstopdf oder gs?
>>
>> Bei der EPS-Datei handelt es sich um eine von gnuplot erzeugte Datei,
>> in der relativ viel vertikaler Text enthalten ist. Reduziere ich diesen,
>> behebt sich das Problem. Nur kann ich ja nicht auf notwendige Inhalte
>> verzichten, um eine korrekte Umwandlung zu ermöglichen.
> Hatte das Problem letztens auch. Die Programme sind einfach "zu
> intelligent" ;-( Heiko hatte (wie so oft) die Lösung:
>
> Aufruf (zumindest unter Unix):
>
> GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
Danke. Ich denke, dass fast niemand eine automatische Rotation einer
EPS-Datei haben möchte. Ich habe mal eine kleine Änderung in epstopdf
eingebaut.
Was soll ich mit der Datei machen? Ich konnte leider keinen Hinweis auf
Copyrightbestimmungen finden. Soll ich die Datei auf CTAN hochladen?
Gruß
Harald
Hier kommt auf jeden Fall der Patch für Version 2.7:
<epstopdf-2.7-2.8.diff>
--- /usr/local/teTeX/bin/i686-pc-linux-gnu/epstopdf Mon Aug 12 18:19:44 2002
+++ ./epstopdf Thu Aug 15 13:28:05 2002
@@ -44,13 +44,15 @@
# 2001/03/05 v2.7 (Heiko Oberdiek)
# * Newline before grestore for the case that there is no
# whitespace at the end of the eps file.
+# 2002/08/15 v2.8 (Harald Harders)
+# * New option: --autorotate.
#
### program identification
my $program = "epstopdf";
-my $filedate="2001/03/05";
-my $fileversion="2.7";
-my $copyright = "Copyright 1998-2001 by Sebastian Rahtz et al.";
+my $filedate="2002/08/15";
+my $fileversion="2.8";
+my $copyright = "Copyright 1998-2002 by Sebastian Rahtz et al.";
my $title = "\U$program\E $fileversion, $filedate - $copyright\n";
### ghostscript command name
@@ -65,6 +67,7 @@
$::opt_gs=1;
$::opt_hires=0;
$::opt_exact=0;
+$::opt_autorotate=0;
$::opt_filter=0;
$::opt_outfile="";
@@ -80,6 +83,7 @@
--(no)compress: use compression (default: $bool[$::opt_compress])
--(no)hires: scan HiResBoundingBox (default: $bool[$::opt_hires])
--(no)exact: scan ExactBoundingBox (default: $bool[$::opt_exact])
+ --(no)autorotate: rotate automatically (default: $bool[$::opt_autorotate])
--(no)debug: debug informations (default: $bool[$::opt_debug])
Examples for producing 'test.pdf':
* $program test.eps
@@ -99,6 +103,7 @@
"gs!",
"hires!",
"exact!",
+ "autorotate!",
"outfile=s",
) or die $usage;
@@ -138,6 +143,7 @@
### option compress
my $GSOPTS = "";
$GSOPTS = "-dUseFlateCompression=false " unless $::opt_compress;
+$GSOPTS = $GSOPTS . "-dAutoRotatePages=/None " unless $::opt_autorotate;
### option BoundingBox types
my $BBName = "%%BoundingBox:";
</epstopdf-2.7-2.8.diff>
Heiko Oberdiek
> > GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
>
> Danke. Ich denke, dass fast niemand eine automatische Rotation einer
> EPS-Datei haben möchte.
Woher *weisst* du das?
> Ich habe mal eine kleine Änderung in epstopdf
> eingebaut.
Das ist aber nur eine von *vielen* Defaultaenderungen, die
vermutlich sinnvoll waere, da Ghostscript mittlerweile mehr
Distiller-Optionen versteht, bzw. sich das Ghostscript-Default-
Verhalten geaendert hat.
Nur halte ich es nicht fuer gut, in kurzen Abstaenden
verschiedene epstopdf-Versionen zu erstellen, die
sich alle *unterschiedlich* verhalten. IMHO kann man
das nur in *einem* groesseren Schritt machen, der
dann auch gleich durch einen Versionssprung etwa
auf 3.0 markiert wird.
Nur die Punkte, die alle abzuhandeln waeren,
lassen sich nicht mal eben an einem Nachmittag
erledigen.
Auf die Schnelle ein paar dieser Punkte, die mir gerade
einfallen:
* Default-Setzung der Ghostscript-Optionen
* Wie soll der Benutzer Ghostscript-Optionen angeben.
* Konfigurationsdateien?
* Spezialisierte Optionen versus eine Option, die
die Ghostscript-Optionen nur durchreicht?
* Nicht alle Optionen koennen als Optionen gesetzt
werden, sondern werden durch PostScript-Code
gesetzt.
* Zeilenendenbehandlung
* Bessere Hires-BoundingBox-Unterstuetzung, ist
das ueberhaupt moeglich?
* BoundingBox-Berechnung bei fehlender BoundingBox.
* Da es mittlerweile leider zu viele unterschiedliche Ports
gibt, sollte das Verhalten von epstopdf spezifiziert
werden, so dass man Implementationen ueberpruefen
kann.
* Benutzerhandbuch.
* ...
Wenn es an mir alleine haengen bleibt, wird es dauern,
ein Aufruf in TEX-D-L blieb da leider ohne Resonanz.
Wenn sich ein paar zur Mithilfe finden wuerden, wuerde
sich das beschleunigen.
> Was soll ich mit der Datei machen? Ich konnte leider keinen Hinweis auf
> Copyrightbestimmungen finden. Soll ich die Datei auf CTAN hochladen?
Sebastian Rahtz mit Aenderungen durch Thomas Esser, mir et.al.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
David Kastrup
> Harald Harders <h.ha...@tu-bs.de> wrote:
>
> > > GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
> >
> > Danke. Ich denke, dass fast niemand eine automatische Rotation einer
> > EPS-Datei haben möchte.
>
> Woher *weisst* du das?
>
> > Ich habe mal eine kleine Änderung in epstopdf
> > eingebaut.
>
> Das ist aber nur eine von *vielen* Defaultaenderungen, die
> vermutlich sinnvoll waere, da Ghostscript mittlerweile mehr
> Distiller-Optionen versteht, bzw. sich das Ghostscript-Default-
> Verhalten geaendert hat.
>
> Nur halte ich es nicht fuer gut, in kurzen Abstaenden
> verschiedene epstopdf-Versionen zu erstellen, die
> sich alle *unterschiedlich* verhalten. IMHO kann man
> das nur in *einem* groesseren Schritt machen, der
> dann auch gleich durch einen Versionssprung etwa
> auf 3.0 markiert wird.
>
> Nur die Punkte, die alle abzuhandeln waeren,
> lassen sich nicht mal eben an einem Nachmittag
> erledigen.
>
> Auf die Schnelle ein paar dieser Punkte, die mir gerade
> einfallen:
[...]
Du hast einen wichtigen vergessen: andere Ausgabedevices als PDF.
Das Boundingboxbestimmereizeugs ist ja in genau dieser Form auch
nötig, wenn man PNG und anderes erzeugen will. In dem Fall will man
natürlich auch noch Optionen wie Auflösung setzen.
Ich habe schon häufiger Leuten den Rat gegeben "holt euch epstopdf,
speichert es unter einem anderen Namen, und dann editiert andere
Optionen rein".
Das ist ja langfristig etwas panne.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David....@t-online.de
Rolf Niepraschk
> Harald Harders <h.ha...@tu-bs.de> wrote:
>
>
>>> GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
>>
>>Danke. Ich denke, dass fast niemand eine automatische Rotation einer
>>EPS-Datei haben möchte.
>
>
> Woher *weisst* du das?
>
Das vermutet er natürlich nur ;-) Allerdings liegt er so falsch damit
nicht. Auch ich halte es nicht für sinnvoll, dass ein Programm eine ihm
zur Konvertierung übergebene Grafik zusätzlich auch noch dreht.
Insbesondere Im Umfeld von TeX ist das unangebracht, da man im Dokument
selbst genügend Möglichkeiten dazu hat und diese auch nutzen möchte (und
es sollte kein "Glücksspiel" sein, ob ich am Ende den Kopf weiter gerade
halten darf oder nicht ;-)
Harald Harders
[...]
>> Danke. Ich denke, dass fast niemand eine automatische Rotation einer
>> EPS-Datei haben möchte.
>
> Woher *weisst* du das?
Wissen tue ich es nicht, aber das habe ich ja nicht behauptet.
>> Ich habe mal eine kleine Änderung in epstopdf
>> eingebaut.
[...]
> Nur halte ich es nicht fuer gut, in kurzen Abstaenden
> verschiedene epstopdf-Versionen zu erstellen, die
> sich alle *unterschiedlich* verhalten. IMHO kann man
> das nur in *einem* groesseren Schritt machen, der
> dann auch gleich durch einen Versionssprung etwa
> auf 3.0 markiert wird.
Einverstanden.
> Nur die Punkte, die alle abzuhandeln waeren,
> lassen sich nicht mal eben an einem Nachmittag
> erledigen.
[...]
> Wenn es an mir alleine haengen bleibt, wird es dauern,
> ein Aufruf in TEX-D-L blieb da leider ohne Resonanz.
> Wenn sich ein paar zur Mithilfe finden wuerden, wuerde
> sich das beschleunigen.
Ich würde schon ein bisschen helfen. Allerdings kann ich kein Perl.
Na ja, dann lerne ich es halt dabei.
Gruß
Harald
Harald Harders
> Heiko Oberdiek <ober...@uni-freiburg.de> writes:
[...]
>> Nur die Punkte, die alle abzuhandeln waeren,
>> lassen sich nicht mal eben an einem Nachmittag
>> erledigen.
>>
>> Auf die Schnelle ein paar dieser Punkte, die mir gerade
>> einfallen:
[...]
> Du hast einen wichtigen vergessen: andere Ausgabedevices als PDF.
> Das Boundingboxbestimmereizeugs ist ja in genau dieser Form auch
> nötig, wenn man PNG und anderes erzeugen will. In dem Fall will man
> natürlich auch noch Optionen wie Auflösung setzen.
Für alles, was kein Vektorformat ist, funktioniert doch convert ganz gut.
Warum sollte man dann nochmal das ganze erfinden? Oder kann convert
irgendetwas nicht, was notwendig wäre?
Harald
David Kastrup
> On 15 Aug 2002 15:10:10 +0200, David Kastrup wrote:
> > Heiko Oberdiek <ober...@uni-freiburg.de> writes:
>
> [...]
>
> >> Nur die Punkte, die alle abzuhandeln waeren,
> >> lassen sich nicht mal eben an einem Nachmittag
> >> erledigen.
> >>
> >> Auf die Schnelle ein paar dieser Punkte, die mir gerade
> >> einfallen:
>
> [...]
>
> > Du hast einen wichtigen vergessen: andere Ausgabedevices als PDF.
> > Das Boundingboxbestimmereizeugs ist ja in genau dieser Form auch
> > nötig, wenn man PNG und anderes erzeugen will. In dem Fall will man
> > natürlich auch noch Optionen wie Auflösung setzen.
>
> Für alles, was kein Vektorformat ist, funktioniert doch convert ganz gut.
> Warum sollte man dann nochmal das ganze erfinden? Oder kann convert
> irgendetwas nicht, was notwendig wäre?
Verwendung der vorgegebenen Boundingbox? Irgendwas war da jedenfalls.
Heiko Oberdiek
> Heiko Oberdiek <ober...@uni-freiburg.de> writes:
>
> > Auf die Schnelle ein paar dieser Punkte, die mir gerade
> > einfallen:
>
> [...]
>
> Du hast einen wichtigen vergessen: andere Ausgabedevices als PDF.
Korrekt, hatte ich vergessen zu erwaehnen.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Heiko Oberdiek wrote:
> > Harald Harders <h.ha...@tu-bs.de> wrote:
> >
> >
> >>> GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
> >>
> >>Danke. Ich denke, dass fast niemand eine automatische Rotation einer
> >>EPS-Datei haben möchte.
> >
> >
> > Woher *weisst* du das?
> >
>
> Das vermutet er natürlich nur ;-) Allerdings liegt er so falsch damit
> nicht. Auch ich halte es nicht für sinnvoll, dass ein Programm eine ihm
> zur Konvertierung übergebene Grafik zusätzlich auch noch dreht.
> Insbesondere Im Umfeld von TeX ist das unangebracht, da man im Dokument
> selbst genügend Möglichkeiten dazu hat und diese auch nutzen möchte (und
> es sollte kein "Glücksspiel" sein, ob ich am Ende den Kopf weiter gerade
> halten darf oder nicht ;-)
Dann spezifiere mal, wie soll sich epstopdf im Standardfalle
verhalten?
* Ghostscript-Default-Optionen (zur Zeit).
* "So, wie wenn man die .eps-Datei in LaTeX einbindet
und mit dvips bearbeitet."
Das ist noch sehr schwammig formuliert.
* Soll sich das nur auf die Orientierung beziehen.
* Was ist mit den vielen anderen Optionen
(Aufloesung, Antialiasing, /prepress, ...)?
* Eigene epstopdf-Voreinstellung?
* ...
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Stephan Lehmke
>
> * Zeilenendenbehandlung
Ooooh ja, bitte bitte.
Zumal die Fehlermeldung, die man erhaelt, wenn man z.B. eine Mac-Datei
verfuettert, alles andere als hilfreich ist (schon klar, ist die
Schuld von ghostscript).
> * Bessere Hires-BoundingBox-Unterstuetzung, ist
> das ueberhaupt moeglich?
Hoechstens die bei Vorhandensein per default zu verwenden. Welchen
Sinn soll es haben, defaultmaessig falsche Raender zu produzieren?
> Wenn es an mir alleine haengen bleibt, wird es dauern,
> ein Aufruf in TEX-D-L blieb da leider ohne Resonanz.
> Wenn sich ein paar zur Mithilfe finden wuerden, wuerde
> sich das beschleunigen.
Kann kein Perl.
Stelle mich aber fuer grobmotorische Hilfsarbeiten gern zur Verfuegung
;-)
Gruss
Stephan
David Kastrup
> In <ajg77i$rlk$1...@n.ruf.uni-freiburg.de>, Heiko Oberdiek writes:
> >
> > * Zeilenendenbehandlung
>
> Ooooh ja, bitte bitte.
>
> Zumal die Fehlermeldung, die man erhaelt, wenn man z.B. eine Mac-Datei
> verfuettert, alles andere als hilfreich ist (schon klar, ist die
> Schuld von ghostscript).
Unwahrscheinlich. PostScript erlaubt explizit jegliche Art der
verschiedenen Zeilenenden, auch vollkommen durcheinander. Da gewisse
Zeitgenossen ihre EPS-Dateien gerne auf Macs anfertigen, um sie dann
auf Unix zu einem PS-file zusammenzuknoten, ziemlich wichtig.
Ist natürlich ziemlich lästig, wenn man das Zeug dann anderweitig
bearbeiten will.
Heiko Oberdiek
> Ich würde schon ein bisschen helfen.
Schoen.
> Allerdings kann ich kein Perl.
> Na ja, dann lerne ich es halt dabei.
Perl ist das Unwichtigste, wichtiger ist am Anfang
vielmehr:
* Vorstellung, was soll epstopdf machen,
welche Features soll es bieten, welche nicht.
Testen auf Machbarkeit (Hires-BoundingBox, ...), wie
koennte etwas gemacht werden.
* Sammlung von Testdateien.
* Spezifikation, Benutzerschnittstellen, Benutzerhandbuch.
* Implementation. Bei klarer Spezifikation koennte man
ohne zu grossen Aufwand etwa auch eine Java-Version
zusaetzlich anbieten.
* Testen.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Rolf Niepraschk
...
>>>Woher *weisst* du das?
>>>
>>
>>Das vermutet er natürlich nur ;-) Allerdings liegt er so falsch damit
>>nicht. Auch ich halte es nicht für sinnvoll, dass ein Programm eine ihm
>>zur Konvertierung übergebene Grafik zusätzlich auch noch dreht.
>>Insbesondere Im Umfeld von TeX ist das unangebracht, da man im Dokument
>>selbst genügend Möglichkeiten dazu hat und diese auch nutzen möchte (und
>>es sollte kein "Glücksspiel" sein, ob ich am Ende den Kopf weiter gerade
>>halten darf oder nicht ;-)
>
>
> Dann spezifiere mal, wie soll sich epstopdf im Standardfalle
> verhalten?
>
> * Ghostscript-Default-Optionen (zur Zeit).
Mag sein, dass es "schwammig" wird. Den Endanwender interessieren
Ghostscript-Optionen in der Regel überhaupt nicht. Daher müssen
Default-Optionen, wenn denn nötig, so gesetzt sein, dass das folgende
sinnvoll passiert.
> * "So, wie wenn man die .eps-Datei in LaTeX einbindet
> und mit dvips bearbeitet."
Ja.
> Das ist noch sehr schwammig formuliert.
Ach, was...
> * Soll sich das nur auf die Orientierung beziehen.
> * Was ist mit den vielen anderen Optionen
> (Aufloesung, Antialiasing, /prepress, ...)?
Ich will ein zur eps-Datei _äquivalente_ pdf-Datei haben. Was das im
Einzelnen betrifft, weiß ich nicht. Es ist mir allerdings unklar warum
Aufloesung und Antialiasing eine Rolle spielen soll. Ich will ja keine
Vektorgrafik in eine Bitmapgrafik konvertiern, sondern siehe oben...
> * Eigene epstopdf-Voreinstellung?
Das sollte für den "Power-User" möglich sein, ist aber zweitrangig
(siehe oben).
Heiko Oberdiek
> Heiko Oberdiek wrote:
>
> > Dann spezifiere mal, wie soll sich epstopdf im Standardfalle
> > verhalten?
> >
> > * Ghostscript-Default-Optionen (zur Zeit).
>
> Mag sein, dass es "schwammig" wird. Den Endanwender interessieren
> Ghostscript-Optionen in der Regel überhaupt nicht. Daher müssen
> Default-Optionen, wenn denn nötig, so gesetzt sein, dass das folgende
> sinnvoll passiert.
>
> > * "So, wie wenn man die .eps-Datei in LaTeX einbindet
> > und mit dvips bearbeitet."
>
> Ja.
>
> > Das ist noch sehr schwammig formuliert.
>
> Ach, was...
Das primaere Ergebnis von epstopdf ist PDF, das von
dvips ist PostScript. Man vergleicht also Aepfel mit
Birnen.
> > * Soll sich das nur auf die Orientierung beziehen.
> > * Was ist mit den vielen anderen Optionen
> > (Aufloesung, Antialiasing, /prepress, ...)?
>
> Ich will ein zur eps-Datei _äquivalente_ pdf-Datei haben. Was das im
> Einzelnen betrifft, weiß ich nicht.
Das ist ja gerade das Problem. Was ist "Aequivalenz" hier?
Nach dem naechsten Abschnitt gebe ich mal ein Beispiel,
um zu illustrieren, dass man mit "scheinbarer" Aequivalenz
schnell Schiffbruch erleidet.
> Es ist mir allerdings unklar warum
> Aufloesung und Antialiasing eine Rolle spielen soll. Ich will ja keine
> Vektorgrafik in eine Bitmapgrafik konvertiern, sondern siehe oben...
Aufloesung und Antialiasing sind zwei der Benutzerwuensche,
die mir gerade eingefallen sind. Damit spielen sie eine Rolle.
Das Ergebnis PDF ist ja bereits das Endprodukt. Beim Einbinden
der PDF-Grafik wird diese ja nicht mehr veraendert.
(Wenn man von Farbsetzungen absieht, aber das ist ein
anderes Thema.)
Zur Illustration ein Beispielsszenario.
Die PostScript-Grafik:
%%% cut %%% rot.eps %%% cut %%%
%!PS
%%BoundingBox: 272 300 301 501
300 300 moveto
90 rotate
/Times-Roman findfont 40 scalefont setfont
(Hello World) show
showpage
%%% cut %%% rot.eps %%% cut %%%
Die LaTeX-Test-Datei:
%%% cut %%% test.tex %%% cut %%%
\documentclass{article}
\usepackage{times}
\usepackage{graphicx}
\pagestyle{empty}
\begin{document}
First page
\newpage
\includegraphics{rot}
\end{document}
%%% cut %%% test.tex %%% cut %%%
Die folgenden Szenarien nehmen "Standard"/"Default"-Verhalten
an, ungesetzte Umgebungsvariable GS_OPTIONS usw.
Ferner sind neuere Ghostscript-Versionen angenommen,
etwa eine der 7er Versionen.
Szenario 1:
latex test
dvips test
ps2pdf test
acroread test.pdf
==> 2. Seite gedreht, "Hello World" horizontal (lesbar)
Szenario 2:
epstopdf rot.eps
pdfelatex test
acroread test.pdf
==> 2. Seite normal, "Hello World" horizontal (lesbar)
Szenario 3:
GS_OPTIONS=-dAutoRotatePages=/None epstopdf rot.eps
pdfelatex test
acroread test.pdf
==> 2. Seite normal, "Hello World" vertikal
Wie bekommt man hier "Aequivalenz"?
Wie soll sich epstopdf verhalten?
Wie erklaert man das dem Benutzer?
So schlecht das bisherige Verhalten von epstopdf auch
sein mag, es hat zumindest den grossen Vorteil, dass
das Verhalten dem Benutzer sehr kurz erklaert werden
kann: Das Programm epstopdf verschiebt die Grafik
und setzt die Seitengroesse gemaess der BoundingBox
und ruft dann schlicht Ghostscript zur Konvertierung aus.
Meine These ist, dass man durch welche Ghostscript-Optionen-
Setzung auch immer keine 100%ige "Aequivalenz" erreichen
kann, wenn man etwa nur dvips-Ausgabe mit epstopdf/pdftex
vergleicht.
Moegliche Auswege waeren etwa:
* Schaerfere, praezisere Definition des Aequivalenz-Begriffs.
Vermutlich wird man um die Einbeziehung von ps2pdf nicht
herumkommen. Hauptproblem: Die Begriffsdefinition muss
soetwas wie "Aequivalenz" auch leisten koennen und fuer
den Benutzer nachvollziehbar sein und so seine moeglichen
Konvertierungsprobleme verstehen und loesen kann.
* GUI-Interface mit Vorschau etc.
* Ein "dummes" epstopdf, das nicht schlauer zu sein versucht,
als es sein kann (gleiches oder aehnliches Verhalten wie
bisher), so dass ein Benutzer bei Problemen sich nicht
zusaetzlich in die "Intelligenz" von epstopdf einarbeiten
muss, um sein Problem zu verstehen und loesen.
* ...
Bei allen Wegen benoetigt man, denke ich, ein Benutzerhandbuch,
das zum einen epstopdf erklaert, zum anderen die typischen
(Problem-)Faelle vorstellt und Loesungsstrategien aufzeigt.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Harald Harders
> Rolf Niepraschk <Rolf.Ni...@ptb.de> wrote:
>
>> Heiko Oberdiek wrote:
>> > Harald Harders <h.ha...@tu-bs.de> wrote:
>> >
>> >
>> >>> GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
>> >>
>> >>Danke. Ich denke, dass fast niemand eine automatische Rotation einer
>> >>EPS-Datei haben möchte.
[...]
>> Das vermutet er natürlich nur ;-) Allerdings liegt er so falsch damit
>> nicht. Auch ich halte es nicht für sinnvoll, dass ein Programm eine ihm
>> zur Konvertierung übergebene Grafik zusätzlich auch noch dreht.
>> Insbesondere Im Umfeld von TeX ist das unangebracht, da man im Dokument
>> selbst genügend Möglichkeiten dazu hat und diese auch nutzen möchte (und
>> es sollte kein "Glücksspiel" sein, ob ich am Ende den Kopf weiter gerade
>> halten darf oder nicht ;-)
>
> Dann spezifiere mal, wie soll sich epstopdf im Standardfalle
> verhalten?
[...]
Ich würde sagen, das Default-Verhalten sollte so sein, dass die pdf-Datei,
in gs angeguckt, genauso aussieht wie die eps-Datei, auch im gs angesehen
(Also gs nur so als Beispiel, man könnte auch den Ausdruck nehmen).
> * Was ist mit den vielen anderen Optionen
> (Aufloesung, Antialiasing, /prepress, ...)?
Die Auflösung wovon? Ich dachte, eine Umwandlung von eps zu pdf ist
hauptsächlich ein Entrollen von Schleifen usw., weil die nicht von pdf
unterstützt werden. Und auflösungsbehaftete Dinge wie eingebundene
Pixelgraphiken sollten so bleiben, wie sie im Original waren.
Und wenn an Auflösungen und so nichts geändert wird, müsste doch auch
kein Antialiasing gemacht werden, oder sehe ich da etwas falsch?
Was ist /prepress?
> * Eigene epstopdf-Voreinstellung?
Es wäre vielleicht gut, wenn epstopdf eine Datei ~/.epstopdf oder
/etc/epstopdfrc auslesen würde. Aber unbedingt notwendig finde ich
das nicht.
Aber wie gesagt, ich helfe gerne bei der Weiterentwicklung von epstopdf und
lerne auch gerne Perl dafür. Es müsste nur jemand die Koordination
übernehmen, was ich nicht so gerne tun würde.
Viele Grüße
Harald
Heiko Oberdiek
> On Thu, 15 Aug 2002 15:59:38 +0200, Heiko Oberdiek wrote:
>
> > Dann spezifiere mal, wie soll sich epstopdf im Standardfalle
> > verhalten?
>
> [...]
>
> Ich würde sagen, das Default-Verhalten sollte so sein, dass die pdf-Datei,
> in gs angeguckt, genauso aussieht wie die eps-Datei, auch im gs angesehen
> (Also gs nur so als Beispiel, man könnte auch den Ausdruck nehmen).
Vorsicht, das sind bereits mehrere Paar Stiefel:
Es gibt Setzungen fuer den Bildschirm:
-dPDFSETTINGS=/screen
bzw.
-dPDFSETTINGS=/ebook
oder Druck:
-dPDFSETTINGS=/printer
bzw.
-dPDFSETTINGS=/prepress
Daneben gibt es noch die Menge
-dPDFSETTINGS=/default
Beschreibungen sind zu finden in
doc/Ps2pdf.htm:
> > * Was ist mit den vielen anderen Optionen
> > (Aufloesung, Antialiasing, /prepress, ...)?
>
> Die Auflösung wovon? Ich dachte, eine Umwandlung von eps zu pdf ist
> hauptsächlich ein Entrollen von Schleifen usw., weil die nicht von pdf
> unterstützt werden. Und auflösungsbehaftete Dinge wie eingebundene
> Pixelgraphiken sollten so bleiben, wie sie im Original waren.
Es gibt PostScript-Operatoren, die sind aufloesungsabhaengig.
Sinnvoll sind sie etwa einsetzbar bei duennen Linien oder im
Extremfall bei duennen Linienmustern. Es wuerde nicht so
gut aussehen, wenn ein Linienmuster mit gleichbreit
gedachten Linien ploetzlich durch Linien mit Breiten von
1 Pixel und 2 Pixel aufgeloest wird.
Uebrigens verursacht die Aufloesungsabhaengigkeit die
groessten Probleme, wenn man versucht, Ernst mit
HiresBoundingBox zu machen. Man nehme nur am
Rand mal einen Buchstaben mit Rundung, je nach
Aufloesung erhaelt man dann eine andere "exakte"
BoundingBox.
Praktische Relevanz hat dies etwa, wenn man ungewoehnliche
Symbole als PostScript-Grafiken verwenden moechte,
oder allgemein, bei EPS-Dateien mit kleinen BoundingBoxen, die
randfrei und womoeglich noch stark vergroessert eingesetzt
werden sollen.
> Und wenn an Auflösungen und so nichts geändert wird, müsste doch auch
> kein Antialiasing gemacht werden, oder sehe ich da etwas falsch?
> Was ist /prepress?
ghostscript/7.xx/doc/Ps2pdf.htm
> > * Eigene epstopdf-Voreinstellung?
>
> Es wäre vielleicht gut, wenn epstopdf eine Datei ~/.epstopdf oder
> /etc/epstopdfrc auslesen würde. Aber unbedingt notwendig finde ich
> das nicht.
Konfigurationsdateien sind eine Idee, die diskutiert werden sollte:
* Ob ueberhaupt.
* Wenn ja, dann wo liegen sie mit welchem Namen,
wie sind sie angebbar, usw.
* Was soll die Konfigurationsdatei enthalten, Syntax?
> Aber wie gesagt, ich helfe gerne bei der Weiterentwicklung von epstopdf und
> lerne auch gerne Perl dafür. Es müsste nur jemand die Koordination
> übernehmen, was ich nicht so gerne tun würde.
Wie ich schon mal geschrieben hatte, ist Perl erstmal der unwichtigste
Part. Der beste Perl-Programmierer wird machtlos sein, wenn er ein
Programm schreiben muesste, dass im Standardaufruf mit
Konfigurationsdateien arbeitet und gleichzeitig keine verwendet.
Will sagen, ohne klare Vorstellung davon, was epsopdf ueberhaupt
tun soll, wie es dazu aufgerufen wird und wie es das machen kann,
macht es keinen Sinn, mit der Implementation anzufangen.
An der Koordination versuche ich mich ja bereits. Durch provokante
Kommentare hoffe ich ein "Problembewusstsein" zu schaffen.
Das Tueckische am epstopdf-Problem ist, dass es auf den ersten
Blicken ziemlich trivial aussieht. Wenn man aber dann die
"Trivialitaeten" umzusetzen versucht und ein gutes, "korrektes"
Ergebnis haben moechte, steht man schnell vor der Erkenntnis,
dass dies in vielen Faellen gar nicht erreichbar sein kann.
Als Ausweg sehe ich da nur eine sorgfaeltige Spezifikation
und ein Benutzerhandbuch. Dies hilft dann bei der
"Standardisierung" von epstopdf (Zur Zeit gibt es leider
einen Wildwuchs von nicht kompatiblen Versionen).
Benutzer koennen dann Probleme leichter verstehen
und loesen.
Ich denke der erste Schritt fuer die Weiterentwicklung
wird eine "Requirements Analysis" sein muessen. Als
Hilfsfragen zum Einstieg schlage ich vor:
* Was ist der Status quo.
* Einsatzzweck, Benutzer, ...
* Welche Aufgaben/Funktionen?
* Welche davon auf alle Faelle (Musskriterien)?
* Welche davon optional (Kannkriterien)?
* Welche auf keinen Fall (Auschlusskriterien)?
* Ueberlegungen zur Machbarkeit.
* Sammlung von Testdateien aufbauen.
* Wie koennen Benutzerschnittstellen aussehen?
* ...
Viele Gruesse
Heiko <ober...@unii-freiburg.de>
Matthias Schwaiger
> * Ob ueberhaupt.
> * Wenn ja, dann wo liegen sie mit welchem Namen,
> wie sind sie angebbar, usw.
> * Was soll die Konfigurationsdatei enthalten, Syntax?
Hierzu vielleicht eine Idee:
- Wenn keine Konfigurationsdatei vorhanden: Standardwerte
- Ansonsten Suchreihenfolge: Bildordner, epstopdf-Ordner (dann könnte man
für bestimmte Sachen spezielle Konfigurationsdateien erstellen, indem man in
den Bildordner so eine modifizierte Datei einfügt).
- Kommandozeilen-option, eine bestimmte oder gar keine Konfigurationsdatei
zu verwenden
- Konf-Datei in ASCII wg. Editierbarkeit (z.B. Parameter="Wert"); für alle
Werte, die nicht umdefiniert worden sind werden Standardwerte genommen.
So könnte man z.B. die bisherige einfache Regel "GS-default" beibehalten und
jeder könnte mit einer optionalen Konf.-Datei sein eigenes Süppchen
kochen...
Nur mal so in den Raum geschmissen. Die Entscheidung, ob's brauchbar ist
überlasse ich denjenigen die mehr davon verstehen... :-)
Matthias
Heiko Oberdiek
> > Konfigurationsdateien sind eine Idee, die diskutiert werden sollte:
> > * Ob ueberhaupt.
> > * Wenn ja, dann wo liegen sie mit welchem Namen,
> > wie sind sie angebbar, usw.
> > * Was soll die Konfigurationsdatei enthalten, Syntax?
>
> Hierzu vielleicht eine Idee:
>
> - Wenn keine Konfigurationsdatei vorhanden: Standardwerte
Klar, da bleibt ja wohl nichts anderes uebrig.
> - Ansonsten Suchreihenfolge: Bildordner, epstopdf-Ordner (dann könnte man
> für bestimmte Sachen spezielle Konfigurationsdateien erstellen, indem man in
> den Bildordner so eine modifizierte Datei einfügt).
Ich versuche mal moegliche Orte aufzuzaehlen:
* aktuelles Verzeichnis
* Verzeichnis, in dem sich das gerade zu konvertierende Bild befindet.
(Das meintest du wohl mit "Bildordner"?)
* Verzeichnis, in dem epstopdf liegt.
Aus der Unix-Welt:
* $HOME/.epstopdfrc
* /etc/epstopdfrc
Aus der Windows-Welt:
* $windows/epstopdf.ini
* Registry
> - Kommandozeilen-option, eine bestimmte oder gar keine Konfigurationsdatei
> zu verwenden
Naechster Fragenkomplex waere dann:
* Welche Konfigurationsdatei wird genommen?
Die letzte bzw. erste einer vorgegebenen Ordnung?
* Oder werden alle eingelesen, wobei Werte hinzugefuegt
und ueberschrieben werden koennen?
* Oder wie die Map-Dateien von pdfTeX:
map first (first ersetzt alle vorigen Dateien und startet
neue Map-Dateien-Liste)
map +next (fuegt next zur Liste)
> - Konf-Datei in ASCII wg. Editierbarkeit (z.B. Parameter="Wert"); für alle
> Werte, die nicht umdefiniert worden sind werden Standardwerte genommen.
Fuer die Syntax ist es vielleicht einfacher, erst einmal zu sehen,
was ueberhaupt herein soll. Zum einen koennen das
Ghostscript-Optionen, zum anderen aber auch PostScript-Code
sein.
> So könnte man z.B. die bisherige einfache Regel "GS-default" beibehalten und
> jeder könnte mit einer optionalen Konf.-Datei sein eigenes Süppchen
> kochen...
D.h. du wuerdest bei den "Default"-Werten aus Kompatibilitaetsgruenden
fuer die Beibehaltung des jetzigen Verhaltens plaedieren?
> Nur mal so in den Raum geschmissen. Die Entscheidung, ob's brauchbar ist
> überlasse ich denjenigen die mehr davon verstehen... :-)
Ja, interessant sind zum einen Ideen, zum anderen Feedback,
insbesondere wenn es dann daran geht, einen Konsensus zu
finden, mit denen moeglichst alle "zufrieden" sind.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Mark Trettin
* Heiko Oberdiek <ober...@uni-freiburg.de> schrieb:
> "Matthias Schwaiger" <matthias....@gmx.de> wrote:
[...]
> Ich versuche mal moegliche Orte aufzuzaehlen:
> * aktuelles Verzeichnis
> * Verzeichnis, in dem sich das gerade zu konvertierende Bild befindet.
> (Das meintest du wohl mit "Bildordner"?)
> * Verzeichnis, in dem epstopdf liegt.
> Aus der Unix-Welt:
* `pwd`/.epstopdfrc
> * $HOME/.epstopdfrc
> * /etc/epstopdfrc
> Aus der Windows-Welt:
> * $windows/epstopdf.ini
> * Registry
>> - Kommandozeilen-option, eine bestimmte oder gar keine Konfigurationsdatei
>> zu verwenden
> Naechster Fragenkomplex waere dann:
> * Welche Konfigurationsdatei wird genommen?
> Die letzte bzw. erste einer vorgegebenen Ordnung?
"Such"-Reihenfolge IMHO:
1. Kommandozeile
2. aktuelles Verzeichnis
3. $HOME
4. /etc
> * Oder werden alle eingelesen, wobei Werte hinzugefuegt
> und ueberschrieben werden koennen?
> * Oder wie die Map-Dateien von pdfTeX:
> map first (first ersetzt alle vorigen Dateien und startet
> neue Map-Dateien-Liste)
> map +next (fuegt next zur Liste)
Ich würde überschreiben wählen. Also wenn Wert gesetzt dann bleibt er
solange erhalten, bis man ihn in einer anderen Datei -- nach obiger
Suchreihenfolge -- überschreibt.
Vorteile:
· in /etc bzw. $HOME könnte man System-/GS-spezifische
Voreinstellungen treffen.
· Zusätliche Einstellungen ruft man per Kommandozeile oder in der
config des aktuellen Verzeichnisses auf, bzw. man `override't die
Systemeinstellungen.
· Man kann so also in die lokalen config Dateien entweder eine
komplette Konfiguration packen oder nur die Änderungen, je nach
Geschmack.
Nachteile:
fällt mir momentan keiner ein. :-)
[...]
> Ja, interessant sind zum einen Ideen, zum anderen Feedback,
> insbesondere wenn es dann daran geht, einen Konsensus zu
> finden, mit denen moeglichst alle "zufrieden" sind.
Nurmalsozumdrüberdiskutieren.
Bis dann
Mark
--
Mark Trettin ------- *Aachen* -- Wo ist das? ------> N: 50°46' O: 06°05'
FdI 51: Version x.5
Mit neuen Icons! (Kristian Köhntopp)
Harald Harders
> Harald Harders <h.ha...@tu-bs.de> wrote:
>
>> On Thu, 15 Aug 2002 15:59:38 +0200, Heiko Oberdiek wrote:
>>
>> > Dann spezifiere mal, wie soll sich epstopdf im Standardfalle
>> > verhalten?
>>
>> [...]
>>
>> Ich würde sagen, das Default-Verhalten sollte so sein, dass die pdf-Datei,
>> in gs angeguckt, genauso aussieht wie die eps-Datei, auch im gs angesehen
>> (Also gs nur so als Beispiel, man könnte auch den Ausdruck nehmen).
>
> Vorsicht, das sind bereits mehrere Paar Stiefel:
> Es gibt Setzungen fuer den Bildschirm:
[...]
> Beschreibungen sind zu finden in
> doc/Ps2pdf.htm:
Werde ich mal lesen.
>> > * Was ist mit den vielen anderen Optionen
>> > (Aufloesung, Antialiasing, /prepress, ...)?
>>
>> Die Auflösung wovon? Ich dachte, eine Umwandlung von eps zu pdf ist
>> hauptsächlich ein Entrollen von Schleifen usw., weil die nicht von pdf
>> unterstützt werden. Und auflösungsbehaftete Dinge wie eingebundene
>> Pixelgraphiken sollten so bleiben, wie sie im Original waren.
>
> Es gibt PostScript-Operatoren, die sind aufloesungsabhaengig.
> Sinnvoll sind sie etwa einsetzbar bei duennen Linien oder im
> Extremfall bei duennen Linienmustern. Es wuerde nicht so
> gut aussehen, wenn ein Linienmuster mit gleichbreit
> gedachten Linien ploetzlich durch Linien mit Breiten von
> 1 Pixel und 2 Pixel aufgeloest wird.
Da muss ich einfach mal nachfragen (ich weiß wohl zu wenig über PDF).
Ich hatte nämlich bisher gedacht, dass pdf im Wesentlichen ein PS-
Abkömmling ist, der weniger Programmiersprachenstrukturen kann
(z. B. keine Schleifen), dafür aber Hypertextkram, bessere
Pixelbildeinbindung und Komprimierung/Verschlüsselung.
Aber anscheinend sind da noch unterschiede.
Beispielsweise ist eine Haarlinie in Postscript natürlich
auflösungsabhängig.
0 setlinewidth ergibt eine Linie, die von dem verwendeten Ausgabegerät
gerade noch dargestellt werden kann. Sie ist also auf einem 300dpi-Drucker
vier mal so dick wie auf einem 1200dpi-Drucker.
Ist beispielsweise hier das Verhalten von pdf anders? Hat hier auf jeden
Fall jede Linie eine feste Dicke?
> Uebrigens verursacht die Aufloesungsabhaengigkeit die
> groessten Probleme, wenn man versucht, Ernst mit
> HiresBoundingBox zu machen. Man nehme nur am
> Rand mal einen Buchstaben mit Rundung, je nach
> Aufloesung erhaelt man dann eine andere "exakte"
> BoundingBox.
>
> Praktische Relevanz hat dies etwa, wenn man ungewoehnliche
> Symbole als PostScript-Grafiken verwenden moechte,
> oder allgemein, bei EPS-Dateien mit kleinen BoundingBoxen, die
> randfrei und womoeglich noch stark vergroessert eingesetzt
> werden sollen.
>
>> Und wenn an Auflösungen und so nichts geändert wird, müsste doch auch
>> kein Antialiasing gemacht werden, oder sehe ich da etwas falsch?
>> Was ist /prepress?
>
> ghostscript/7.xx/doc/Ps2pdf.htm
>
[...]
> An der Koordination versuche ich mich ja bereits. Durch provokante
> Kommentare hoffe ich ein "Problembewusstsein" zu schaffen.
Habe mich schon gewundert. :-)
> Das Tueckische am epstopdf-Problem ist, dass es auf den ersten
> Blicken ziemlich trivial aussieht. Wenn man aber dann die
> "Trivialitaeten" umzusetzen versucht und ein gutes, "korrektes"
> Ergebnis haben moechte, steht man schnell vor der Erkenntnis,
> dass dies in vielen Faellen gar nicht erreichbar sein kann.
Merke ich so langsam auch. Das Verhalten von epstopdf hat mir bisher
eigentlich recht gut gefallen, weil die Ausgabe normalerweise recht
nah an der Eingabedatei war. Nur ist ein sporadisches Rotieren der
Datei (was ja der Anfang dieser Diskussion war) etwas merkwürdig.
Da möchte ich nicht, dass gs für mich denkt.
> * Einsatzzweck, Benutzer, ...
Ich möchte meine eps-Bilder aus Gnuplot, Illustrator und einem
selbstgeschriebenen FE-Postprozessor unter latex und pdflatex nutzen
können, so dass die Ausdrucke (meist Papier) hinterher möglichst
identisch sind.
> * Welche Aufgaben/Funktionen?
> * Welche davon auf alle Faelle (Musskriterien)?
Konvertierung mit möglichst wenig Veränderung (so weit das möglich ist).
Falls nötig, optionale Angabe der Geräteauflösung.
> * Welche davon optional (Kannkriterien)?
Diese automatische Rotationsfunktion darf über eine Option
angschaltet werden können, ist aber echt nicht nötig. Drehen kann ich
auch von Hand. Ich denke, die Rotationsfunktion ist für PS-Dateien
machmal sinnvoll, für EPS eigentlich nicht.
> * Welche auf keinen Fall (Auschlusskriterien)?
??
> * Ueberlegungen zur Machbarkeit.
Ich denke, epstopdf ist gar nicht so weit von einer sehr guten Lösung
entfernt. Also ich denke, Machbarkeit ist gegeben.
> * Sammlung von Testdateien aufbauen.
Ich habe tausende (na ja, übertrieben). Die meisten sind aus den oben
genannten Programmen erzeugt. Gerade die aus meinem Postprozessor sind
recht anspruchvoll, da ausgiebig mit Schleifen und Verzweigungen
gearbeitet wird. Obwohl ich recht sicher bin, dass ich dem Postscript-
Standard entspreche, scheitert bspw. Illustrator 7.0 beim Einlesen.
> * Wie koennen Benutzerschnittstellen aussehen?
Was meinst Du damit genau? GUI?
Ich finde die Methode mit Kommandozeilenoption wie bisher super:
$ epstopdf [Optionen] <Eingabedatei> [<Ausgabedatei>]
Und Ausgabedatei ergibt sich als Default mit dem Namen der Eingabedatei
und ausgetauschter Erweiterung (also wie bisher).
Dadurch ist epstopdf auch in Makefiles sinnvoll zu verwenden.
Ob Windowsuser gerne eine GUI hätten, weiß ich nicht.
Gruß,
Heiko Oberdiek
> * Heiko Oberdiek <ober...@uni-freiburg.de> schrieb:
> > "Matthias Schwaiger" <matthias....@gmx.de> wrote:
>
> [...]
>
> "Such"-Reihenfolge IMHO:
>
> 1. Kommandozeile
> 2. aktuelles Verzeichnis
> 3. $HOME
> 4. /etc
>
> Ich würde überschreiben wählen. Also wenn Wert gesetzt dann bleibt er
> solange erhalten, bis man ihn in einer anderen Datei -- nach obiger
> Suchreihenfolge -- überschreibt.
Du meintest umgekehrt?
Also zuerst wird /etc/epstopdfrc gelesen, dann
$HOME/.epstopdfrc, wobei diese Datei dann Werte
aus /etc/epstopdfrc ueberschreibt.
> Nachteile:
>
> fällt mir momentan keiner ein. :-)
* Zusaetzlicher Verwaltungsaufwand fuer Konfigurationsdateien.
Man koennte auch alles ueber Optionen regeln und der
Benutzer definiert sich Aliase, Shellscripte, je nachdem
was das OS bietet.
* Aerger mit Betriebssystemabhaengigkeiten. Unter
Windows macht wohl "3. $HOME" wohl keinen Sinn
und "4. /etc" muesste wohl "%windows%/epstopdf.ini"
heissen, weiss aber nicht, ob das auch bei neueren
Windows-Versionen Sinn macht.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> On Fri, 16 Aug 2002 14:09:08 +0200, Heiko Oberdiek wrote:
> 0 setlinewidth ergibt eine Linie, die von dem verwendeten Ausgabegerät
> gerade noch dargestellt werden kann. Sie ist also auf einem 300dpi-Drucker
> vier mal so dick wie auf einem 1200dpi-Drucker.
> Ist beispielsweise hier das Verhalten von pdf anders? Hat hier auf jeden
> Fall jede Linie eine feste Dicke?
Ausprobieren, was Ghostscript/Distiller da machen.
Die "0" kann ja auch ein beliebiger berechneter
Wert in Abhaengigkeit der Aufloesung sein,
spaetestens das wird dann bei der PDF-Berechnung
festgeklopft.
Auch verschiebt epstopdf das Bild in den
Ursprung. Die BoundingBox-Angaben
als ganze bp-Groessen sind aber ziemlich
ungenau. Es kann einen Rand von fast
1bp Breite geben. Ist die Verschiebung
keine ganzzahlige, bezogen auf die Pixel,
kann andererseits die obere linke Ecke
des Bildes nach der Verschiebung anstatt
auf den Ursprung zu fallen auch ins Negative
rutschen, so dass nach Clipping Pixelreihen
fehlen. Eine Einbeziehung der HiresBoundingBox
verschaerft dabei die aufloesungsabhaengigen
Probleme.
> Merke ich so langsam auch. Das Verhalten von epstopdf hat mir bisher
> eigentlich recht gut gefallen, weil die Ausgabe normalerweise recht
> nah an der Eingabedatei war. Nur ist ein sporadisches Rotieren der
> Datei (was ja der Anfang dieser Diskussion war) etwas merkwürdig.
> Da möchte ich nicht, dass gs für mich denkt.
Und ein anderer wundert sich, dass er die PDF-Datei in
der LaTeX-Datei drehen muss ...
> > * Einsatzzweck, Benutzer, ...
>
> Ich möchte meine eps-Bilder aus Gnuplot, Illustrator und einem
> selbstgeschriebenen FE-Postprozessor unter latex und pdflatex nutzen
> können, so dass die Ausdrucke (meist Papier) hinterher möglichst
> identisch sind.
Rufst du epstopdf per Hand auf, ist es Teil eines anderen Programms,
laeuft es als Filter ,...?
> > * Welche Aufgaben/Funktionen?
> > * Welche davon auf alle Faelle (Musskriterien)?
>
> Konvertierung mit möglichst wenig Veränderung (so weit das möglich ist).
> Falls nötig, optionale Angabe der Geräteauflösung.
Ich habe hier im Thread ein Beispielsszenario gegeben, wie wuerdest
du hier etwa "wenig Veraenderung" definieren?
> > * Welche davon optional (Kannkriterien)?
>
> Diese automatische Rotationsfunktion darf über eine Option
> angschaltet werden können, ist aber echt nicht nötig. Drehen kann ich
> auch von Hand. Ich denke, die Rotationsfunktion ist für PS-Dateien
> machmal sinnvoll, für EPS eigentlich nicht.
Viele EPS-Dateien werden "gedreht"/"landscape" erstellt.
> > * Welche auf keinen Fall (Auschlusskriterien)?
>
> ??
* Keine Preview-Erzeugung.
Oder soll epstopdf zu einer eierlegenden Wollmilchsau werden
und gleich Programme wie "ps2pdf" oder "ps2epsi" ersetzen?
Oder wie sieht es aus mit PS-Dateien, die aus mehreren
Seiten bestehen und das Ergebnis soll eine PDF-Datei
mit gleicher Seitenzahl sein. Jede Seite ist dann entsprechend
der Seiten-BoundingBox angepasst.
> > * Ueberlegungen zur Machbarkeit.
>
> Ich denke, epstopdf ist gar nicht so weit von einer sehr guten Lösung
> entfernt. Also ich denke, Machbarkeit ist gegeben.
Damit meine ich etwa, kann man die Verschiebung zum
Ursprung ganz genau hinbekommen, etwa unter
Einbeziehung der HiresBoundingBox/ExactBoundingBox?
> > * Sammlung von Testdateien aufbauen.
>
> Ich habe tausende (na ja, übertrieben). Die meisten sind aus den oben
> genannten Programmen erzeugt.
Die Quantitaet interessiert nicht, geeigneter sind moeglichst
kleine Repraesentanten fuer Problemfaelle (Autorotation,
HiresBoundingBox, ...) oder Arten von EPS (Verwendung
von setpagedevice in der Praxis, ...)
> > * Wie koennen Benutzerschnittstellen aussehen?
>
> Was meinst Du damit genau? GUI?
Ja, beispielsweise spreche ich ins Mikrofon
"Liebes epstopdf, bitte nun keine Autorotation."
oder muss ich dass in die Tastatur eingeben:
epstopdf -XAR (kryptisch)
epstopdf --Option-die-Autorotation-abstellt (lang)
oder was schert epstopdf die genaue Ghostscript-Optionenbezeichnung?
epstopdf --gsoptions=-dAutoRotatePages=/None
oder ...
> Ob Windowsuser gerne eine GUI hätten, weiß ich nicht.
Wenn epstopdf eine eierlegende Wollmilchsau mit tausend
Optionen und Einstellmoeglichkeiten wird, waere eine GUI,
die dann etwa auch gleich EPS-Original und PDF-Ergebnis
anzeigt, nicht unbedingt schlecht.
Wenn epstopdf aber minimalistisch verstanden wird,
quasi als kleines wohldefiniertes Glied einer Verarbeitungskette,
etwa
generateps | correctlineendings | epstopdf >ausgabe.pdf
ist eine GUI dann mit Kanonen auf Spatzen geschossen.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Mark Trettin
* Heiko Oberdiek <ober...@uni-freiburg.de> schrieb:
> Mark Trettin <mtr-...@gmx.de> wrote:
[...]
>> 1. Kommandozeile
>> 2. aktuelles Verzeichnis
>> 3. $HOME
>> 4. /etc
>>
>> Ich würde überschreiben wählen. Also wenn Wert gesetzt dann bleibt er
>> solange erhalten, bis man ihn in einer anderen Datei -- nach obiger
>> Suchreihenfolge -- überschreibt.
> Du meintest umgekehrt?
Ja.
> Also zuerst wird /etc/epstopdfrc gelesen, dann
> $HOME/.epstopdfrc, wobei diese Datei dann Werte
> aus /etc/epstopdfrc ueberschreibt.
Richtig, ich habe mich unklar ausgedrückt. Ich meinte oben
precedence, das Einlesen muß also andersrum geschehen.
>> Nachteile:
>>
>> fällt mir momentan keiner ein. :-)
> * Zusaetzlicher Verwaltungsaufwand fuer Konfigurationsdateien.
> Man koennte auch alles ueber Optionen regeln und der
> Benutzer definiert sich Aliase, Shellscripte, je nachdem
> was das OS bietet.
Jain. Man kann alles in /etc/epstopdfrc schreiben und nur zusätzlich
(bei Bedarf) lokale Dateien anlegen oder Kommandozeilenoptionen
übgergeben.
> * Aerger mit Betriebssystemabhaengigkeiten.
Das ist natürlich ein Problem...
> Unter Windows macht wohl "3. $HOME" wohl keinen Sinn
Es gibt doch (bei den NTen¹) auch Benutzerverzeichnisse für die einzelnen
Programm-Konfigurationen, oder? Ich meine die sind dann irgendwie unter
C:\windows\...\Benutzername\... Bei den Spielzeugversionen müsste dann
evtl. rausfallen. Da müsste mal ein Windowsfachmann etwas zu sagen.
> und "4. /etc" muesste wohl "%windows%/epstopdf.ini" heissen, weiss
> aber nicht, ob das auch bei neueren Windows-Versionen Sinn macht.
Hm, ich kenne mich mit Windows nicht mehr wirklich aus, aber dort
sollte eine Systemweite Konfig + User Konfig möglich sein?
Bis dann
Mark
______________
¹ NT, 2000, eXPerimental
--
Mark Trettin ------- *Aachen* -- Wo ist das? ------> N: 50°46' O: 06°05'
FdI 121: NOP
Seiteneffektfreies Takte verbraten. (Ingo Augsten)
Markus Kohm
> Unter
> Windows macht wohl "3. $HOME" wohl keinen Sinn
Wieso das? Natürlich macht das unter Windows Sinn!
Markus
--
Fragen zu LaTeX? --> http://www.dante.de/faq/de-tex-faq/
Fragen zu KOMA-Script? --> scrguide
Lust zur Mitarbeit? --> http://koma-script.net.tf
Fragen zur Person? --> http://kohm.de.tf
Harald Harders
> Harald Harders <h.ha...@tu-bs.de> wrote:
[...]
>> 0 setlinewidth ergibt eine Linie, die von dem verwendeten Ausgabegerät
>> gerade noch dargestellt werden kann. Sie ist also auf einem 300dpi-Drucker
>> vier mal so dick wie auf einem 1200dpi-Drucker.
>> Ist beispielsweise hier das Verhalten von pdf anders? Hat hier auf jeden
>> Fall jede Linie eine feste Dicke?
>
> Ausprobieren, was Ghostscript/Distiller da machen.
> Die "0" kann ja auch ein beliebiger berechneter
> Wert in Abhaengigkeit der Aufloesung sein,
> spaetestens das wird dann bei der PDF-Berechnung
> festgeklopft.
Alles klar.
> Auch verschiebt epstopdf das Bild in den
> Ursprung. Die BoundingBox-Angaben
> als ganze bp-Groessen sind aber ziemlich
> ungenau. Es kann einen Rand von fast
> 1bp Breite geben. Ist die Verschiebung
> keine ganzzahlige, bezogen auf die Pixel,
> kann andererseits die obere linke Ecke
> des Bildes nach der Verschiebung anstatt
> auf den Ursprung zu fallen auch ins Negative
> rutschen, so dass nach Clipping Pixelreihen
> fehlen. Eine Einbeziehung der HiresBoundingBox
> verschaerft dabei die aufloesungsabhaengigen
> Probleme.
Das ist natürlich ein Problem, das ich noch nicht bedacht habe.
>> Merke ich so langsam auch. Das Verhalten von epstopdf hat mir bisher
>> eigentlich recht gut gefallen, weil die Ausgabe normalerweise recht
>> nah an der Eingabedatei war. Nur ist ein sporadisches Rotieren der
>> Datei (was ja der Anfang dieser Diskussion war) etwas merkwürdig.
>> Da möchte ich nicht, dass gs für mich denkt.
>
> Und ein anderer wundert sich, dass er die PDF-Datei in
> der LaTeX-Datei drehen muss ...
Das glaube ich nicht. Wenn er \includegraphics nutzt und latex und
pdflatex nutzt, muss er es dann in latex nicht drehen und in pdflatex
doch. Das ist doch wirklich komisch.
>> > * Einsatzzweck, Benutzer, ...
>>
>> Ich möchte meine eps-Bilder aus Gnuplot, Illustrator und einem
>> selbstgeschriebenen FE-Postprozessor unter latex und pdflatex nutzen
>> können, so dass die Ausdrucke (meist Papier) hinterher möglichst
>> identisch sind.
>
> Rufst du epstopdf per Hand auf, ist es Teil eines anderen Programms,
> laeuft es als Filter ,...?
Meist habe ich epstopdf in einem Makefile stehen, das das Programm auf
eine eps-Datei (also nicht als Filter) anwendet. Die Anwendung als Filter
finde ich aber auch praktisch. Es ist also so, dass ich nur relativ
selten epstopdf von Hand aufrufe.
>> > * Welche Aufgaben/Funktionen?
>> > * Welche davon auf alle Faelle (Musskriterien)?
>>
>> Konvertierung mit möglichst wenig Veränderung (so weit das möglich ist).
>> Falls nötig, optionale Angabe der Geräteauflösung.
>
> Ich habe hier im Thread ein Beispielsszenario gegeben, wie wuerdest
> du hier etwa "wenig Veraenderung" definieren?
Ich würde das Verhalten von ps2pdf als unschön bezeichnen. Jetzt verstehe
ich auch endlich, warum ich solche Effekte mal in einem Foliensatz für
einen Vortrag hatte, als ich es noch mit tex->dvi->ps->pdf gemacht habe.
Ich habe es nie verstanden, dass die eine Folie überkopf war. Jetzt
weiß ich warum. pdflatex hat das Verhalten gezeigt, das ich erwartet
hatte, nämlich alle Folien normal orientiert.
ps2pdf ruft sicherlich auch gs auf, und man kann das ganze mit der
Option, die Autorotate verhindert, koppeln. Und wenn man jetzt in das
Szenario aus Deinem Posting noch folgendes einbaut, sieht es schon
anders aus (falls das so mit den Optionen geht):
latex test
dvips test
GS_OPTIONS=-dAutoRotatePages=/None ps2pdf test.ps
Denn das entspricht dann genau folgendem:
GS_OPTIONS=-dAutoRotatePages=/None epstopdf rot.eps
pdflatex test
Und diese beiden Versionen sind das, was ich von dem Code erwarten
würde und was ich ja auch bei latex test && dvips test in ghostview
sehe.
>> > * Welche davon optional (Kannkriterien)?
>>
>> Diese automatische Rotationsfunktion darf über eine Option
>> angschaltet werden können, ist aber echt nicht nötig. Drehen kann ich
>> auch von Hand. Ich denke, die Rotationsfunktion ist für PS-Dateien
>> machmal sinnvoll, für EPS eigentlich nicht.
>
> Viele EPS-Dateien werden "gedreht"/"landscape" erstellt.
Aber dass gs versucht, anhand der Menge Text, die in eine Richtung
geschrieben ist, zu erkennen, ob es meine Datei drehen soll oder nicht,
finde ich merkwürdig.
Und wenn ich eine Datei gedreht erzeuge, weiß ich es, und dann kann
ich auch eine Option zum drehen angeben, finde ich.
Und auch da denke ich, dass es dann unpraktisch ist, wenn eine Datei
einmal mit latex und einmal mit pdflatex übersetzt wird, dass das
Bild einmal so und einmal anders orientiert ist.
>> > * Welche auf keinen Fall (Auschlusskriterien)?
>>
>> ??
>
> * Keine Preview-Erzeugung.
>
> Oder soll epstopdf zu einer eierlegenden Wollmilchsau werden
> und gleich Programme wie "ps2pdf" oder "ps2epsi" ersetzen?
Preview finde ich unnötig.
> Oder wie sieht es aus mit PS-Dateien, die aus mehreren
> Seiten bestehen und das Ergebnis soll eine PDF-Datei
> mit gleicher Seitenzahl sein. Jede Seite ist dann entsprechend
> der Seiten-BoundingBox angepasst.
Finde ich auch unnötig.
>> > * Ueberlegungen zur Machbarkeit.
>>
>> Ich denke, epstopdf ist gar nicht so weit von einer sehr guten Lösung
>> entfernt. Also ich denke, Machbarkeit ist gegeben.
>
> Damit meine ich etwa, kann man die Verschiebung zum
> Ursprung ganz genau hinbekommen, etwa unter
> Einbeziehung der HiresBoundingBox/ExactBoundingBox?
Ach so. Über die Boundingbox habe ich mir zu wenig Gedanken gemacht, um
da eine Aussage machen zu können.
>> > * Sammlung von Testdateien aufbauen.
>>
>> Ich habe tausende (na ja, übertrieben). Die meisten sind aus den oben
>> genannten Programmen erzeugt.
>
> Die Quantitaet interessiert nicht, geeigneter sind moeglichst
> kleine Repraesentanten fuer Problemfaelle (Autorotation,
> HiresBoundingBox, ...) oder Arten von EPS (Verwendung
> von setpagedevice in der Praxis, ...)
Für Autorotation habe ich ein Beispiel. Dann welche, die relativ viele
Programmiersprachenelemente verwenden. Soll ich die irgendwo zum
Download bereitstellen, dass eine Datenbank aufgebaut werden kann?
>> > * Wie koennen Benutzerschnittstellen aussehen?
>>
>> Was meinst Du damit genau? GUI?
>
> Ja, beispielsweise spreche ich ins Mikrofon
> "Liebes epstopdf, bitte nun keine Autorotation."
> oder muss ich dass in die Tastatur eingeben:
> epstopdf -XAR (kryptisch)
> epstopdf --Option-die-Autorotation-abstellt (lang)
> oder was schert epstopdf die genaue Ghostscript-Optionenbezeichnung?
> epstopdf --gsoptions=-dAutoRotatePages=/None
> oder ...
Ich denke, es ist nicht sinnvoll, dass epstopdf alle möglichen Optionen
an gs weiterreicht, da ja manche im Zusammenhang mit epstopdf unsinnig
wären. Und da die Optionen von gs oft etwas merkwürdig sind, würde ich
es bevorzugen, eigene (sprechende) Optionen einzuführen, beispielsweise
epstopdf -noautorotate
oder so.
>> Ob Windowsuser gerne eine GUI hätten, weiß ich nicht.
>
> Wenn epstopdf eine eierlegende Wollmilchsau mit tausend
> Optionen und Einstellmoeglichkeiten wird, waere eine GUI,
> die dann etwa auch gleich EPS-Original und PDF-Ergebnis
> anzeigt, nicht unbedingt schlecht.
> Wenn epstopdf aber minimalistisch verstanden wird,
> quasi als kleines wohldefiniertes Glied einer Verarbeitungskette,
> etwa
> generateps | correctlineendings | epstopdf >ausgabe.pdf
> ist eine GUI dann mit Kanonen auf Spatzen geschossen.
Ich würde epstopdf eher minimalistisch halten. Und dann natürlich auch auf
eine GUI verzichten. Außerdem würde die auch wieder große Probleme
bei der Portierbarkeit bereiten.
Ich habe noch einen Vorschlag:
Sollten wir nicht ein Projekt auf sourceforge.net einrichten, in dem
die Vorschläge, Beispieldateien etc. gesammelt werden können?
Viele Grüße
Heiko Oberdiek
> On Sat, 17 Aug 2002 14:06:16 +0200, Heiko Oberdiek wrote:
>
> > Und ein anderer wundert sich, dass er die PDF-Datei in
> > der LaTeX-Datei drehen muss ...
>
> Das glaube ich nicht. Wenn er \includegraphics nutzt und latex und
> pdflatex nutzt, muss er es dann in latex nicht drehen und in pdflatex
> doch. Das ist doch wirklich komisch.
Es gibt auch Leute, die verwenden *nur* pdflatex.
> ps2pdf ruft sicherlich auch gs auf, und man kann das ganze mit der
> Option, die Autorotate verhindert, koppeln. Und wenn man jetzt in das
> Szenario aus Deinem Posting noch folgendes einbaut, sieht es schon
> anders aus (falls das so mit den Optionen geht):
>
> latex test
> dvips test
> GS_OPTIONS=-dAutoRotatePages=/None ps2pdf test.ps
Oder
ps2pdf -dAutoRotatePages=/None test.ps
Da ps2pdf Optionen an Ghostscript durchreicht.
> >> > * Welche davon optional (Kannkriterien)?
> >>
> >> Diese automatische Rotationsfunktion darf über eine Option
> >> angschaltet werden können, ist aber echt nicht nötig. Drehen kann ich
> >> auch von Hand. Ich denke, die Rotationsfunktion ist für PS-Dateien
> >> machmal sinnvoll, für EPS eigentlich nicht.
> >
> > Viele EPS-Dateien werden "gedreht"/"landscape" erstellt.
>
> Aber dass gs versucht, anhand der Menge Text, die in eine Richtung
> geschrieben ist, zu erkennen, ob es meine Datei drehen soll oder nicht,
> finde ich merkwürdig.
AFAIK kopiert hier gs lediglich das Verhalten vom Distiller.
Uebrigens ein anderer Punkt, epstopdf gibt auch PostScript
aus, damit dieser vom Distiller verarbeitet werden kann.
Dann erhebt sich die Frage, ob Ghostscript-Optionen dann
besser zu PostScript-Code werden sollen, damit sie vom
Distiller verstanden werden.
> >> > * Welche auf keinen Fall (Auschlusskriterien)?
> >
> > * Keine Preview-Erzeugung.
> >
> > Oder soll epstopdf zu einer eierlegenden Wollmilchsau werden
> > und gleich Programme wie "ps2pdf" oder "ps2epsi" ersetzen?
>
> Preview finde ich unnötig.
Die Frage ist, ob epstopdf beispielsweise "ps2epsi" ersetzen darf
(Kannkriterium) oder auf keinen Fall (Ausschlusskriterium).
> > Oder wie sieht es aus mit PS-Dateien, die aus mehreren
> > Seiten bestehen und das Ergebnis soll eine PDF-Datei
> > mit gleicher Seitenzahl sein. Jede Seite ist dann entsprechend
> > der Seiten-BoundingBox angepasst.
>
> Finde ich auch unnötig.
Man erstellt eine .tex-Datei mit vielen pstricks-Grafiken,
laesst einmal latex, dvips und epstopdf darueber laufen.
> >> > * Sammlung von Testdateien aufbauen.
> >>
> >> Ich habe tausende (na ja, übertrieben). Die meisten sind aus den oben
> >> genannten Programmen erzeugt.
> >
> > Die Quantitaet interessiert nicht, geeigneter sind moeglichst
> > kleine Repraesentanten fuer Problemfaelle (Autorotation,
> > HiresBoundingBox, ...) oder Arten von EPS (Verwendung
> > von setpagedevice in der Praxis, ...)
>
> Für Autorotation habe ich ein Beispiel. Dann welche, die relativ viele
> Programmiersprachenelemente verwenden. Soll ich die irgendwo zum
> Download bereitstellen, dass eine Datenbank aufgebaut werden kann?
> >> > * Wie koennen Benutzerschnittstellen aussehen?
> >>
> >> Was meinst Du damit genau? GUI?
> >
> > Ja, beispielsweise spreche ich ins Mikrofon
> > "Liebes epstopdf, bitte nun keine Autorotation."
> > oder muss ich dass in die Tastatur eingeben:
> > epstopdf -XAR (kryptisch)
> > epstopdf --Option-die-Autorotation-abstellt (lang)
> > oder was schert epstopdf die genaue Ghostscript-Optionenbezeichnung?
> > epstopdf --gsoptions=-dAutoRotatePages=/None
> > oder ...
>
> Ich denke, es ist nicht sinnvoll, dass epstopdf alle möglichen Optionen
> an gs weiterreicht, da ja manche im Zusammenhang mit epstopdf unsinnig
> wären.
Das laege dann in der Verantwortung des Benutzers.
> Und da die Optionen von gs oft etwas merkwürdig sind, würde ich
> es bevorzugen, eigene (sprechende) Optionen einzuführen, beispielsweise
> epstopdf -noautorotate
> oder so.
Nachteile:
* Viele neue Namen
* Viele Optionen, man vergisst sicher welche und neuere gs-Versionen
koennen wieder neue anbieten.
> >> Ob Windowsuser gerne eine GUI hätten, weiß ich nicht.
> >
> > Wenn epstopdf eine eierlegende Wollmilchsau mit tausend
> > Optionen und Einstellmoeglichkeiten wird, waere eine GUI,
> > die dann etwa auch gleich EPS-Original und PDF-Ergebnis
> > anzeigt, nicht unbedingt schlecht.
> > Wenn epstopdf aber minimalistisch verstanden wird,
> > quasi als kleines wohldefiniertes Glied einer Verarbeitungskette,
> > etwa
> > generateps | correctlineendings | epstopdf >ausgabe.pdf
> > ist eine GUI dann mit Kanonen auf Spatzen geschossen.
>
> Ich würde epstopdf eher minimalistisch halten.
Das ist aber dann ein Widerspruch zum Punkt "Optionen"
weiter oben?
> Und dann natürlich auch auf
> eine GUI verzichten. Außerdem würde die auch wieder große Probleme
> bei der Portierbarkeit bereiten.
Java als Beispiel.
> Ich habe noch einen Vorschlag:
> Sollten wir nicht ein Projekt auf sourceforge.net einrichten, in dem
> die Vorschläge, Beispieldateien etc. gesammelt werden können?
Ja und Nein.
Ja:
* Infrastruktur: Space, Mailingliste, CVS, ...
Nein:
* Man richtet mit grossem Tamtam das Projekt ein,
und dann "stirbt" es nach kurzer Zeit oder es
sind hoechstes zwei, drei Leute beteiligt.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Harald Harders
> Harald Harders <h.ha...@tu-bs.de> wrote:
[...]
>> > Und ein anderer wundert sich, dass er die PDF-Datei in
>> > der LaTeX-Datei drehen muss ...
>>
>> Das glaube ich nicht. Wenn er \includegraphics nutzt und latex und
>> pdflatex nutzt, muss er es dann in latex nicht drehen und in pdflatex
>> doch. Das ist doch wirklich komisch.
>
> Es gibt auch Leute, die verwenden *nur* pdflatex.
Stimmt. Ich glaube, bei dem einen Punkt werden wir uns nicht einigen
können: Wenn ich ein Bild in einer Orientierung als eps habe, möchte ich
es, wenn ich nichts anderes sage, auch als pdf in der gleichen
Orientierung haben. Eine Rotation bei der Konvertierung auf Verlangen ist
natürlich ok.
[...]
>> >> > * Welche auf keinen Fall (Auschlusskriterien)?
>> >
>> > * Keine Preview-Erzeugung.
>> >
>> > Oder soll epstopdf zu einer eierlegenden Wollmilchsau werden
>> > und gleich Programme wie "ps2pdf" oder "ps2epsi" ersetzen?
>>
>> Preview finde ich unnötig.
>
> Die Frage ist, ob epstopdf beispielsweise "ps2epsi" ersetzen darf
> (Kannkriterium) oder auf keinen Fall (Ausschlusskriterium).
Solange epstopdf ein von ps2epsi erzeugtes Preview nicht löscht, muss
es das wirklich nicht noch können (ich weiß, ein unixmäßiger Ansatz,
der in der Windowswelt wohl meist anders gesehen wird).
>> > Oder wie sieht es aus mit PS-Dateien, die aus mehreren
>> > Seiten bestehen und das Ergebnis soll eine PDF-Datei
>> > mit gleicher Seitenzahl sein. Jede Seite ist dann entsprechend
>> > der Seiten-BoundingBox angepasst.
>>
>> Finde ich auch unnötig.
>
> Man erstellt eine .tex-Datei mit vielen pstricks-Grafiken,
> laesst einmal latex, dvips und epstopdf darueber laufen.
Klingt dann natürlich nicht schlecht. Aber gibt es nicht ein Tool, das
einzelne Seiten extrahiert? Dann könnte man doch das vorschalten. Ich habe
halt nur Angst, dass es nichts wird, wenn zuviel in epstopdf hineingepackt
wird.
Mir ist also ein kleines Tool lieber, das dann aber richtig funktioniert,
als ein großes Tool, das nie fertig wird.
>> >> > * Sammlung von Testdateien aufbauen.
[...]
>> Und dann natürlich auch auf
>> eine GUI verzichten. Außerdem würde die auch wieder große Probleme
>> bei der Portierbarkeit bereiten.
>
> Java als Beispiel.
Auf jeden Fall muss epstopdf auch Kommandozeilen verarbeiten können und
dann nicht ständig ein Fenster aufmachen. Und es sollte so schnell wie
möglich sein, weil es sonst im Batchbetrieb sehr nervig werden kann.
Dann würde ich eher an eine GUI denken, die dann im Hintergrund ein
einfaches epstopdf-Kommandozeilentool aufruft.
>> Ich habe noch einen Vorschlag:
>> Sollten wir nicht ein Projekt auf sourceforge.net einrichten, in dem
>> die Vorschläge, Beispieldateien etc. gesammelt werden können?
>
> Ja und Nein.
> Ja:
> * Infrastruktur: Space, Mailingliste, CVS, ...
> Nein:
> * Man richtet mit grossem Tamtam das Projekt ein,
> und dann "stirbt" es nach kurzer Zeit oder es
> sind hoechstes zwei, drei Leute beteiligt.
Stimmt. Aber welche Alternative zur Verwaltung haben wir?
Michael Schmidt
> Mark Trettin <mtr-...@gmx.de> wrote:
>
>> Nachteile:
>>
>> fällt mir momentan keiner ein. :-)
>
> * Zusaetzlicher Verwaltungsaufwand fuer Konfigurationsdateien.
> Man koennte auch alles ueber Optionen regeln und der
> Benutzer definiert sich Aliase, Shellscripte, je nachdem
> was das OS bietet.
Das ist ja nur der Aufwand des Nutzers, und der wird ja von niemendem
gezwungen. -> PAL
>
> * Aerger mit Betriebssystemabhaengigkeiten. Unter
> Windows macht wohl "3. $HOME" wohl keinen Sinn
> und "4. /etc" muesste wohl "%windows%/epstopdf.ini"
> heissen, weiss aber nicht, ob das auch bei neueren
> Windows-Versionen Sinn macht.
$HOME heisst unter Win zwar anders, ist aber unter 9x "Eigene Dateien"
unter NT in winnt\profiles\... Das /etc/epstopdfrc kann man nach
$TEXMF_HOME/etc verschieben, da würde ich zumindest sowieso eher suchen.
Um das .ini-Suffix kommt man wohl nicht wirklich herum.
--
Michael Schmidt
Michael Schmidt
> On Mon, 19 Aug 2002 11:25:44 +0200, Heiko Oberdiek wrote:
>> Java als Beispiel.
>
> Auf jeden Fall muss epstopdf auch Kommandozeilen verarbeiten können
> und dann nicht ständig ein Fenster aufmachen. Und es sollte so schnell
> wie möglich sein, weil es sonst im Batchbetrieb sehr nervig werden
> kann. Dann würde ich eher an eine GUI denken, die dann im Hintergrund
> ein einfaches epstopdf-Kommandozeilentool aufruft.
Wie wäre es mit der typischen Unix-Philosophie:
ein Kommandozeilentool und eine GUI-Programm, das das Toll mit den
entsprechenden Parametern aufruft. (Das kann dann auch jemand anders
schreiben...)
>>> Ich habe noch einen Vorschlag:
>>> Sollten wir nicht ein Projekt auf sourceforge.net einrichten, in dem
>>> die Vorschläge, Beispieldateien etc. gesammelt werden können?
>>
>> Ja und Nein.
>> Ja:
>> * Infrastruktur: Space, Mailingliste, CVS, ...
>> Nein:
>> * Man richtet mit grossem Tamtam das Projekt ein,
>> und dann "stirbt" es nach kurzer Zeit oder es
>> sind hoechstes zwei, drei Leute beteiligt.
>
> Stimmt. Aber welche Alternative zur Verwaltung haben wir?
Ich habe sowieso einen sourceforge account, wenn ihr mir sagt, unter
welcher Lizenz das Ding stehen soll, ist das Projekt schnell
eingerichtet.
--
Michael Schmidt
Frank Fürst
> Harald Harders wrote:
> > Moin moin,
> > ich habe ein Problem mit epstopdf, nämlich die Tatsache, dass es mir
> > eine EPS-Datei bei der Umwandlung in PDF rotiert. Ich weiß nun
Gerade das selbe Problem gehabt, an den Thread erinnert und die Antwort
gelesen.
> > Bei der EPS-Datei handelt es sich um eine von gnuplot erzeugte Datei,
> > in der relativ viel vertikaler Text enthalten ist.
Bei mir ist es Grace, und soviel vertikaler Text ist es gar
nicht. Jedenfalls ist da deutlich mehr "normaler".
>
> Hatte das Problem letztens auch. Die Programme sind einfach "zu
> intelligent" ;-( Heiko hatte (wie so oft) die Lösung:
>
> Aufruf (zumindest unter Unix):
>
> GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
Und das bewirkt bei mir leider nichts, das Bild ist immer noch
rotiert. gs-Version ist 7.04 (aladdin). Ansonsten finde ich nichts über
rotieren.
Ich kann die Datei natürlich einfach in der LaTeX-Datei zurückrotieren,
notfalls mit ifpdf. Aber eigentlich...
Woher könnte denn das kommen?
Gruß, Frank
--
[Gesucht war ein MTA für Massenmailing]
Aus Stabilitätsgründen würde ich es allerdings vorziehen, wenn als
Server-OS nicht Debian-Linux sondern Windows-95 verwendet wird.
[Elmar Haneke in debian-user-de@]
Gerrit Kirpal
Hi,
> Harald Harders wrote:
>
> > On Mon, 19 Aug 2002 11:25:44 +0200, Heiko Oberdiek wrote:
> >> Java als Beispiel.
> >
> > Auf jeden Fall muss epstopdf auch Kommandozeilen verarbeiten können
> > und dann nicht ständig ein Fenster aufmachen. Und es sollte so schnell
> > wie möglich sein, weil es sonst im Batchbetrieb sehr nervig werden
> > kann. Dann würde ich eher an eine GUI denken, die dann im Hintergrund
> > ein einfaches epstopdf-Kommandozeilentool aufruft.
> Wie wäre es mit der typischen Unix-Philosophie:
> ein Kommandozeilentool und eine GUI-Programm, das das Toll mit den
> entsprechenden Parametern aufruft. (Das kann dann auch jemand anders
> schreiben...)
Ich bewege mich in der Windows-Welt, wo quasi sehr viel GUI ist. TeX
selbst und etliche Programme um TeX herum laufen in der DOS-Box und
ich habe mich daran gewöhnt. Also, ich kann auf eine GUI für Windows
verzichten, zumal das Problem von Windows eben GUI ist. Ich denke auch
zugunsten der Stabilität sollte ein Kommandozeilen-Programm her.
[...]
Gruß, Gerrit
Heiko Oberdiek
> Rolf Niepraschk <Rolf.Ni...@ptb.de> schrieb:
>
> > Harald Harders wrote:
> > > Moin moin,
> > > ich habe ein Problem mit epstopdf, nämlich die Tatsache, dass es mir
> > > eine EPS-Datei bei der Umwandlung in PDF rotiert. Ich weiß nun
>
> Gerade das selbe Problem gehabt, an den Thread erinnert und die Antwort
> gelesen.
> [...]
> > GS_OPTIONS=-dAutoRotatePages=/None epstopdf --outfile=foo.pdf foo.eps
>
> Und das bewirkt bei mir leider nichts, das Bild ist immer noch
> rotiert. gs-Version ist 7.04 (aladdin). Ansonsten finde ich nichts über
> rotieren.
EPS-Dateien koennen auch einen %%Orientation-DSC-Kommentar
haben, der die Grafik als Landscape kennzeichnet, dann rotiert
Ghostscript ebenfalls. Abhilfe:
ParseDSCComments=/false
Aber ich wiederhole mich, wenn ich sage, dass es viele
Ghostscript-Optionen gibt, die einen Einfluss auf die
Ausgangs-PDF-Datei nehmen.
Kann sich jemand mal die Muehe machen, sich durch diese
Optionen und Einstellungen hindurchzuarbeiten und aufzulisten,
welche etwa das Ausgabeformat, welche die Ausgabequalitaet
und so weiter beeinflussen?
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Michael Schmidt <nonsense...@bigfoot.do-not-type.de> wrote in message news:<j7tvja...@Neil.local>...
>
> Ich bewege mich in der Windows-Welt, wo quasi sehr viel GUI ist. TeX
> selbst und etliche Programme um TeX herum laufen in der DOS-Box und
> ich habe mich daran gewöhnt. Also, ich kann auf eine GUI für Windows
> verzichten, zumal das Problem von Windows eben GUI ist. Ich denke auch
> zugunsten der Stabilität sollte ein Kommandozeilen-Programm her.
Da epstopdf in Skripten, Makefiles etc. Verwendung findet und
viele das Kommandozeilen-Interface bevorzugen werden,
denke ich, dass keiner die Kommandozeilen-Version
abschaffen will.
Wenn epstopdf eher minimalistisch bleibt, duerfte es wohl
auch keine richtigen Bedarf fuer eine GUI geben.
Aber wie wenn man den Leuten den kleinen Finger
gibt, wollen sie dann die ganze Hand. Also wenn epstopdf
um tausend Optionen angereichtert wird, wird es schwer,
die Uebersicht zu behalten, so dass eine GUI helfen
koennte.
Eine GUI koennte, wenn sie etwa Quelle und Ziel
darstellen kann, dabei helfen die Berechnung der
BoundingBox zu kontrollieren. Das Problem des
"bbox"-Devices von Ghostscript ist etwa, dass es
die BoundingBox nur innerhalb der gegebenen
Papiergroesse berechnet und die ist oft nicht
bekannt.
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Heiko Oberdiek
> Heiko Oberdiek wrote:
>
> > * Aerger mit Betriebssystemabhaengigkeiten. Unter
> > Windows macht wohl "3. $HOME" wohl keinen Sinn
> > und "4. /etc" muesste wohl "%windows%/epstopdf.ini"
> > heissen, weiss aber nicht, ob das auch bei neueren
> > Windows-Versionen Sinn macht.
>
> $HOME heisst unter Win zwar anders, ist aber unter 9x "Eigene Dateien"
AFAIK gibt es unter Win die Umgebungsvariable HOME
standardmaessig nicht. Vielleicht hat sich das bei
neueren Versionen geaendert.
Der "Ordner" "Eigene Dateien" jedenfalls ist nicht
benutzerspezifisch und duerfte von den wenigsten
Programmen nach .ini-Dateien durchsucht werden.
> unter NT in winnt\profiles\... Das /etc/epstopdfrc kann man nach
> $TEXMF_HOME/etc verschieben, da würde ich zumindest sowieso eher suchen.
> Um das .ini-Suffix kommt man wohl nicht wirklich herum.
epstopdf ist zwar ein Programm, das wohl hauptsaechlich
im pdf(TeX)-Umfeld genutzt wird, dennoch hat es eigentlich
nichts mit TeX zu tun und wuerde es zu den Support/Tool-
Programmen zaehlen, wie etwa Ghostscript, ...
Viele Gruesse
Heiko <ober...@uni-freiburg.de>
Michael Schmidt
> AFAIK gibt es unter Win die Umgebungsvariable HOME
> standardmaessig nicht. Vielleicht hat sich das bei
> neueren Versionen geaendert.
> Der "Ordner" "Eigene Dateien" jedenfalls ist nicht
> benutzerspezifisch und duerfte von den wenigsten
> Programmen nach .ini-Dateien durchsucht werden.
Win 9x kennt so etwas wie Benutzer ja auch nicht wirklich, das ist eher
ein Workaround in der Netzwerkumgebung, aber der Registryeintrag
"ownfiles" oder so ähnlich verweist auf ein Verzeichnis, in dem der
Benutzer eigene Dateien ablegt, dem Gedanken nach so etwas wie $HOME.
Dass da kein Programm sucht, dürfte daran liegen, dass die meisten
(kommerziellen) Win-Programmierer "single user" denken. Selbst Netscape
bekommt es nicht hin, unter NT die verschiedenen Profile auch den
erstellenden Usern zuzuordnen.
>> unter NT in winnt\profiles\... Das /etc/epstopdfrc kann man nach
>> $TEXMF_HOME/etc verschieben, da würde ich zumindest sowieso eher
>> suchen. Um das .ini-Suffix kommt man wohl nicht wirklich herum.
>
> epstopdf ist zwar ein Programm, das wohl hauptsaechlich
> im pdf(TeX)-Umfeld genutzt wird, dennoch hat es eigentlich
> nichts mit TeX zu tun und wuerde es zu den Support/Tool-
> Programmen zaehlen, wie etwa Ghostscript, ...
Der Punkt hat was, stimme dir voll und ganz zu.
--
Michael Schmidt
Gerrit Kirpal
Heiko Oberdiek <ober...@uni-freiburg.de> wrote in message news:<ak3b8f$v3$2...@n.ruf.uni-freiburg.de>...
> kir...@rz.uni-leipzig.de (Gerrit Kirpal) wrote:
>
> >
> > Ich bewege mich in der Windows-Welt, wo quasi sehr viel GUI ist. TeX
> > selbst und etliche Programme um TeX herum laufen in der DOS-Box und
> > ich habe mich daran gewöhnt. Also, ich kann auf eine GUI für Windows
> > verzichten, zumal das Problem von Windows eben GUI ist. Ich denke auch
> > zugunsten der Stabilität sollte ein Kommandozeilen-Programm her.
[...]
> Wenn epstopdf eher minimalistisch bleibt, duerfte es wohl
> auch keine richtigen Bedarf fuer eine GUI geben.
> Aber wie wenn man den Leuten den kleinen Finger
> gibt, wollen sie dann die ganze Hand. Also wenn epstopdf
> um tausend Optionen angereichtert wird, wird es schwer,
> die Uebersicht zu behalten, so dass eine GUI helfen
> koennte.
Da ist was dran. Ab einer gewissen Funktionalität kann eine GUI
wirklich zum besseren Überblick verhelfen. Der ausführbare Teil des
Programms würde ja weiterhin ein Kommandozeilentool sein. Damit hätte
man einen guten Kompromiß zwischen GUI und Stabilität.
> Eine GUI koennte, wenn sie etwa Quelle und Ziel
> darstellen kann, dabei helfen die Berechnung der
> BoundingBox zu kontrollieren. Das Problem des
> "bbox"-Devices von Ghostscript ist etwa, dass es
> die BoundingBox nur innerhalb der gegebenen
> Papiergroesse berechnet und die ist oft nicht
> bekannt.
>
> Viele Gruesse
> Heiko <ober...@uni-freiburg.de>
Gruß, Gerrit