info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Minimalbeispiel mit Bild
6 views
Skip to first unread message
Friedrich Vosberg
Nov 25, 2022, 2:24:43 PM11/25/22
to
Ich hab's vergessen. Wie baut man ein Minimalbeispiel mit Bild (PNG-Datei)?
Ich habe hier ein Dokument, bei dem beim Kompilieren immer eine unglaublich lange Denkpause eingelegt wird, wenn das Bild eingebunden wird. Ich würde Euch da gerne mal drübergucken lassen, um herauszufinden, wo da der Hase im Pfeffer liegt.
Die Grundstruktur des Minimalbeispiels sieht so aus:
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\includegraphics[width=1cm]{../../../Pictures/namederdatei.png}
\end{document}
Ich habe hier ein Dokument, bei dem beim Kompilieren immer eine unglaublich lange Denkpause eingelegt wird, wenn das Bild eingebunden wird. Ich würde Euch da gerne mal drübergucken lassen, um herauszufinden, wo da der Hase im Pfeffer liegt.
Die Grundstruktur des Minimalbeispiels sieht so aus:
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\includegraphics[width=1cm]{../../../Pictures/namederdatei.png}
\end{document}
Ulrike Fischer
Nov 25, 2022, 3:01:18 PM11/25/22
to
Am Fri, 25 Nov 2022 11:24:42 -0800 (PST) schrieb Friedrich Vosberg:
> Ich hab's vergessen. Wie baut man ein Minimalbeispiel mit Bild
> (PNG-Datei)?
>
> Ich habe hier ein Dokument, bei dem beim Kompilieren immer eine
> unglaublich lange Denkpause eingelegt wird, wenn das Bild
> eingebunden wird. Ich würde Euch da gerne mal drübergucken
> lassen, um herauszufinden, wo da der Hase im Pfeffer liegt.
Nun, wenn es wirklich am Bild liegt, musst du es irgendwo zum
> Ich hab's vergessen. Wie baut man ein Minimalbeispiel mit Bild
> (PNG-Datei)?
>
> Ich habe hier ein Dokument, bei dem beim Kompilieren immer eine
> unglaublich lange Denkpause eingelegt wird, wenn das Bild
> eingebunden wird. Ich würde Euch da gerne mal drübergucken
> lassen, um herauszufinden, wo da der Hase im Pfeffer liegt.
Download bereitstellen.
Abgesehen davon: png kann dauern. Aus der pdftex-Doku:
Embedding png images in the general case requires pdfTEX to
uncompress the pixel array and to re--compress it to the pdf
requirements; this process often takes a noticeable amount of time.
Since pdfTEX 1.30.0 there is now a fast png embedding mode that
goes without uncompressing; the image data are directly copied into
the pdf stream, resulting in a much higher embedding speed. However
this mode is only activated, if the image array structure of the
png file is compatible with the pdf image structure (e.g. an
interlaced png image requires uncompressing to re--arrange the
image lines). Luckily it seems that the most common png files also
allow fast copying. The use of gamma correction disables fast
copying, as it requires calculations with individual pixels.
Whether the fast copy mode is used for a png image can be seen from
the log file, which then shows the string ‘(PNG copy)’ after the
png file name.
--
Ulrike Fischer
http://www.troubleshooting-tex.de/
Friedrich Vosberg
Nov 25, 2022, 3:11:25 PM11/25/22
to
Ulrike Fischer schrieb am Freitag, 25. November 2022 um 21:01:18 UTC+1:
>
> Abgesehen davon: png kann dauern.
Oha. Danke. Ich welches SVG Format sollte man so ein PNG mit welchem Tool umformatieren, damit's zukünftig schneller geht?
>
> Abgesehen davon: png kann dauern.
Ulrich D i e z
Nov 26, 2022, 6:25:50 PM11/26/22
to
Am 25.11.22 um 21:11 schrieb Friedrich Vosberg:
> Ulrike Fischer schrieb am Freitag, 25. November 2022 um 21:01:18 UTC+1:
>>
>> Abgesehen davon: png kann dauern.
>
> Oha. Danke. Ich welches SVG Format sollte man so ein PNG mit welchem Tool umformatieren, damit's zukünftig schneller geht?
SVG ist skalierbare Vektorgrafik.
PNG ist Rastergrafik.
Konversion von Rastergrafik in Vektorgrafik kann zu suboptimalen Ergebnissen
führen.
Vielleicht kannst Du die PNG-Dateien nach .pdf konvertieren
und in deinem LaTeX-Dokument statt der PNG-Dateien die .pdf-Dateien
per \includegraphics einfügen?
Konvertieren zB mit netpbm oder mit ImageMagick/convert oder sonst einem
Tool.
Andere, leicht umständlichere Konversionsmethode, die mit heutigen
LaTeX-Bordmitteln auskommen sollte, könnte sein:
Wenn du mit TeX-Engines arbeitest, die direkt pdf erstellen, kannst du
vielleicht die PNG-Datei per \includegraphics in ein LaTeX-Hilfs-Dokument
einfügen, in den von dir im eigentlichen Dokument gewünschten Maßen,
welches aus einer Seite ohne Ränder besteht, die genau die Ausmaße hat,
die das Bildchen in deinem eigentlichen Dokument haben
soll.
Dieses LaTeX-Hilfsdokument kompilierst du einmal zu einer pdf-Datei.
Das dauert dann einmal lang.
Aber dann hast du ein pdf-Bildchen mit dem Inhalt der PNG-Datei.
In dein eigentliches Dokument fügst du fürderhin die pdf-Datei mit dem
Bildchen per \includegraphics ein anstatt des PNG-Bildchens.
Da im eigentlichen Dokument nicht mit PNG sondern mit PDF-Bildchen
gearbeitet wird, müsste so das Compilieren des eigentlichen Dokuments
schneller gehen, auch wenn die dabei entstehende pdf-Datei ein paar
Bytes größer wird als wenn im eigentlichen Dokument PNG-Bildchen
direkt eingebunden worden wären.
Für das Erstellen eines Hilfsdokuments mit einer Seite in den Ausmaßen
eines per \includegraphics einzufügenden Bildchens habe ich mir
seinerzeit folgende Vorlage gebastelt:
%------------------------------------------------------
\documentclass{article}
%------------------------------------------------------
% This package is needed for detecting the engine:
%------------------------------------------------------
\usepackage{iftex}
%------------------------------------------------------
% This package is needed for placing the image:
%------------------------------------------------------
\usepackage{graphicx}
%------------------------------------------------------
% Raise a warning in case of .dvi-mode:
%------------------------------------------------------
\ifXeTeX\else\ifpdf\else
\GenericWarning{(hint) }{(hint)
--------------------------------------------------------------\MessageBreak
Your TeX-engine seems to be running in dvi-mode.\MessageBreak
In case your image is not an .eps-file, you may need to do\MessageBreak
the following:\MessageBreak
1. Have calculated the bounding box of your image and saved\MessageBreak
\space\space\space the bounding-box-info in a file with extension .bb or .xbb\MessageBreak
\space\space\space by means of a program like ebb (=extract bounding box)\MessageBreak
2. Declare a new graphics-rule, which could, e.g., look like\MessageBreak
\space\space\space this:\MessageBreak
\string\DeclareGraphicsRule{.jpg}{eps}{.bb}{}\MessageBreak
--------------------------------------------------------------\MessageBreak
Press Returnn to proceed.\MessageBreak
--------------------------------------------------------------%\MessageBreak
\csname @gobbletwo\endcsname
}%
\immediate\read-1 to\keyboardinput
\fi\fi
\newbox\BoxWithImage
\newcommand\Includegraphicspage[2][]{%
\begingroup
%------------------------------------------------------
% Image goes into a box so \wd, \ht and \dp can be used
% for measuring that box and automatically setting the
% margins and the paper format:
%------------------------------------------------------
\setbox\BoxWithImage=\vbox{\hbox{%
\includegraphics[{#1}]{#2}%
%-------------------------------------------------
}}%
\csname @ifundefined\endcsname{pagewidth}{}{\pagewidth=\wd\BoxWithImage}%
\csname @ifundefined\endcsname{pdfpagewidth}{}{\pdfpagewidth=\wd\BoxWithImage}%
\csname @ifundefined\endcsname{pageheight}{}{\pageheight=\ht\BoxWithImage
\advance\pageheight\dp\BoxWithImage}%
\csname @ifundefined\endcsname{pdfpageheight}{}{\pdfpageheight=\ht\BoxWithImage
\advance\pdfpageheight\dp\BoxWithImage}%
\shipout\vbox{\kern-1truein\hbox{\kern-1truein\box\BoxWithImage}}%
\endgroup
}%
%------------------------------------------------------
\begin{document}
%
% \Includegraphicspage has the same argument-pattern as
% \includegraphics, but the immage will be shipped out on a
% page on its own whereby the usual output-routine is bypassed.
% Pages created this way do not affect LaTeX's page-counting.
%
\Includegraphicspage[height=10cm, width=15cm]{example-image-a}%
\end{document}
%------------------------------------------------------
Mit freundlichem Gruß
Ulrich
> Ulrike Fischer schrieb am Freitag, 25. November 2022 um 21:01:18 UTC+1:
>>
>> Abgesehen davon: png kann dauern.
>
> Oha. Danke. Ich welches SVG Format sollte man so ein PNG mit welchem Tool umformatieren, damit's zukünftig schneller geht?
PNG ist Rastergrafik.
Konversion von Rastergrafik in Vektorgrafik kann zu suboptimalen Ergebnissen
führen.
Vielleicht kannst Du die PNG-Dateien nach .pdf konvertieren
und in deinem LaTeX-Dokument statt der PNG-Dateien die .pdf-Dateien
per \includegraphics einfügen?
Konvertieren zB mit netpbm oder mit ImageMagick/convert oder sonst einem
Tool.
Andere, leicht umständlichere Konversionsmethode, die mit heutigen
LaTeX-Bordmitteln auskommen sollte, könnte sein:
Wenn du mit TeX-Engines arbeitest, die direkt pdf erstellen, kannst du
vielleicht die PNG-Datei per \includegraphics in ein LaTeX-Hilfs-Dokument
einfügen, in den von dir im eigentlichen Dokument gewünschten Maßen,
welches aus einer Seite ohne Ränder besteht, die genau die Ausmaße hat,
die das Bildchen in deinem eigentlichen Dokument haben
soll.
Dieses LaTeX-Hilfsdokument kompilierst du einmal zu einer pdf-Datei.
Das dauert dann einmal lang.
Aber dann hast du ein pdf-Bildchen mit dem Inhalt der PNG-Datei.
In dein eigentliches Dokument fügst du fürderhin die pdf-Datei mit dem
Bildchen per \includegraphics ein anstatt des PNG-Bildchens.
Da im eigentlichen Dokument nicht mit PNG sondern mit PDF-Bildchen
gearbeitet wird, müsste so das Compilieren des eigentlichen Dokuments
schneller gehen, auch wenn die dabei entstehende pdf-Datei ein paar
Bytes größer wird als wenn im eigentlichen Dokument PNG-Bildchen
direkt eingebunden worden wären.
Für das Erstellen eines Hilfsdokuments mit einer Seite in den Ausmaßen
eines per \includegraphics einzufügenden Bildchens habe ich mir
seinerzeit folgende Vorlage gebastelt:
%------------------------------------------------------
\documentclass{article}
%------------------------------------------------------
% This package is needed for detecting the engine:
%------------------------------------------------------
\usepackage{iftex}
%------------------------------------------------------
% This package is needed for placing the image:
%------------------------------------------------------
\usepackage{graphicx}
%------------------------------------------------------
% Raise a warning in case of .dvi-mode:
%------------------------------------------------------
\ifXeTeX\else\ifpdf\else
\GenericWarning{(hint) }{(hint)
--------------------------------------------------------------\MessageBreak
Your TeX-engine seems to be running in dvi-mode.\MessageBreak
In case your image is not an .eps-file, you may need to do\MessageBreak
the following:\MessageBreak
1. Have calculated the bounding box of your image and saved\MessageBreak
\space\space\space the bounding-box-info in a file with extension .bb or .xbb\MessageBreak
\space\space\space by means of a program like ebb (=extract bounding box)\MessageBreak
2. Declare a new graphics-rule, which could, e.g., look like\MessageBreak
\space\space\space this:\MessageBreak
\string\DeclareGraphicsRule{.jpg}{eps}{.bb}{}\MessageBreak
--------------------------------------------------------------\MessageBreak
Press Returnn to proceed.\MessageBreak
--------------------------------------------------------------%\MessageBreak
\csname @gobbletwo\endcsname
}%
\immediate\read-1 to\keyboardinput
\fi\fi
\newbox\BoxWithImage
\newcommand\Includegraphicspage[2][]{%
\begingroup
%------------------------------------------------------
% Image goes into a box so \wd, \ht and \dp can be used
% for measuring that box and automatically setting the
% margins and the paper format:
%------------------------------------------------------
\setbox\BoxWithImage=\vbox{\hbox{%
\includegraphics[{#1}]{#2}%
%-------------------------------------------------
}}%
\csname @ifundefined\endcsname{pagewidth}{}{\pagewidth=\wd\BoxWithImage}%
\csname @ifundefined\endcsname{pdfpagewidth}{}{\pdfpagewidth=\wd\BoxWithImage}%
\csname @ifundefined\endcsname{pageheight}{}{\pageheight=\ht\BoxWithImage
\advance\pageheight\dp\BoxWithImage}%
\csname @ifundefined\endcsname{pdfpageheight}{}{\pdfpageheight=\ht\BoxWithImage
\advance\pdfpageheight\dp\BoxWithImage}%
\shipout\vbox{\kern-1truein\hbox{\kern-1truein\box\BoxWithImage}}%
\endgroup
}%
%------------------------------------------------------
\begin{document}
%
% \Includegraphicspage has the same argument-pattern as
% \includegraphics, but the immage will be shipped out on a
% page on its own whereby the usual output-routine is bypassed.
% Pages created this way do not affect LaTeX's page-counting.
%
\Includegraphicspage[height=10cm, width=15cm]{example-image-a}%
\end{document}
%------------------------------------------------------
Mit freundlichem Gruß
Ulrich
Ulrich D i e z
Nov 27, 2022, 9:15:10 AM11/27/22
to
Ulrike Fischer schrieb:
> Am Fri, 25 Nov 2022 11:24:42 -0800 (PST) schrieb Friedrich Vosberg:
>
>> Ich hab's vergessen. Wie baut man ein Minimalbeispiel mit Bild
>> (PNG-Datei)?
[...]
> Abgesehen davon: png kann dauern. Aus der pdftex-Doku:
>
> Embedding png images in the general case requires pdfTEX to
> uncompress the pixel array and to re--compress it to the pdf
> requirements; this process often takes a noticeable amount of time.
[...]
Falls es darum geht, in der Phase des Dokumenterstellens und
Ausprobierens und häufigen Neu-Compilierens die Dinge so zu
gestalten, dass in dieser Phase das Neucompilieren möglichst
schnell vonstatten geht:
Ich frage mich gerade - und jetzt auch die Leser/innen dieser
Newsgroup - , ob in Zusammengang mit png-Bildchen das Compilieren
signifikant schneller vonstatten geht, wenn man das graphicx-Paket
in dieser Phase mit der "draft"-Option lädt.
(Man muss ja die Bildchen nicht unbedingt sehen wenn es in der
"Bastelphase" nur darum geht, wie der Text gesetzt wird. Die mit
der draft-Option gemalten Rechteckchen mit dem Namen der
Bilddatei reichen in dieser Phase oft vollkommen aus.)
Oder ob das nicht viel bringt, weil die png-Dateien auch für
das Erhalten der Bildmaße "angelesen" werden müssen.
Wenn ich richtig verstehe, würde man bei der draft-Option
zumindest den "re-compress"-Teil eigentlich nicht brauchen.
Ob man den uncompress-Teil braucht, um an die Bildmaße zu
kommen, bzw - falls nicht -, ob die diversen TeX-Engines
es überhaupt unterstützen, bei Verwendung der draft-Option
nur die Bildmaße aus der Bilddatei auszulesen und die ganze
Zeit kostende Dekomprimiererei/Neu-Komprimiererei bleiben zu
lassen, weiss ich nicht.
Auf der von mir im Moment verwendeten Maschinerie kann ich
das nicht vernünftig testen, weil hier der Großteil der
Zeit nicht für das Compilieren drauf geht, sondern dafür,
die TeX-Engine überhaupt erstmal zu laden und zur
Ausführung zu bringen.
Ob ich mit draft-Optrion oder ohne 500 verschiedene
png-Dateien einfügen lasse, macht auf meinem System
gemäß l3benchmark grade mal aderthalb Sekunden aus, was in
Relation zu meiner eigenen Umdrehungsgeschwindigkeit nicht
ins Gewicht fällt.
Mit freundlichem Gruß
Ulrich
> Am Fri, 25 Nov 2022 11:24:42 -0800 (PST) schrieb Friedrich Vosberg:
>
>> Ich hab's vergessen. Wie baut man ein Minimalbeispiel mit Bild
>> (PNG-Datei)?
> Abgesehen davon: png kann dauern. Aus der pdftex-Doku:
>
> Embedding png images in the general case requires pdfTEX to
> uncompress the pixel array and to re--compress it to the pdf
> requirements; this process often takes a noticeable amount of time.
Falls es darum geht, in der Phase des Dokumenterstellens und
Ausprobierens und häufigen Neu-Compilierens die Dinge so zu
gestalten, dass in dieser Phase das Neucompilieren möglichst
schnell vonstatten geht:
Ich frage mich gerade - und jetzt auch die Leser/innen dieser
Newsgroup - , ob in Zusammengang mit png-Bildchen das Compilieren
signifikant schneller vonstatten geht, wenn man das graphicx-Paket
in dieser Phase mit der "draft"-Option lädt.
(Man muss ja die Bildchen nicht unbedingt sehen wenn es in der
"Bastelphase" nur darum geht, wie der Text gesetzt wird. Die mit
der draft-Option gemalten Rechteckchen mit dem Namen der
Bilddatei reichen in dieser Phase oft vollkommen aus.)
Oder ob das nicht viel bringt, weil die png-Dateien auch für
das Erhalten der Bildmaße "angelesen" werden müssen.
Wenn ich richtig verstehe, würde man bei der draft-Option
zumindest den "re-compress"-Teil eigentlich nicht brauchen.
Ob man den uncompress-Teil braucht, um an die Bildmaße zu
kommen, bzw - falls nicht -, ob die diversen TeX-Engines
es überhaupt unterstützen, bei Verwendung der draft-Option
nur die Bildmaße aus der Bilddatei auszulesen und die ganze
Zeit kostende Dekomprimiererei/Neu-Komprimiererei bleiben zu
lassen, weiss ich nicht.
Auf der von mir im Moment verwendeten Maschinerie kann ich
das nicht vernünftig testen, weil hier der Großteil der
Zeit nicht für das Compilieren drauf geht, sondern dafür,
die TeX-Engine überhaupt erstmal zu laden und zur
Ausführung zu bringen.
Ob ich mit draft-Optrion oder ohne 500 verschiedene
png-Dateien einfügen lasse, macht auf meinem System
gemäß l3benchmark grade mal aderthalb Sekunden aus, was in
Relation zu meiner eigenen Umdrehungsgeschwindigkeit nicht
ins Gewicht fällt.
Mit freundlichem Gruß
Ulrich
Alfred Neumann
Nov 27, 2022, 9:36:52 AM11/27/22
to
Am 27.11.2022 um 00:26 schrieb Ulrich D i e z:
> % Pages created this way do not affect LaTeX's page-counting.
> %
> \Includegraphicspage[height=10cm, width=15cm]{example-image-a}%
Funktioniert bestens.
> % Pages created this way do not affect LaTeX's page-counting.
> %
> \Includegraphicspage[height=10cm, width=15cm]{example-image-a}%
An dieser Stelle wird das Bild mit dem Originalnamen eingelesen. Das
Ausgabe-PDF erhält aber den Namen der Sourcedatei, die ich anschließend
umbenenne.
Lässt sich hier irgendwie der Originalname als Speichername einsetzen?
Beispiel:
% Source
convert-png2pdf.tex
%Bilddatei:
meinbild.png
%Ausgabedatei:
meinbild.pdf
Ulrich D i e z
Nov 27, 2022, 11:00:25 AM11/27/22
to
Am 27.11.22 um 15:36 schrieb Alfred Neumann:
> Am 27.11.2022 um 00:26 schrieb Ulrich D i e z:
>
>> % Pages created this way do not affect LaTeX's page-counting.
>> %
>> \Includegraphicspage[height=10cm, width=15cm]{example-image-a}%
!!!!! Nicht nur den Dateinamen im nicht-optionalen Argument, sondern auch
das optionale Argument des in der Datei convert-png2pdf.tex vorkommenden
\Includegraphicspage-Befehls musst du von Fall zu Fall anpassen, denn es
ist nicht gesagt, dass du das Bildchen immer in einer Breite von 15cm und
einer Höhe von 10cm haben möchtest !!!!!
Wen du png-Bildchen und pdf-Bildchen in der selben Größe haben möchtest,
kannst du das optionale Argument weglassen.
> Funktioniert bestens.
> An dieser Stelle wird das Bild mit dem Originalnamen eingelesen. Das Ausgabe-PDF erhält aber den Namen der Sourcedatei, die ich anschließend umbenenne.
>
> Lässt sich hier irgendwie der Originalname als Speichername einsetzen?
>
> Beispiel:
>
> % Source
> convert-png2pdf.tex
>
> %Bilddatei:
> meinbild.png
>
> %Ausgabedatei:
> meinbild.pdf
Wenn du möchtest, dass die Ausgabedatei "meinbild.pdf" heißt, kannst du
den Compiler an der Shell/am Komandozeilenprompt/an der Konsole mit der Option
-jobname="..." aufrufen, zB
pdflatex -jobname="meinbild" convert-png2pdf.tex
Wenn du das tust, expandiert das Primitive \jobname zur Phrase "meinbild",
bestehend aus expliziten Character-Token der Kategorie 12(other).
Dann kannst du den \Includegraphicspage-Befehl, der in der Datei convert-png2pdf.tex
steht, so umstricken, dass er den Dateinamen der einzufügenden Grafikdatei aus
\jobname erhält, etwa:
\Includegraphicspage{\jobname.pgf}%
Aber das ändert nichts daran, dass ggfs das optionale Argument dieses
Befehls von Fall zu Fall angegeben/angepasst werden muss wenn man das
pdf-Bildchen in anderer Größe als das pgf-Bildchen haben möchte.
Bei manchen TeX-Plattformen kann auch eine Möglichkeit, diese Angabe/
Anpassung beim Aufruf des Compilers vorzunehmen, realisiert werden - bei
manchen TeX-Plattformen könnte etwas in der folgenden Art funktionieren:
In der Datei convert-png2pdf.tex für den Aufruf des \Includegraphicspage-Befehls:
\providecommand{\includegraphicsoptions}{}%
\expandafter\Includegraphicspage\expandafter[\expandafter{\includegraphicsoptions}]{\jobname.png}%
Aufruf des Compilers an der Shell/am Komandozeilenprompt/an der Konsole:
pdflatex -jobname="meinbild" "\def\includegraphicsoptions{height=10cm, width=15cm} \input convert-png2pdf.tex "
Den Befehl für die Kommandozeile halte ich aber für ein Monstrum.
Außerdem funktioniert er allenfalls dann, wenn pdflatex aus demjenigen Verzeichnis heraus
aufgerufen wird, in dem die Datei meinbild.png liegt.
Wenn dann aber convert-png2pdf.tex in einem anderen Verzeichnis liegt, sodass man
beim \input-Befehl auch noch relative Pfade angeben muss, wird es lustig.
Außerdem erzeugt pdflatex eine Datei meinbild.log in dem Verzeichnis, von dem aus
pdflatex aufgerufen wurde. Bereits existierende .log-Dateien gleichen Namens werden
dabei zerstört.
Von daher halte ich das ganze Konzept für eher fragil.
Es ist als Notbehelf zu sehen wenn man außer den Bordmitteln der TeX-Distribution
keine anderen Werkzeuge zur Umwandlung in andere Grafikformate zur Verfügung hat.
Mit freundlichem Gruß
Ulrich
> Am 27.11.2022 um 00:26 schrieb Ulrich D i e z:
>
>> % Pages created this way do not affect LaTeX's page-counting.
>> %
>> \Includegraphicspage[height=10cm, width=15cm]{example-image-a}%
das optionale Argument des in der Datei convert-png2pdf.tex vorkommenden
\Includegraphicspage-Befehls musst du von Fall zu Fall anpassen, denn es
ist nicht gesagt, dass du das Bildchen immer in einer Breite von 15cm und
einer Höhe von 10cm haben möchtest !!!!!
Wen du png-Bildchen und pdf-Bildchen in der selben Größe haben möchtest,
kannst du das optionale Argument weglassen.
> Funktioniert bestens.
> An dieser Stelle wird das Bild mit dem Originalnamen eingelesen. Das Ausgabe-PDF erhält aber den Namen der Sourcedatei, die ich anschließend umbenenne.
>
> Lässt sich hier irgendwie der Originalname als Speichername einsetzen?
>
> Beispiel:
>
> % Source
> convert-png2pdf.tex
>
> %Bilddatei:
> meinbild.png
>
> %Ausgabedatei:
> meinbild.pdf
den Compiler an der Shell/am Komandozeilenprompt/an der Konsole mit der Option
-jobname="..." aufrufen, zB
pdflatex -jobname="meinbild" convert-png2pdf.tex
Wenn du das tust, expandiert das Primitive \jobname zur Phrase "meinbild",
bestehend aus expliziten Character-Token der Kategorie 12(other).
Dann kannst du den \Includegraphicspage-Befehl, der in der Datei convert-png2pdf.tex
steht, so umstricken, dass er den Dateinamen der einzufügenden Grafikdatei aus
\jobname erhält, etwa:
\Includegraphicspage{\jobname.pgf}%
Aber das ändert nichts daran, dass ggfs das optionale Argument dieses
Befehls von Fall zu Fall angegeben/angepasst werden muss wenn man das
pdf-Bildchen in anderer Größe als das pgf-Bildchen haben möchte.
Bei manchen TeX-Plattformen kann auch eine Möglichkeit, diese Angabe/
Anpassung beim Aufruf des Compilers vorzunehmen, realisiert werden - bei
manchen TeX-Plattformen könnte etwas in der folgenden Art funktionieren:
In der Datei convert-png2pdf.tex für den Aufruf des \Includegraphicspage-Befehls:
\providecommand{\includegraphicsoptions}{}%
\expandafter\Includegraphicspage\expandafter[\expandafter{\includegraphicsoptions}]{\jobname.png}%
Aufruf des Compilers an der Shell/am Komandozeilenprompt/an der Konsole:
pdflatex -jobname="meinbild" "\def\includegraphicsoptions{height=10cm, width=15cm} \input convert-png2pdf.tex "
Den Befehl für die Kommandozeile halte ich aber für ein Monstrum.
Außerdem funktioniert er allenfalls dann, wenn pdflatex aus demjenigen Verzeichnis heraus
aufgerufen wird, in dem die Datei meinbild.png liegt.
Wenn dann aber convert-png2pdf.tex in einem anderen Verzeichnis liegt, sodass man
beim \input-Befehl auch noch relative Pfade angeben muss, wird es lustig.
Außerdem erzeugt pdflatex eine Datei meinbild.log in dem Verzeichnis, von dem aus
pdflatex aufgerufen wurde. Bereits existierende .log-Dateien gleichen Namens werden
dabei zerstört.
Von daher halte ich das ganze Konzept für eher fragil.
Es ist als Notbehelf zu sehen wenn man außer den Bordmitteln der TeX-Distribution
keine anderen Werkzeuge zur Umwandlung in andere Grafikformate zur Verfügung hat.
Mit freundlichem Gruß
Ulrich
Alfred Neumann
Nov 27, 2022, 11:36:02 AM11/27/22
to
Am 27.11.2022 um 17:00 schrieb Ulrich D i e z:
Danke für die Erläuterungen.
Da sich die Anzahl der Umwandlungen bei mir in Grenzen hält, bleibe ich
erst mal bei der händischen Umbenennung.
Danke für die Erläuterungen.
Da sich die Anzahl der Umwandlungen bei mir in Grenzen hält, bleibe ich
erst mal bei der händischen Umbenennung.
Ulrich D i e z
Nov 27, 2022, 3:17:02 PM11/27/22
to
Am 27.11.22 um 17:36 schrieb Alfred Neumann:
Man kann beim graphicx-Package die draft-Option angeben, dann verringert sich
die Compilierzeit in der Phase des Dokumenterstellens und Bastelns.
Wenn man mit Basteln fertig ist, lässt man die draft-Option weg, dann dauert
das Compilieren einmal halt ein bisschen länger.
Manchmal habe ich, wenn keine Fotos, sondern nur vektorisierbare Zeichnungen
ohne Beschriftung in Schwarz nötig waren, früher die Zeichnungen auch mit
Metafont erstellt und als Schriftart eingebunden. Das war eine tolle
Frickelei.
Heutzutage: TikZ/pgf.
Manchmal, wennn ich auf einem Foto zusätzlich etwas schreiben möchte, mache
ich es nicht so, dass ich die Box mit dem Bild per \shipout ausgeben lasse,
sondern ich stelle für das Dokument die entsprechende Seitengröße und ein
Seitenlayout ohne Ränder und ohne Seitenkopf/Seitenfuß ein und packe das Bild
in eine Box, die als Seitenhintergrund verwendet wird, zB mittels eso-pic,
oder - bei aktuellem LaTeX - mittels des Hooks shipout/background .
Auf die erste (und einzige) Seite des Dokuments packe ich dann zB eine
picture-Umgebung oder eine tikzpicture-Umgebung, die es mir ermöglicht,
durch Angabe von Koordinaten Elemente auf dem Bild zu platzieren. Auf
diese Weise kann ich im Bildchen die selbe Schrift haben wie im LaTeX-
Dokument, in das das Bildchen eingebunden werden soll.
Ich hab das mal unter <https://tex.stackexchange.com/a/450130> beschrieben.
Der Code ist sehr ähnlich dem, den ich in diesem Thread schon gepostet habe.
Mit freundlichem Gruß
Ulrich
> Am 27.11.2022 um 17:00 schrieb Ulrich D i e z:
>
> Danke für die Erläuterungen.
>
> Da sich die Anzahl der Umwandlungen bei mir in Grenzen hält, bleibe ich erst mal bei der händischen Umbenennung.
Ich mache das auch eher selten. ;-)
>
> Danke für die Erläuterungen.
>
> Da sich die Anzahl der Umwandlungen bei mir in Grenzen hält, bleibe ich erst mal bei der händischen Umbenennung.
Man kann beim graphicx-Package die draft-Option angeben, dann verringert sich
die Compilierzeit in der Phase des Dokumenterstellens und Bastelns.
Wenn man mit Basteln fertig ist, lässt man die draft-Option weg, dann dauert
das Compilieren einmal halt ein bisschen länger.
Manchmal habe ich, wenn keine Fotos, sondern nur vektorisierbare Zeichnungen
ohne Beschriftung in Schwarz nötig waren, früher die Zeichnungen auch mit
Metafont erstellt und als Schriftart eingebunden. Das war eine tolle
Frickelei.
Heutzutage: TikZ/pgf.
Manchmal, wennn ich auf einem Foto zusätzlich etwas schreiben möchte, mache
ich es nicht so, dass ich die Box mit dem Bild per \shipout ausgeben lasse,
sondern ich stelle für das Dokument die entsprechende Seitengröße und ein
Seitenlayout ohne Ränder und ohne Seitenkopf/Seitenfuß ein und packe das Bild
in eine Box, die als Seitenhintergrund verwendet wird, zB mittels eso-pic,
oder - bei aktuellem LaTeX - mittels des Hooks shipout/background .
Auf die erste (und einzige) Seite des Dokuments packe ich dann zB eine
picture-Umgebung oder eine tikzpicture-Umgebung, die es mir ermöglicht,
durch Angabe von Koordinaten Elemente auf dem Bild zu platzieren. Auf
diese Weise kann ich im Bildchen die selbe Schrift haben wie im LaTeX-
Dokument, in das das Bildchen eingebunden werden soll.
Ich hab das mal unter <https://tex.stackexchange.com/a/450130> beschrieben.
Der Code ist sehr ähnlich dem, den ich in diesem Thread schon gepostet habe.
Mit freundlichem Gruß
Ulrich
0 new messages