Picture too big 

 > I found that the snapshot that I took was too big to fit in my
 > thesis. So, I'd like to know you opinion on:
 >
 > - Is there any way that I can redefine the left margin just for the
 >   picture temporally?
 >
    The chngpage package from CTAN includes an adjustwidth environment
which does this.

Peter W.

Picture too big 

> - Is there any way that I can redefine the left margin just for the

You don't need it. \hspace*{-*cm} will work, TeX really don't mind if you try to print outside the margins. To center your picture you could use

\makebox[\textwidth]{picture...}

Ulrike Fischer

Picture too big 

> - what is the proper x-geometry(*) window width that is appropriate
>   for Letter paper?

You can resize the photo to fit your page using the \includegraphics command. For example, using the graphicx.sty package:

\includegraphics[width= 6in]{photoname}

Rather than specify an explicit dimension, you can use \linewidth. This is the horizontal distance between your left and right margins. So use of

\includegraphics[width= \linewidth]{photoname}

specifies an x-dimension equal to \linewidth and

\includegraphics[width= 0.5\linewidth]{photoname}

specifies an x-dimension equal to specify some fraction of \linewidth. This approach is independant of paper size and therefore more handy.

Of course, all of this is available in the documentation that should have come with your distribution (ex. look for grfguide.ps).

Brent

extract eps figure from postscript 

Newsgroups: comp.lang.postscript, comp.text.tex
Date: 2001-03-09 06:58:37 PST
> Is it possible to extract the EPS-figure from PostScript file produced
> from LaTex and save it as a separate file?

Look at

==> ftp://ftp.dante.de/tex-archive/support/psrip/

cmd:psrip 

Usage 

..Rolf
gv www10_sarwar.ps
psrip -d ~/discards/gens/eps !$

Info 

psrip - extracts images from postscript-files

# Version: 1.3

Source 

http://www.dante.de/tex-archive/support/psrip/ ftp://ftp.dante.de/tex-archive/support/psrip/

http://groups.google.com/groups?hl=en&lr=&safe=off&th=c1d0a50217806d36,30&ic=1

Comments 

DESCRIPTION The script saves the lines between *'%%BeginDocument: name'* and *'%%EndDocument'* to a new file named *dir/name*.

Installation 

Steps 
cd /opt
cp ~/dl/mustH_b/wp/latex/tools/psrip/psrip bin
cp ~/dl/mustH_b/wp/latex/tools/psrip/psrip.1 man/man1
chmod 755 /opt/bin/psrip

Test Run 

