Bilder und PDF

[jonas88]

Was für Bildendungen kann ich denn verwenden wann ich PDFlatx verwende?

weil bei .eps gibts ne Fehlermeldung
...

ciao
Jonas

[sofa-surfer]

Hallo,

ein Blick ins l2picfaq (http://www.tug.org/tex-archive/info/l2picfaq/german/l2picfaq.pdf) kann nicht schaden ...

Matthias

[rais]

Moin moin,

Was für Bildendungen kann ich denn verwenden wann ich PDFlatx verwende?

weil bei .eps gibts ne Fehlermeldung
...

ciao
Jonas
alternativ könntest Du es mit dem pst-pdf-Paket probieren, da sollte das auch mit (e)ps-Grafiken funzen, wenn Du sie entsprechend in eine postscript-Umgebung packst.
Schau Dir dann auch pst-pdf-example.tex an.;)
MfG,

[voss]

Moin moin,

alternativ könntest Du es mit dem pst-pdf-Paket probieren, da sollte das auch mit (e)ps-Grafiken funzen, wenn Du sie entsprechend in eine postscript-Umgebung packst.
Schau Dir dann auch pst-pdf-example.tex an.;)


das braucht man nicht in eine postscript-Umgebung zu packen!
Abgesehen davon ist der Abschnitt über pst-pdf in l2picfaq komplett falsch.

Herbert

[bischi]

Abgesehen davon ist der Abschnitt über pst-pdf in l2picfaq komplett falsch.

Nett, dass man mir das erst jetzt sagt - aber besser spät als nie...

Was konkret ist falsch und wie wärs richtig? Bei mir haben die Beispiele nämlich funktioniert...

MfG Bischi

PS: Zum Problem: eps nach pdf konvertieren liefert das gewünschte Ergebnis.

[rais]

das braucht man nicht in eine postscript-Umgebung zu packen!

Hehe, da hab ich mich wohl zu sehr aufs Beispiel gestürzt
aus pst-pdf-sample.tex:


:
\begin{postscript}[trim=0 0 0 0,ignore]
\includegraphics[width=.475\textwidth]{penguin.eps}
\end{postscript}
\savepicture{ps:A}
:

und vermute mal, daß die Grafik hier nur in der postscript-Umgebung steckt, damit's mit dem \savepicture/\usepicture funzt - oder warum ist sie sonst drin?
MfG,

[voss]

Hehe, da hab ich mich wohl zu sehr aufs Beispiel gestürzt
aus pst-pdf-sample.tex:


:
\begin{postscript}[trim=0 0 0 0,ignore]
\includegraphics[width=.475\textwidth]{penguin.eps}
\end{postscript}
\savepicture{ps:A}
:

und vermute mal, daß die Grafik hier nur in der postscript-Umgebung steckt, damit's mit dem \savepicture/\usepicture funzt - oder warum ist sie sonst drin?


steht doch alles in der Doku ...

Herbert

[bischi]

Genau aus dieser Doku stammt der Beispielcode aus l2picfaq.pdf (sind ja gerade mal 3 Seiten Erklärungen - der Rest ist Implementationscode...)

Nochmals: Was genau ist an l2picfaq zum Thema pst-pdf so total falsch?!

MfG Bischi

[pospiech]

Mein Wissen dazu:

pst-pdf benutzt ps4pdf (makefile) und als Paket preview um automatisch jeden Psotscriptcode in ein Pdf zu packen, dass dann von pdflatex automatisch als PDF wieder eingebunden wird.

Dazu ist nur ein Laden von pst-pdf und die Benutztung des ps4pdf Makefiles notwendig.


Ein anderer Weg wäre die Nutzung vom epstopdf Paket. Das wandelt mit dem externen Paket epstopdf direkt die eps nach pdf. Auch in diesem Fall benötigt man keine zusätzlichen Befehle.

Matthias

[rais]

Auch wenn's ein wenig spät kommt...

steht doch alles in der Doku ...

Herbert
Mag ja sein, daß da alles drinsteht, aber so richtig gefunden hab' ich's immer noch nicht...


