bcs.jim@pro-angmar.UUCP (Jim Rinaldo) (02/24/91)
In-Reply-To: message from gessel@ilium.cs.swarthmore.edu Dan and others doing PostScript with the NeXT: has anyone else noticed the following? Build a simple IB app with a bunch of browser objects, buttons, whatever in it. Make the app so that it has a print menu. link the print menu to the created window (with the browser, buttons, whatever) so that you can print and print to disk. run the app and print the window to disk. Take a look at the code in YAP. Why is it that IB generates binaries for some parts of the window and PS for others? Why isn't it "pure." This question comes up because the publication of documentation with screen dumps IN THEORY should be resolution independent. But, due to IB impurities, it is not (along with every app for screen shooting is doing Tiffs). What's the problem? Well, if you try to imageset this, it looks like crap. The distortion patterns (moires) look crappy. I understand this happening when one is working with tiff images or EPS images with binary info in them; I understand it happening when people are doing alpha-channel graphics (if I have this wrong it is because I am still learning the cube) that have opacity setting that are not possible in PS. But I sure the heck don't understand it when it is happening in areas of windows, (where the sliders are) and other fundimental window elements. It seems that it is just do to people designing part of IB with tiffs or bitmap graphics, instead of using PS code. What do you think? Please correct me if I am mistaken. Again, I am new to the Cube, but feel this really shoots down some claims about "ultimate pub platform" if the docs come out screwy. Jim Rinaldo Editor, Computer-Aided Publishing Solutions (CAPs) The Boston Computer Society BCS: (617) 367-8080, FAX: 367-8530 pro-angmar!BCS.Jim@alfalfa.com
scott@erick.gac.edu (Scott Hess) (02/26/91)
In article <649.next.net@pro-angmar> bcs.jim@pro-angmar.UUCP (Jim Rinaldo) writes:
Build a simple IB app with a bunch of browser objects, buttons, whatever
in it. Make the app so that it has a print menu. link the print menu to
the created window (with the browser, buttons, whatever) so that you can
print and print to disk.
run the app and print the window to disk. Take a look at the code in YAP.
Why is it that IB generates binaries for some parts of the window and P
for others? Why isn't it "pure."
This really has nothing to do with InterfaceBuilder. All of the binaries
will be coming from View (and View subclasses) within the window that
output bitmaps and the like. For instance, the close/miniaturize buttons
use bitmaps. As does the scroll-bar and the up/down buttons on the
scroller (or left/right for horizontal ones). If you don't use them,
no problem. If you _really_ REALLY need pure .eps there, you'd probably
have to roll your own (in general, it's alot simpler and more efficient
to use the bitmaps, esp when moving the scroller and stuff around.
What's the problem? Well, if you try to imageset this, it looks like
crap. The distortion patterns (moires) look crappy. I understand this
happening when one is working with tiff images or EPS images with
binary info in them; I understand it happening when people are doing
alpha-channel graphics (if I have this wrong it is because I am still
learning the cube) that have opacity setting that are not possible in PS.
What are you printing with? 300dpi output doesn't look so good, in
general. NeXT printers do well, but not everyone has them. Sigh.
But I sure the heck don't understand it when it is happening in areas
of windows, (where the sliders are) and other fundimental window
elements. It seems that it is just do to people designing part of IB
with tiffs or bitmap graphics, instead of using PS code.
For many of the graphics, you should get postscript. For instance, with
Buttons, you'll be entirely postscript unless you place a bitmap in
it, in which case you'll have some bitmap data, also. Same with most
everything else.
Please correct me if I am mistaken. Again, I am new to the Cube, but
feel this really shoots down some claims about "ultimate pub platform"
if the docs come out screwy.
This isn't all that big of a deal for desktop publishing. Generally,
you won't be using screen shots/dumps. Well, for most docs you certainly
wouldn't. Of course, the NeXT documentation sort of has to, for obvious
reasons. And documentation for a program on the NeXT has good reason
to, also. But doing the page layout for a newsletter, or setting up
a newspaper/magazine really has little if any requirements for anything
but straight .eps code (you should be using ps-clipart and the like,
anyhow, right?).
Later,
--
scott hess scott@gac.edu
Independent NeXT Developer GAC Undergrad
<I still speak for nobody>
"Tried anarchy, once. Found it had too many constraints . . ."
"Buy `Sweat 'n wit '2 Live Crew'`, a new weight loss program by
Richard Simmons . . ."