$ psrip -d ~/discards/gens/eps www10_sarwar.ps
psrip v1.3 by Christian Lackas (delta@clackas.de, http://www.clackas.de)
Saving images to directory '/home/tong/discards/gens/eps'.
Checking www10_sarwar.ps.
Finished (0 images extracted)
$ head !$
%!PS-Adobe-3.0
%%Creator: GNU Ghostscript 550 (pswrite)
%%DocumentData: Clean7Bit
%%LanguageLevel: 2

dvips 5.92b .. %%EndBinary error 

Newsgroups: comp.text.tex
Date: 30 Jul 2003 11:21:23 -0700
> I get the following error while running dvips 5.92b:
> dvips: ! expected to see %%EndBinary at end of data

The %%BeginBinary comment includes a bytecount for the binary data. Presumably dvips has skipped the specified number of bytes without reaching the %%EndBinary. One cause might be that the binary stuff has been corrupted during a file transfer, another that the bytecount is simply wrong.

David Wilson

dvips 5.92b .. %%EndBinary error 

If bytecount is wrong "eps2eps" (Ghostscript bat file) will solve the problem ..

Erik Van Eynde

Screen capture tools in X 

Newsgroups: comp.text.tex,comp.windows.x,comp.os.linux.x

Sven Utcke <utcke@tu-harburg.de> writes:

> > Please suggest what screen capture tools do you use under Xwin.

On X Windows, I use xv, gimp, ImageMagic, xwd, proabably in that order.

> > Besides, I found the images that I captured are too big to fit into
> > my paper
>
> What do you mean by "to big"?  You do realise that you can scale and
> crop the images when inputing into TeX, don't you?

Too big is no problem. I don't know if Tex does this automatically but there are a load of tools for rescaling including xv, gimp, ImageMagic. Each one has its strong and weak points. Sometimes the differences are dramatic. It seems to depend on the subject matter. One rule I like to follow is to use integral resize factors, cut the size by 1/2, 1/4, 1/8 somehow I just think this makes the rescaling easier. Each program gives options for smoothing and other algorithms applied. Some of them can help a lot.

> > and they look ugly.
>
> What do you mean by "ugly"?  The printout, or the screen-preview, or
> the image before inclusion?  You do realise that a gif can only
> contain 256 different colours, which might not be enough to represent
> a modern day desktop (kde, say)?  And obviously the print and preview
> quality are governed by similar concerns...

Yep, just saying ugly doesn't help. You might want to post a URL where the images are. I don't know if you can post them to this group.

> > The characters are constructed by obvious dots, not the fine looking
> > lines when seen in X.
>
> Well, it _is_ a screen capture, so it is by necessity made up of dots,
> as was the original screen.  If you see lines, then your X might have
> used antialias.  In which case you would be in for trouble either way:
> 1) Your screen has a depth of only 8bit.  In that case gif would be
>    sufficient to represent the screen-capture, but the preview would
>    most likely look butt-ugly, as only a fraction of theses colours
>    are available for preview.
> 2) Your screen has a depth of somewhere between 16 and 32 bit.  Then
>    using gif might already have ruined everything.

Do they start to look ugly after the capture, when resized or printed?

If your screen didn't show dots, then the picture shouldn't show a lot more. Providing you printer is full color. Also the technique of reducing the image size affects this a lot.

> In the latter case tiff or png would have been better formats to
> use.  Hell, even jpg would have been better, in particular if you can
> get your conversion tools to only use lossless compression...

Jpg is lossy, but it seems to fulfill its warranty and only loose things you can't see. But I agree, its best used at the end of the process for storage.

> > Using tools to sample and re-scale the images make them look
> > uglier. So,

Which tools? I've seen some that help and some that hurt. Do you really want help? Why so many secrets? (Just kidding. But think about it, the more you tell us the better chance you have.)

Dan Espen

Screen capture tools in X 

> Too big is no problem.  I don't know if Tex does this automatically

No, it simply tells the PostScript interpreter how big the image should be, and the interpreter does the rest. This usually works quite well if you keep the following in mind:

on a 300DPI-Printer there is very little point for images that have more than 100DPI after scaling. The PS-interpreter should normally be able to deal with these images if the original resolution (before scaling) would have been somewhere between 50—200DPI. Anything more, you would be better advised to do the scaling your own, using some low-pass filter before resampling to avoid alias.

Sven

Screen capture tools in X 

> >> Please suggest what screen capture tools do you use under Xwin.
> >>
> >
> > Personnally, I haven't found anything better than good 'ole xv (although
> > I haven't looked very hard)...
> Xv isnt available for all dists of Linux as its propretary.
> I use the Gimp, for screen and window capture and it works just
> as well as xv used to.

"Proprietary" is not exactly a term but xv license terms can be a trouble for a distribution maker. Ask those folks who put together "TeX Live" CDs. :-)

If your distro does not have 'xv' then most likely it comes with 'ee', a.k.a. "Electric Eyes". It will do screen captures, and other picture operations, in a manner similar to 'xv'. There should be a buch of other options as well; for example 'import' from ImageMagick suite will do a fine job (and can be used in scripts).

Michal

Screen capture tools in X 

> I viewed them with display, xnview, and gimp. and Acdsee under windows.