2.4 Command options
Das Verhalten der Anweisungen \includegraphics, \usepicture und der Umgebung
postscript kann mit den folgenden optionalen Parametern beeinflusst
werden (key-value-Syntax):
das hört sich für mich so wie eine Aufzählung an - das würde bedeuten, daß sowohl \includegraphics, \usepicture, als auch die postscript-Umgebung die hierauf folgenden Optionen verhackstücken könnten. Da fehlt irgendwie die Verbindung hin zu "wenn \includegraphics innerhalb einer postscript-Umgebung aufgerufen wird..."
Abgesehen davon:


Die Anwendung dieses Verfahrens kann die Angabe der
Option “trim” erübrigen (siehe Abschnitt 2.4).

Ja und? Wo findet man `trim' in Abschnitt 2.4? Nirgends - erst wieder im dokumentierten Quellcode, der ja nun wirklich nicht jedermanns Sache ist.
Genaugenommen hab' ich's zuerst in pst-pdf.sty gefunden (oder vielmehr: gerade nicht), als mir dann klar wurde, daß der \setkeys so ziemlich am Anfang der postscript-Umgebung eben auch dafür sorgt, daß der folgende \includegraphics (der ja ebenfalls auf keyval aufsetzt) gerade diese trim-Option gesetzt bekommt (wobei ich mich noch frage, ob ein zusätzlicher Rand von 0pt zu allen Seiten so richtig Sinn macht).
Sehr verwirrend, das :eek:
MfG,

[voss]

Auch wenn's ein wenig spät kommt...

Mag ja sein, daß da alles drinsteht, aber so richtig gefunden hab' ich's immer noch nicht...
das hört sich für mich so wie eine Aufzählung an - das würde bedeuten, daß sowohl \includegraphics, \usepicture, als auch die postscript-Umgebung die hierauf folgenden Optionen verhackstücken könnten. Da fehlt irgendwie die Verbindung hin zu "wenn \includegraphics innerhalb einer postscript-Umgebung aufgerufen wird..."


pst-pdf ist lediglich ein Interface zu preview.sty. _Dem_ Paket muss man erst mal mitteilen, was als Grafik ausgeschnitten werden soll und was nicht. Und _per Definition_ gehören die in der Doku angegeben Makros/Umgebungen dazu. Man kann beliebige neue bestimmen:
\PreviewEnvironment{tabular}

\includegraphics ist bereits automatisch von preview erfasst, braucht also nicht in die postscript Umgebung gepackt zu werden.


Abgesehen davon:

Ja und? Wo findet man `trim' in Abschnitt 2.4? Nirgends - erst wieder im dokumentierten Quellcode, der ja nun wirklich nicht jedermanns Sache ist.
Genaugenommen hab' ich's zuerst in pst-pdf.sty gefunden (oder vielmehr: gerade nicht), als mir dann klar wurde, daß der \setkeys so ziemlich am Anfang der postscript-Umgebung eben auch dafür sorgt, daß der folgende \includegraphics (der ja ebenfalls auf keyval aufsetzt) gerade diese trim-Option gesetzt bekommt (wobei ich mich noch frage, ob ein zusätzlicher Rand von 0pt zu allen Seiten so richtig Sinn macht).


trim ist bereits in graphicx definiert und erklärt , wie überhaupt _alle_ Optionen von graphicx auch in pst-pdf gültig sind.

Mit der letzten Version von pst-pdf braucht man noch nichtmal \usepackage{pst-pdf} machen, wenn eines der auf CTAN vorhandenen Skripte verwendet werden.

Herbert

[rais]

