> 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.
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...}
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).
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.
dvips 5.92b .. %%EndBinary error
If bytecount is wrong "eps2eps" (Ghostscript bat file)
will solve the problem ..
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.)
> 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.
> >> 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).
> 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!
>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.
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.
> 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
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.
> 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??,
> 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.
|
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.
> 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.
> 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)?
> 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.
%--- 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 ---
> >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.
>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.
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' ?
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.
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.
jpeg2ps produce very bad results
> >> 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
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 …
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.
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?
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.
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.
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.
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:-
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.
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.
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…
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.
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.
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:
-
- >8 - -
\begin{document}
\DeclareGraphicsRule{.gif}{eps}{.gif.bb}{`convert #1 'eps:-' }
\includegraphics{test2.gif}
\end{document}
- - >8 - -
$ 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