Don't. This is the cause of all your trouble. display, xnview, and gimp all call gs to create a bitmap from your Postscript at 72DPI. But, alas, your PS-File isn't 72DPI, it is approx. 58DPI (this, too, would not have happened with gifconv. Please use that instead!). So they are resampling the image, and the output will look _horrendous_. Instead, use gs directly, or even better, use gv. This will look _much_ better!

Sven

Screen capture tools in X 

>but there are a load of tools for rescaling including xv, gimp, ImageMagic.

Yet another tool, specifically designed for image resampling: Paul Heckbert's zoom <http://www.xmission.com/~legalize/zoom.html>. I added some file I/O support to his basic program, which lets you experiment with different smoothing options as well.

Rich

Screen capture tools in X 

Ah, now I think I understand. Your source image is an emacs window dump which contains many 1-pixel wide features. In particular there is a large amount of text in a fixed-width screen font.

This sort of image is going to be especially sensitive to resampling because of all the 1-pixel wide features. When I bring up test2.eps in Ghostview, it looks as expected. It also prints as I'd expect on my laser printer. The rescaled version looks a little blurrier, as you've downsampled it with something. It doesn't look like the downsampling introduced any aliasing, but its necessarily less legible because you started with 1-pixel wide features before you downsampled. They can't get any smaller without getting blurrier.

Dan Espen

Screen capture tools in X 

> Despite some of the other posters comments, I viewed them both
> with xv, the .eps file does look worse.

The representation of the eps-file which xv provides you looks worse. Of course it does (see my commants on this elsewhere in this or a similar thread), but the image presented to you by xv allows absolutely _no_ inference on the eps (which, in fact, does have _exactly_ the same quality as the gif).

> Specifically, the fonts are uneven.  The .eps file also looked bad
> with ghostview.

Then your ghostview is broken.

> I then converted the .gif to .ps with xv.

Don't. Although the quality of the image will be fine, the size will be horrible. At least check the compression-box offered to you in the PostScript dialog…

> I got a similar pixelated image.

No. You got what looked to you like a similar pixelated image due to some problem with your ghostview.

> I think xv is doing some rescaling based on the target paper size.

By default it will save at 72dpi resolution. When viewed in ghostview (or gv, for that) this will indeed look ugly with the default settings. In gv you can set

1.000->Pixel Based

and all will be fine. With ghostview, I do not know how to do this.

> With xv, I wasn't able to figure out the controls to stop it from
> doing that.

The save to PS-dialog offers you the possibility to set the resolution. Don't know what value would look best in ghostview though, and they have _no_ bearing on the printing process at all.

> > If anyone want to see how "bad" they are, please check out
> >
> > http://xpt.sourceforge.net/test/[]
>
> Sorry, I don't have a complete answer, you might want to try ImageMagik
> too.

No, no, no. I seem to repeating myself here :-)

You will get perfect quality postscript out of xv, ImageMagick and pretty much any other tool. However, the file will be _huge_. If you use gifconv instead, you will get a small file with still perfect quality. The only disadvantage is that the Postscript is not compatibel with PostScript Level 1 Printers, but these probably do not exist anymore anyway.

http://hepax6.rl.ac.uk/DELPHI/Adye/gifconv.html

Sven

Screen capture tools in X 

> I've prepared two image files, one .gif and one .eps. Both saved
> from the same screen capture, using the same software -- gimp. So
> there should be no lose because of the 'conversion'.

And indeed there isn't. However, the *.eps is sillily huge, and using gifconv for the conversion would reduce the size by more than 98%!!!

> - the two picture files are not the same size. (why?)

But they are! The gif is 504x481 pixel, while the eps contains an image of:

% Image geometry
504 481 8

This has admittedly been _scaled_ to fit into a bounding box of

%%BoundingBox: 14 14 418 399