Versteh' mich bitte nicht falsch:
ich bin Dir durchaus dankbar dafür, daß Du versuchst, meinem `Dickschädel' Deine Weisheit einzutrichtern...Otoh ist es auf diese Weise auch irgendwie spaßiger, als meinerseits bloß zu antworten: "Ja, Du hast recht..." oder so ähnlich. - findest Du das nicht auch? :D

pst-pdf ist lediglich ein Interface zu preview.sty.

Nun, _das_ hab ich _nirgends_ in der Doku zu pst-pdf gefunden - lediglich, daß preview von pst-pdf geladen wird und das auch noch nur im dokumentierten Quellcode, zu dem ich ja schon meine Meinung abgegeben hab'


_Dem_ Paket muss man erst mal mitteilen, was als Grafik ausgeschnitten werden soll und was nicht. Und _per Definition_ gehören die in der Doku angegeben Makros/Umgebungen dazu. Man kann beliebige neue bestimmen:
\PreviewEnvironment{tabular}

Jetzt mal im Klartext: heißt das, daß die trim-Option eigentlich an das preview-Paket und nicht an den \includegraphics (um beim Beispiel zu bleiben) übergeben wird?

\includegraphics ist bereits automatisch von preview erfasst, braucht also nicht in die postscript Umgebung gepackt zu werden.

Das erklärt mir noch lange nicht, warum beim angesprochenen mitgelieferten Beispiel von pst-pdf gerade dieses \includegraphics in eine postscript-Umgebung eingebettet ist.


trim ist bereits in graphicx definiert und erklärt , wie überhaupt _alle_ Optionen von graphicx auch in pst-pdf gültig sind.

Was ich ausdrücken wollte: 'trim' wird in der Beschreibung zur notightpage-Option angeschnitten, mit einem Hinweis auf Abschnitt 2.4 (man kann als außenstehender hier nur den entsprechenden Abschnitt aus derselben Doku annehmen), in welchem die `trim' Option aber gar nicht erwähnt wird. Was ich aber eigentlich verwirrend fand: Paket A (graphicx) definiert eine Option `trim'. Paket A wird nun von Paket B (pst-pdf) geladen, definiert sich seine eigene Umgebung (postscript), in der die Option aus Paket A (eben `trim') benutzt wird. Das ist fast schon vergleichbar mit zwei eigens definierten Makros: in Makro A definiert man sich eine Option, aber in Makro B ruft man sie auf...


steht doch alles in der Doku ...
Wir sprechen schon von ein und derselben Doku - also die zu pst-pdf?

PS) das ist alles keinesfalls gegen Dich gerichtet, aber vllt verstehst Du jetzt meine Verwirrung.

MfG,

[voss]

Nun, _das_ hab ich _nirgends_ in der Doku zu pst-pdf gefunden - lediglich, daß preview von pst-pdf geladen wird und das auch noch nur im dokumentierten Quellcode, zu dem ich ja schon meine Meinung abgegeben hab'

pst-pdf sorgt für die Anwendung von preview, was eigentlich nur für AUCTeX vom emacs gedacht war.



Jetzt mal im Klartext: heißt das, daß die trim-Option eigentlich an das preview-Paket und nicht an den \includegraphics (um beim Beispiel zu bleiben) übergeben wird?

Nein, sie wird an graphicx weitergereicht.


Das erklärt mir noch lange nicht, warum beim angesprochenen mitgelieferten Beispiel von pst-pdf gerade dieses \includegraphics in eine postscript-Umgebung eingebettet ist.


Weil die Menschen, die freiwillig an Paketen arbeiten, von denen oft nur andere was haben, ab und zu mal etwas machen, was sie später verändern wollen aber nicht tun weil sie es einfach vergessen haben ...


Herbert

[rais]

Weil die Menschen, die freiwillig an Paketen arbeiten, von denen oft nur andere was haben, ab und zu mal etwas machen, was sie später verändern wollen aber nicht tun weil sie es einfach vergessen haben ...

ich habe mir diesen Text sehr lange angeschaut, auch wenn ich schon nicht mehr sagen kann, wie oft ich den blöden screensaver wegklicken mußte...
So ich selbst erst vor etwas über einem Jahr als bisher Word-geprägter - d.h. inzwischen würd' ich's eher als `geplagter' ausdrücken - mit LaTeX in Kontakt gekommen bin, habe ich wer weiß' viele Dokumentationen online wie offline durchgelesen - und in dieser Zeit bereits wesentlich mehr mit LaTeX erreicht, als ich mir bei einem Programm wie Word jemals zu hoffen gewagt hätte.
Ich mein', stell' Dir einmal vor, Du würdest erst heute mit LaTeX beginnen - wo würdest Du anfangen? Bei der Vielzahl an bereits vorhandenen Paketen ist es für einen relativen Neueinsteiger in der Materie nun wirklich nicht gerade leicht...
Und so ich mir auch nur wünschen kann, die LaTeX-Gemeinde eines Tages mit dem einen oder anderen selbstgestrickten Beitrag zu bereichern, kann ich nur hoffen, daß Du hier ausnahmsweise einmal falsch liegst - Du weißt schon, welchen Teil ich meine.
MfG,