Home > Archive > Tex > July 2006 > graphicx and option draft
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
graphicx and option draft
|
|
| Ulrike Fischer 2006-07-24, 8:02 am |
| Hello,
I have played a bit with different combinations of options of
includegraphics but I didn't find a sensible way to use includegraphics
and process the document with LaTeX and pdfLaTeX and get "draft frames"
when the image doesn't exist:
\documentclass{article}
\usepackage[draft]{graphicx}
\begin{document}
LaTeX
%% warning and frame is shown
%\includegraphics[bb = 0 0 100 100]{dontexist.eps}
%\includegraphics[read=.bb,type=eps]{dontexist}
%% error, no frame
%\includegraphics[read=.bb]{dontexist}
%\includegraphics[read=.bb,ext=.eps]{dontexist}
%% error, no frame
%\includegraphics[bb = 0 0 100 100]{dontexist}
pdfLaTeX
% fatal error, pdf not finished
%\includegraphics[viewport = 0 0 100 100]{dontexist.pdf}
% error, no frame
%\includegraphics[viewport = 0 0 100 100]{dontexist}
\end{document}
Has someone a better idea? And why is graphicx trying to open graphics
when draft is enable and the bounding box is known?
--
Ulrike Fischer
e-mail: zusätzlich meinen Vornamen vor dem @ einfügen.
e-mail: add my first name between the news and the @.
| |
|
|
| Ulrike Fischer 2006-07-24, 7:03 pm |
| Herbert Voss <Herbert.Voss@gmx.net> schrieb:
> \usepackage[demo]{graphicx}% latest update
>
> takes all keys into account, but doesn't look for the file.
> Without any keys a black box of 200pt x 150pt is printed.
It works fine if the size of the image is given throught width and
height (at least the rule has the correct size, but I would prefer the
standard draft frame with as much of the filename as possible), but it
don't work with bb (or viewport):
\documentclass{minimal}
\usepackage[demo]{graphicx}
\begin{document}
\includegraphics[width=5cm,height=1cm]{h
ei}
\includegraphics[width=1cm,height=3cm]{h
ei}
\bigskip
\includegraphics[bb=10 10 150 150]{hei}
\includegraphics[bb=100 100 150 150]{hei}
\end{document}
--
Ulrike Fischer
e-mail: zusätzlich meinen Vornamen vor dem @ einfügen.
e-mail: add my first name between the news and the @.
| |
|
|
| Heiko Oberdiek 2006-07-24, 7:03 pm |
| Herbert Voss <Herbert.Voss@gmx.net> wrote:
> Ulrike Fischer wrote:
>
> works only for latex not for pdflatex. Looks like a bug to me
>
> \documentclass[draft]{minimal}
> \usepackage{graphicx,ifpdf}
>
> \begin{document}
>
> \ifpdf\includegraphics[draft, bb=10 10 150 150, type=png]{hei}
PNG isn't EPS. %%BoundingBox doesn't exist. Sometimes a PNG
file has a width and a height (natwidth, natheight), but sometimes
also the density is unknown. At any case "bb=10 10 ..." is nonsense,
the image starts at "0 0". For selecting areas option viewport exists.
Yours sincerely
Heiko <oberdiek@uni-freiburg.de>
| |
| Ulrike Fischer 2006-07-24, 7:03 pm |
| Heiko Oberdiek <oberdiek@uni-freiburg.de> schrieb:
>
> PNG isn't EPS. %%BoundingBox doesn't exist. Sometimes a PNG
> file has a width and a height (natwidth, natheight), but sometimes
> also the density is unknown. At any case "bb=10 10 ..." is nonsense,
> the image starts at "0 0". For selecting areas option viewport exists.
Yes. But that isn't the problem.
If the graphics hei exists,
\includegraphics[draft, bb=10 10 150 150]{hei}
\includegraphics[draft, viewport=10 10 150 150]{hei}
both give sensible results with LaTeX and pdflatex. You get perhaps a
warning that viewport is used instead of bb, but you will get a frame
in the wanted size in any case.
But if hei doesn't exists, you get either errors or (with option demo)
rules of a standard size that has nothing to do with the size given by
viewport or bb.
I would like to process drafts of documents even if the images are not
accessible. Why should pdfLaTeX fail completly because of a missing
image even if draft is enabled? And the result should be as accurate as
possible. So if the size information is there (as bb, viewport, width
or in a .bb- file) it should be used.
--
Ulrike Fischer
e-mail: zusätzlich meinen Vornamen vor dem @ einfügen.
e-mail: add my first name between the news and the @.
| |
|
|
| Heiko Oberdiek 2006-07-24, 7:03 pm |
| Ulrike Fischer <news@nililand.de> wrote:
> Heiko Oberdiek <oberdiek@uni-freiburg.de> schrieb:
>
>
>
> Yes. But that isn't the problem.
>
> If the graphics hei exists,
> \includegraphics[draft, bb=10 10 150 150]{hei}
> \includegraphics[draft, viewport=10 10 150 150]{hei}
> both give sensible results with LaTeX and pdflatex. You get perhaps a
> warning that viewport is used instead of bb, but you will get a frame
> in the wanted size in any case.
>
> But if hei doesn't exists, you get either errors
The error message is:
| ! LaTeX Error: Cannot determine size of graphic in hei (no size specifed).
This is the correct, see grfguide:
| draft suppress all the `special' features. In particular graphics files are not
| included (but they are still read for size info) just the filename is printed
| in a box of the correct size.
Yours sincerely
Heiko <oberdiek@uni-freiburg.de>
| |
| Heiko Oberdiek 2006-07-24, 7:03 pm |
| Herbert Voss <Herbert.Voss@gmx.net> wrote:
> Heiko Oberdiek wrote:
>
> this is not the point. There is a given bb,
Why? pdfTeX is capable to determine the bounding box information
by itself. This is much more user friendly and less error-prone.
> which should be
> taken into account, when draft is true. Just as latex does.
No it doesn't. LaTeX is stupid in this sense, the driver does
make the job. And, for example, if you look at the bitmap
support of driver dvips.def, it's just horrible, it doesn't support
viewport, clipping, ... dvipdfm.def isn't better in this respect,
I had to (re)write the bitmap support of these drivers for a
new package of mine.
[color=darkred]
| |
| Herbert Voss 2006-07-24, 7:03 pm |
| Heiko Oberdiek wrote:
> No it doesn't. LaTeX is stupid in this sense, the driver does
> make the job. And, for example, if you look at the bitmap
> support of driver dvips.def, it's just horrible, it doesn't support
> viewport, clipping, ... dvipdfm.def isn't better in this respect,
> I had to (re)write the bitmap support of these drivers for a
> new package of mine.
ah, I see. You're right ...
Herbert
--
http://PSTricks.de/
http://TeXnik.de/
http://www.dante.de/CTAN/info/math/...de/Mathmode.pdf
http://www.dante.de/faq/de-tex-faq/
http://www.tex.ac.uk/cgi-bin/texfaq...ntroduction=yes
| |
| Ulrike Fischer 2006-07-25, 4:06 am |
| Heiko Oberdiek <oberdiek@uni-freiburg.de> schrieb:
>
> The error message is:
>
>| ! LaTeX Error: Cannot determine size of graphic in hei (no size
>| specifed).
>
> This is the correct, see grfguide:
>
>| draft suppress all the `special' features. In particular graphics
>| files are not
>| included (but they are still read for size info) just the
>| filename is printed in a box of the correct size.
>
Yes, I know that is the documented behaviour. But I was asking for an
additional or improved behaviour: If draft (or another/new key) is
enable there should be no errors if the graphic is not there but
LaTeX/pdfLaTeX should try to get the size info from the existing keys
or use fall back values.
I could write a fake \includegraphics-command with similar keys which
draws only a frame, but it would take some time to get all the key
combinations right (angle/width/trim/scale) that could change the size
of the frame. And it looks like I would do a work twice: graphicx
already knows how to handle this combinations.
At my opininion there must be an easier way. Couldn't one add a fall
back graphic "missing-graphic" to the package that is used if draft is
active and the real graphic is not found? So that with activated draft
LaTeX/pdfLaTeX handle missing images like a browser a html when an
image is not found?
--
Ulrike Fischer
e-mail: zusätzlich meinen Vornamen vor dem @ einfügen.
e-mail: add my first name between the news and the @.
| |
| Heiko Oberdiek 2006-07-25, 4:06 am |
| Ulrike Fischer <news@nililand.de> wrote:
> Yes, I know that is the documented behaviour. But I was asking for an
> additional or improved behaviour: If draft (or another/new key) is
> enable there should be no errors if the graphic is not there but
> LaTeX/pdfLaTeX should try to get the size info from the existing keys
> or use fall back values.
>
> I could write a fake \includegraphics-command with similar keys which
> draws only a frame, but it would take some time to get all the key
> combinations right (angle/width/trim/scale) that could change the size
> of the frame. And it looks like I would do a work twice: graphicx
> already knows how to handle this combinations.
No, not completely. Much is done in the driver definition files in the
macros that support the different kinds of image files. Thus you have
to reinvent most of the wheel for non-existing images anyway.
File existence is used in many places of graphics:
* looking for file extension
* information about size
* image inclusion
The main macros are \Ginclude@graphics and \Gin@setfile.
Adding support for non-existing files means a severe change
of design. You need a new algorithm that rewrites/replaces these
macros. And if you look at other deficiencies of graphics you will
probably end up with a successor of graphic(s,x). How much time
you want to invest?
Yours sincerely
Heiko <oberdiek@uni-freiburg.de>
| |
| Ulrike Fischer 2006-07-25, 8:03 am |
| Heiko Oberdiek <oberdiek@uni-freiburg.de> schrieb:
>
> No, not completely. Much is done in the driver definition files in the
> macros that support the different kinds of image files. Thus you have
> to reinvent most of the wheel for non-existing images anyway.
>
> File existence is used in many places of graphics:
> * looking for file extension
> * information about size
> * image inclusion
> The main macros are \Ginclude@graphics and \Gin@setfile.
> Adding support for non-existing files means a severe change
> of design. You need a new algorithm that rewrites/replaces these
> macros. And if you look at other deficiencies of graphics you will
> probably end up with a successor of graphic(s,x). How much time
> you want to invest?
OK. So I tried my second idea: I put a small missing-img.eps (it
contains only a bounding box) and a missing-img.png in my local texmf.
And then I added a switch to \Ginclude@graphics (I used only the value
of the draft boolean, but one could also add an independant one):
\documentclass{minimal}
\usepackage[draft]{graphicx}
\makeatletter
\catcode`\*=11
\let\OriGinclude@graphics\Ginclude@graph
ics
\def\Ginclude@graphics#1{%
\begingroup
\let\input@path\Ginput@path
\filename@parse{#1}%
\ifx\filename@ext\relax
\@for\Gin@temp:=\Gin@extensions\do{%
\ifx\Gin@ext\relax
\Gin@getbase\Gin@temp
\fi}%
\else
\Gin@getbase{\Gin@sepdefault\filename@ex
t}%
\ifx\Gin@ext\relax
\@warning{File `#1' not found}%
\def\Gin@base{\filename@area\filename@ba
se}%
\edef\Gin@ext{\Gin@sepdefault\filename@e
xt}%
\fi
\fi
\ifx\Gin@ext\relax
\ifGin@draft % <------------ new
\@warning{File `#1' not found, using missing-img instead}%new
\OriGinclude@graphics{missing-img}%<---------- new
\else%<------------new
\@latex@error{File `#1' not found}%
{I could not locate the file with any of these extensions:^^J%
\Gin@extensions^^J\@ehc}%
\fi%<------------- new
\else
\@ifundefined{Gin@rule@\Gin@ext}%
{\ifx\Gin@rule@*\@undefined
\@latex@error{Unknown graphics extension: \Gin@ext}\@ehc
\else
\expandafter\Gin@setfile\Gin@rule@*{\Gin
@base\Gin@ext}%
\fi}%
{\expandafter\expandafter\expandafter\Gi
n@setfile
\csname Gin@rule@\Gin@ext\endcsname{\Gin@base\Gi
n@ext}}%
\fi
\endgroup}
\catcode`\*=12
\makeatother
\begin{document}
\includegraphics[width=5cm,height=1cm]{d
ontexist}
\includegraphics[width=1cm,height=3cm]{a
nother}
%
\includegraphics{hei}
\includegraphics[bb=10 10 150 150]{hei}
\includegraphics{dont}
\end{document}
It seems to work fine. No errors more in draft mode and more or less
accurates frames.
--
Ulrike Fischer
e-mail: zusätzlich meinen Vornamen vor dem @ einfügen.
e-mail: add my first name between the news and the @.
|
|
|
|
|