(which I would not have done), but as in this case the scaling is lossless, this poses no problem. And in my version of gv this is indeed the exact same scaling which the previewer will do if "Natural Size" (instead of "Pixel Based") is choosen, so on my screen they even have the exact same size.

> - the .eps version is much worse than the .gif one.

Why do you think that? They are absolutely identical.

>   If you can magnify both images and do a comparison, you can get a
>   clearer understanding.

Hmm. I can only assume that your previewers do some sort of extrapolation or somesuch. Without, the two images are absolutely identical (except for a small white border to the right and bottom of the eps, but I assume this is an artefact of gv rather than soemthing in the image.

> I then tried to re-scale it using gimp down to 300x??,

Don't.

> which is the acceptable size for my Latex.

No, it isn't. Forget about pixel for a moment. What wide in cm (or inch, if you must) do you want the image to have in the printout? What Resolution does your colour printer have? I'll assume a width of only 5.04", which would be less than the width of your page. In that case you would end up with a resolution (when printing) of 100DPI. This should print reasonably well.

Note If you want higher quality when printing, you should stick with white, black, cyan, magenta and yellow as your colours. That purplish grey you are using must be hell for the printer… Hmm, I just tried, and indeed this looks fairly poor: only the black an green come out well. By the way, when taking your printers resolution into consideration, remeber that most low-cost printer, even though tey have a nominal resolution of more than 2000DPI, will rarely give you more than 400DPI in real life…
> I think the scaling effect should at
> least better than that does by Latex.

Unlikely, in this case.

> Moreover, I think the print
> out should be no better than a computer image view.

Using the scaled image, it must by necessity be much worse, as you were dealing with many structures that were only 1pxl wide to begin with. These do not scale down very gracefully. Leave the scaling to the PS-Interpreter. Please…

> If anyone want to see how "bad" they are, please check out
>
> http://xpt.sourceforge.net/test/[]

Except for the scaled version, they are both perfect. Your previewer is broken.

Screen capture tools in X 

> lossless, this poses no problem.  And in my version of gv this is
> indeed the exact same scaling which the previewer will do if "Natural
> Size" (instead of "Pixel Based") is choosen,

oh, that's why gimp does that "unnecessary" scaling… ahh, things are linking with each other in my mind now… :-)

> No, it isn't.  Forget about pixel for a moment.  What wide in cm (or
> inch, if you must) do you want the image to have in the printout?
> What Resolution does your colour printer have?  I'll assume a width of
> only 5.04", which would be less than the width of your page.  In that
> case you would end up with a resolution (when printing) of 100DPI.
> This should print reasonably well.

This is the most interesting part that I wanted to know. My printer (HP5) has a fairly good resolution, but previously I was forced to capture frames that are merely around 300 pixel width. Otherwise they stick out of my printing area. I know scaling those "1-pixel wide features" would be worse, so I have to choose very tiny fonts and thus the output looks really coarse. (Color is not an issue, I mostly deal with BW captures)

Back to what I should do… It is fairly safe to assume current printer will have at least 300dpi, and let's make it simple that the printing area is just 5". So there should be no problem printing a 1500 pixel width image onto the 5" printing area on a 300dpi printer. That'd be much much better than a tiny-font 300-pixel-width image. ok, here comes my question, how can I do this, capturing/printing this smooth-looking image (under X, especially for Latex)?

Screen capture tools in X 

> how can I do this, capturing/printing this smooth-looking image?

Use your usual capturing tools. You do not need to do any scaling of the image yourself. When you include the image (with \includegraphics{}, for example), specify arbitrary values for width and height that have to be pre-calculated. Example: If you have an 1152x864 pixel screenshot, and want to print it with, say, 300 dpi, it has the dimensions:

1152 dots / 300 dpi = 3.84 in,
 864 dots / 300 dpi = 1.88 in.

