Preview / YAP / Printing / Digitial Librarian
Andrew Zimmerman
I'm having a problem using Preview to display a ps file.
The ps is the output of dvi2ps which contains a MacDraw file
(And the necessary header). The file was generated on a DEC3100.
I am able to preview this file using the program dxpsview on a
DEC3100, but Preview just prints out a blank page.
Interestingly enough, YAP will almost print the same file.
(Yap would work, but it appears tht YAP doesn't know about pages, and
therefore overlays all of the pages at once.)
Why is it possbile for YAP to display this file, while Preview
gets confused?
Is there anyway to print multiple files on the NeXT? It seems that I
have to open each file, and then do a print command. Since some of the
documents consist of many files, I would like to just be able to select
all of the files I would like to print at one time, and have the print
command (on the workspace menu) open all of the files and issue the print
command to each file. Same holds true for the Librarian.
Is there any way to have the Librarian go though each of the chapters of
a document in sequential order?
Thanks for any help,
Meinhard E. Mayer (Hardy)
There are some differences between dvi2ps and dvips (in my case the
latter works and the former dies).
I have been printing to a LaserjetIIP, and it seems to choke if you
feed it too much at once.
For printing multiple files use lpr from a shell.
Hardy
-------****-------
Meinhard E. Mayer (Prof.) Department of Physics, University of California
Irvine CA 92717;(714) 856 5543; ha...@golem.ps.uci.edu or MMA...@UCI.BITNET
Ronald C.F. Antony
> Is there anyway to print multiple files on the NeXT? It seems that I
>have to open each file, and then do a print command. Since some of the
>documents consist of many files, I would like to just be able to select
>all of the files I would like to print at one time, and have the print
>command (on the workspace menu) open all of the files and issue the print
If someone has the time, it should be possible to write an app that
does this. Fist open the nth file, then pump a number of events to the
app that will open up the document (NXJournaler) such that the
document is printed....
Ronald
------------------------------------------------------------------------------
"The reasonable man adapts himself to the world; the unreasonable one persists
in trying to adapt the world to himself. Therefore all progress depends on the
unreasonable man." G.B. Shaw | r...@cs.brown.edu or ant...@browncog.bitnet
Mike Dixon
If someone has the time, it should be possible to write an app
that does this. Fist open the nth file, then pump a number of
events to the app that will open up the document (NXJournaler)
such that the document is printed....
you might want to try 'open -p' before you go to all this effort...
--
.mike.
Ronald C.F. Antony
sure, but that does not solve all the problems. (e.g. you can't give a
printer as a parameter, or a fax number or a file that should be used
to save the ps output in etc.) A nice, uniform macro language, like
LISP, that takes over what the shell scripts did for CLI-level
problems is missing. I say LISP since that proved useful for many
nontrivial things: AutoLisp, elisp etc. A regular script language like
Bill Gates Basic-as-embedded-language, does not cut it. Things like
recursive operations would be a pain to formulate in such an
environment.
While we're at it: all the graphics is nice for dummy-users, as is
marcro recording of user events. But what keyboard equivalents are to
mouse actions, are macro languages to journalling. And would be an
Interface Builder that optionally spits out code instead of .nib
files. Has anyone ever tried to carefully document a program that uses
the Interface Builder? I'd like if I could print out source for what I
did there. At least I could follow what was done. e.g. how does a
student turn in a .nib file for a programing assignment? Shall the
TA test every connection by clicking on them?
As good and as practical as .nib files are, there is a need to have
some textual equivalent to them.
Mark Interrante
>In article <1991Mar20....@data.com> s...@data.com (Steven M. Boker) writes:
> Those at NeXT who
> are reading this should take note. Implementing Ronalds idea would
> be a boon to the more-than-casual developer.
>
>Why not write an IBdocument.app and implement Ronald's idea your self?
>Your app could interface with IB seamlessly if you implement the app using
>NeXT's "services" paradigm.
I am more interested in what other developers think should be included
in upcoming versions of IB. It seems that additional interface/data structure
classes can be easily incorporated into IB so that is no longer an
issue for IB-only development.
Possible areas:
1. configuration support tools (multiuser)
2. an integrated graphical compiler/debugging tools. (ala mac/PC
tools) of course this need not be part of IB per se.
3. I would like the ability to double click on just about anything in
IB and have it open up or at least have an inspector popup.
4. ?
This is one tool that NeXT has the lead in, what do others want
included to help maintain that lead?
-----------------------------------------------------------------------------
mark Interrante Software Engineering Research Center
m...@beach.cis.ufl.edu CIS Department, University of Florida 32611
-----------------------------------------------------------------------------
Quote from a west Texas farmer "status quo is Latin for the mess we're in."
Steven M. Boker
[many good comments deleted]
>As good and as practical as .nib files are, there is a need to have
>some textual equivalent to them.
I agree completely here. Documentation of my IB work is a manual task
at this point. It shouldn't be. I think Ronald has pointed to one of
the few weak spots in the IB development process. Those at NeXT who
are reading this should take note. Implementing Ronalds idea would
be a boon to the more-than-casual developer.
Steve
--
#====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
# Steve Boker # En Vino Kaos #
# s...@data.com # En Kaos Veritas #
#====#====#====#====#====#====#====#====#====#====#====#====#====#====#====#
cnh...@maraba.tamu.edu
are reading this should take note. Implementing Ronalds idea would
be a boon to the more-than-casual developer.
Why not write an IBdocument.app and implement Ronald's idea your self?
Your app could interface with IB seamlessly if you implement the app using
NeXT's "services" paradigm.
--
"Battle not with monsters, lest ye become a monster,
and if you gaze into the abyss, the abyss gazes also into you."
-Friedrich Wilhelm Nietszche
Steven M. Boker
> Those at NeXT who
> are reading this should take note. Implementing Ronalds idea would
> be a boon to the more-than-casual developer.
>
>Why not write an IBdocument.app and implement Ronald's idea your self?
>Your app could interface with IB seamlessly if you implement the app using
>NeXT's "services" paradigm.
The basic problem with a third party IB scripting language is that it
doesn't have the "standards" power that a release from NeXT would have.
I agree that if NeXT decides that it has no intention of producing such
a .nib scripter, a third party would have a hot product here. However,
any release from NeXT would blow a third party away. Its a good idea,
but a dangerous one from an investment standpoint for a third party
developer.
Steve.
Steven M. Boker
>
>I am more interested in what other developers think should be included
>in upcoming versions of IB. It seems that additional interface/data structure
>classes can be easily incorporated into IB so that is no longer an
>issue for IB-only development.
>
>Possible areas:
>
>1. configuration support tools (multiuser)
>
>2. an integrated graphical compiler/debugging tools. (ala mac/PC
>tools) of course this need not be part of IB per se.
>
>3. I would like the ability to double click on just about anything in
>IB and have it open up or at least have an inspector popup.
>
>4. ?
>
>This is one tool that NeXT has the lead in, what do others want
>included to help maintain that lead?
I don't have any earthshaking suggestions, but I'd like to keep this
ball rolling. Mark and I seem to have a common interest here.
4. How about an easier way to track down all of the inherited methods
of a class? I am forever looking up ObscureClassDefinition to find
that it inherits from AnotherObscureClass which inherits from
StillAnotherObscureClass. After alot of mucking about, I've more
or less learned them, but a class documentor which read all of the
inherited (and overridden) methods and dynamically produced one
.rtf file with the union of the class and its inherited methods and
variables would be a boon. Here is one area where on-line documentation
could really shine. Override a method and the documentation file
dynamically rebuilds itself to reflect the new class definition.
Steve.
Russell Selph
nib file and produces human readable output. I needs some work
to whip it into shape, but I'll try and post it on one of the archive sites
by Tuesday, March 26.
I didn't ask for any help from NeXT on their nib file format, as I didn't
think I'd get any. As a result, Nibble may have a few hiccups on odd
looking nibs.
------------------------------------------------------------------
Russell Selph
cg10...@icogsci1.ucsd.edu
------------------------------------------------------------------
Ronald C.F. Antony
>in upcoming versions of IB. It seems that additional interface/data structure
>classes can be easily incorporated into IB so that is no longer an
>issue for IB-only development.
>
>Possible areas:
>
>1. configuration support tools (multiuser)
>
>2. an integrated graphical compiler/debugging tools. (ala mac/PC
>tools) of course this need not be part of IB per se.
>
>3. I would like the ability to double click on just about anything in
>IB and have it open up or at least have an inspector popup.
>
>4. ?
I think NeXT should have a look at Saber-C++ and Brown's Field
environment. DEC e.g. licensed Field. (if you use it non commercially,
it is available for free from Brown). For those that don't know what
Field is, here a short abstract:
Field is basically a message based glue that lets work together many
of the Unix software tool. Some of them are also extended to do more
than the basic version. This means you have a syntax sensitive editor
that checks your grammar, thus resolving many problems before you do a
compile. Then you have tools that let you graphically display complex
data structures like e.g. trees. There are also graphical interfaces
to make, x-ref tools etc.
Since the whole thing is message based, it should be relatively easy
to add other tools, use alternative editors etc.
Field supports as of now, C, C++ and Pascal. So Objective-C support
would have to added as well as an NextStep interface.
In any case, it could be inspiring for the NeXT people to have a look
at it, even more now that DEC will sell that as a product.