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
> 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
> >> 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
> 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
>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
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
> 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
> 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]](../../../../asciidoc/images/icons/note.png){kind=icon} | |
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.
> 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.
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
> >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
>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