When viewed with gsview32 (for the PS) or Acrobat Reader (for the PDF), both in Windoze 2000, the screen capture image looks pretty bad. This is natural, because it has to be scaled down to sub-screen resolution. The resulting printout looks very fine though. Even at 600 dpi it is legible, and at 1200 dpi it is great.

Below is a sample LaTeX file. The file capture.eps is a 1152x864 screen capture image. Go to http://www.hoellenglut.de/capture for the files.

%--- begin capture.tex ---
\documentclass{article}
\usepackage{ngerman,a4}
\usepackage[dvips]{graphicx}
\pagestyle{empty}
\begin{document}
\noindent Dies ist ein Test zum Anzeigen und Drucken eines Screenshots
in \LaTeX.  "Uber ein Feedback w"urde ich mich freuen.\\~
\noindent\includegraphics[width=3.84in,height=2.88in]{capture.eps}
\end{document}
%--- end capture.tex ---

Udo Zallmann

Screen capture tools in X 

> >I got the following error when display the .eps using gv.
> >
> >Error: /undefined in @q
> Your .eps has a binary preview. gv (and TeX) aren't too happy
> with them. Russell Lang's epstool is your friend for removing
> these.

I was not sure whether some DVI previewer might need it, so i left the TIFF preview in. I could certainly have saved it without.

Udo Zallmann

Screen capture tools in X 

>One last question, is it better to calculate, then give the
>width/height accordingly, so that the DPI would be "normal" for
>printer, not something like 123.45DPI?

Yes. Printing bitmaps is device-dependent. They'll always look best if one image pixel is represented by an integral number of printer dots.

Formats such as PNG and TIFF hold resolution information; trouble is, there are very few free tools that make proper use of this information, and fewer still I'd trust to make an EPS file that'd do what I'd expect.

Stewart C. Russell

jpeg2ps produce very bad results 

Summary 

Specify eps2 target format, as in convert xxx.jpg eps2:xxx.eps

this is equal to or even better than jpeg2ps, though viewed poorly in gv du to a fault in ghostscript's screen renderer.

jpeg2ps produce very bad results 

Newsgroups: comp.text.tex
Date: 2001-09-06 17:33:30 PST
> Merz) I, sometimes, obtain very bad results.

From what I know, jpeg2ps only wraps the jpeg in a PostScript Level2 decompression programme. What doe you mean with `obtain very bad results' ?

Sven

jpeg2ps produce very bad results 

> In fact the eps file is less good than the jpeg file. But the
> result is acceptable. But when I visualise the ps file whith
> ghostscript I loose again quality. And this time the result
> become unacceptable.
> I don't have a printer near me, so I can't tell you if the
> result is good when I print the document.

It will be good when you print it.

> My image is a curve and my problem is that I have
> unwanted point near the curve. Moreover the image contain
> text and when I visualise it with ghostscript, it becomes
> very ugly.

Yes, but that is a fault in ghostscript's screen renderer.

Magnus

jpeg2ps produce very bad results 

> My image is a curve and my problem is that I have
> unwanted point near the curve. Moreover the image contain
> text and when I visualise it with ghostscript, it becomes
> very ugly.

Please, _never_ use lossy compression (which jpg usually is) with text or line drawings. I have severe doubts the jpg image was anywhere near good quality before converting (you can of course prove me wrong by privately emailing me the original jpg as an email attachment).

Use png, or even better, save directly to (non-bitmapped) eps or pdf.

Stephan

jpeg2ps produce very bad results 

David Kastrup writes:

> >> When I create an eps file
> >> from a jpeg file thanks to jpeg2ps (V1.8 from Thomas >Merz) I,
> >> sometimes, obtain very bad results.  >Is there another soft
> >> which produce good results ?
> >>
> >> I've used xv with good results.
> >>
> >> You might also try the "convert" program that comes with
> >> ImageMagik.
>
> Sven> But the resulting eps file will be much bigger, up to 2500%
> Sven> (jep, that's right, 25 times) the size you would get with
> Sven> jpeg2ps.
>
> Specify eps2 target format, as in
> convert xxx.jpg eps2:xxx.eps

Indeed!

kogs12>/home/utcke% convert zug1.jpg zug1-convert1.eps
kogs12>/home/utcke% convert zug1.jpg eps2:zug1-convert2.eps
kogs12>/home/utcke% jpeg2ps zug1.jpg > zug1-jpeg2ps.eps
Note on file 'zug1.jpg': 1024x685 pixel, 3 color components
kogs12>/home/utcke% ls -l zug1*
-rw-r--r--   1 utcke    tvp      4892610 Sep 14 14:02 zug1-convert1.eps
-rw-r--r--   1 utcke    tvp       120886 Sep 14 14:02 zug1-convert2.eps
-rw-r--r--   1 utcke    tvp       122245 Sep 14 14:02 zug1-jpeg2ps.eps
-rw-r--r--   1 utcke    tvp        95599 May 19  2000 zug1.jpg

As I now see, this is even better than jpeg2ps! I didn't know …

Sven

jpeg2ps produce very bad results 

: As I now see, this is even better than jpeg2ps! I didn't know convert
: could do this at all.

I tried this on two randomly chosen jpg files and jpeg2ps gave file sizes less than a fifth the size of the convert/eps2 files. I am sticking to jpeg2ps, warts and all.

Chris Boyd

jpeg2ps produce very bad results 

Sven> As I now see, this is even better than jpeg2ps! I didn't know convert
Sven> could do this at all.  Does it also work for tiff (instead of
Sven> tiff2ps), gif (instead of gifconv) and png (instead of bmeps, which
Sven> only works half of the time anyway)?

Cough cough. You posted the above results, didn't you? It seems that you are perfectly available of trying this out faster than it takes to post to a newsgroup.

Sven> What format would I need to specify?

eps2.

One note of caution, though: I believe that convert uses an encoding where % signs may appear in the first column as part of data. That may or may not confuse dvips and/or ghostscript.

David Kastrup

jpeg2ps produce very bad results 

I discovered, painfully, that you *must* use the jpeg2ps -h switch, to produce hex-encoded .ps (or .eps) files for use with LaTeX. Otherwise, the .ps output sometimes includes lines starting with a '%' char, and your image gets mangled.

Unfortunately, this makes increases the size of the .ps file.

Michael Friendly

jpeg2ps produce very bad results 

> Unfortunately, this makes increases the size of the .ps
> file.

Not that much, though. Where size is relevant, you'll compress Postscript with some file compressor, anyhow, and the entropy of the hex encoded file is the same as of the ASCII85 encoded one, so after compression you'll hardly notice a difference.

David Kastrup

Inserting gif pictures in latex2e document ? 

Newsgroups: comp.text.tex
Date: 1999/01/21
>     Does someone know if there is a way to insert
> the .gif picture directly into my document ?

If you are using a postscript driver (and that is what I read from your description above), you will eventually need some postscript. But it can be done on the fly if you use dvips in the following way:

\usepackage{graphicx}
\DeclareGraphicsRule{.gif}{eps}{.gif.bb}{`convert #1 eps2:-}
\includegraphics{pict.gif}

where convert is the Imagemagick program. The .bb file can be made with:

convert pict.gif eps2:- |head > pict.gif.bb

This even works on Windows systems if you have Imagemagick installed. I have fptex 0.2 installed and the relevant call is: c:/apps/tex/ImageMagick/convert #1 eps2:-

Piet van Oostrum

Inserting gif pictures in latex2e document ? 

>     I would like to insert a .gif picture into a latex2e document.
>     The only way I found to do that is to convert the gif
> picture into a ps picture using xv, and then inserting
> the ps file into the latex doc using the \includegraphics
> command. However, the resolution
> obtained when printing the document in 600dpi
> is very poor (looks like offset printing).

You should remember that the printer has to do half-toning to print your picture. You should make sure your printer is set up for printing pictures. Also remember that a 600 dpi printer can only print at the equivalent of 150dpi when printing colour. You may have more luck using the pbm utilities to convert to postscript. You can adjust it to match the resolution of your printer, and use a more complex dithering method, and avoid the printer's half-toning.

>    Does someone know if there is a way to insert
>the .gif picture directly into my document ?

Some drivers can. Dvips (I think) can't, but even if it could I doubt it would improve picture quality.

James

Sizing non-eps graphics, packages 

View this article only Newsgroups: comp.text.tex Date: 2002-01-08 08:59:45 PST

Thorsten Buelo wrote: > When I include non-.eps graphics in my document, the \textwidth > command doesn't work properly anymore. In detail, I tried to include a > .jpg picture via > > and > \includegraphics[bb=0 0 640 480,width=\textwidth]{picture.jpg} > > The picture is displayed, but unfortunately the width equals not the > textwidth, > as expected. Instead, it's a little bit smaller.

Verify that the bounding box really is "0 0 640 480". Run jpeg2ps manually, examine the results in Ghostview (or another PostScript previewer), and see if the picture is in the lower left corner and is 22.6cm x 16.9cm (8.9" x 6.7"), as that's what "0 0 640 480" implies. If not, there's a script on CTAN called bbfig, which tries to determine the correct bounding box.

Scott Pakin

Sizing non-eps graphics, packages 

> Verify that the bounding box really is "0 0 640 480".  Run jpeg2ps

Thank you, it was actually a different bounding box. I ran jpeg2ps from the command line and found in the header that the displayed bb differed from the one I determined before with another converter. Before that, I thought, the bb would be always the same, not depending on the program used for conversion. Well, I'm a little bit smarter again…

Thanks once more

Thorsten

inclugraphic and textwidth 

Newsgroups: comp.text.tex
Date: 2002-09-23 07:55:03 PST
> I have included my grafics with the following:
>
> \usepackage{graphicx}
>
> \DeclareGraphicsRule {.tif}{.bmp}{}{}
>
>
> \begin{figure}[h]
>
> \begin{center}
>
> \includegraphics[width=6cm,heigh=6cm]{bilder/per_beanspr_1.bmp}
>
> \caption[GrenzSpg]{Beanspruchungsbereiche in Abha"ngigkeit von R}
>
> \end{center}
>
> \end{figure}
>
> Everything went good, but if i exchange my includegraphics with the
> following:
>
> \includegraphics[width=\textwidth]{bilder/per_beanspr_1.bmp}
>
> i get the error:
>
> ! LaTeX Error: Cannot determine size of graphic in bilder/per_beanspr_1.bmp
> (no size specifed).

LaTeX cannot determine the size of the graphic in bilder/per_beanspr_1.bmp because you did not specify the size fully (the height is missing). LaTeX needs to know how much space to reserve for the graphic, and it can't read in .bmp files itself in order to find out.

Read grfguide. You might use an externally generated .bb file if appropriate.

David Kastrup

inclugraphic and textwidth 

I think the problem lies in the fact that LaTeX cannot guess the bounding box from a .bmp file. Therefore the first way gives no errors, while the second one fails, because the height of the picture is unknown.

A better way should be to convert your pictures into EPS format.

Enrico

Non-EPS Graphic Files 

Newsgroups: comp.text.tex

I'm trying to follow the instructions from epslatex.ps to include non-eps format graphics (.gif, .jpg…) in tex, but no success so far:

The test file is:

The latex error is:

The graphics files are:

$ dir test2.*
-rw-rw----    1 tong     tong        13468 Jul 12 22:05 test2.gif
-rw-rw----    1 tong     tong           27 Jul 13 17:21 test2.gif.bb
$ cat test2.gif.bb
%%BoundingBox: 0 0 504 481

Can anybody help me with it? thanks