#Cool Clip Art Cheap
27 messages in this thread
If anybody has been thinking about ordering clip art from the Soft-Logik
Graphic Library (from that cool poster we sent all our users), but can't
decide, now is a good time. We have a special deal running on them until
the end of September if you call our sales line. They'll give you full
details. 1-800-829-8608. The prices are very good. The poster doesn't
really say, but there are roughly 75-125 structured drawings in each
package. They are all in Adobe Illustrator EPS format, which means that you
can edit them in PageStream or Art Expression for printing to any type of
printer. (As well as importing as PostScript in ProPage or ProDraw.)
If you don't have a graphic poster, call sales and they'll send you one. It
has our 600 PostScript fonts on the other side.
Prices are as low as 33 cents per drawing. That's cheaper than clip art
which isn't anywhere near as good. You can't buy better structured clip art
for the Amiga. Prices for the same clip art on the PC or Mac are twice the
price.
Michael Soft-Logik
Thanks for the promotion!
Michael
Sorry to be a bit pedantic, but your statement `They are all in Adobe
Illustrator EPS format, which means that you can edit them in PageStream or
Art Expression for printing to any type of printer…' isn't the full story
and implies that you can actually edit the EPS itself.
Unless PageStream has had a full PostScript interpreter and editor added
since I last looked, I would assume that all you could edit is the
bit-mapped image which is part of the EPSI format. The underlying
structured graphic will remain untouched.
A dot-matrix printer would therefore use the `revised' bitmap for output,
but a PostScript printer (and also PPage and PDraw) would either take the
original (and unedited) EPS structure … or the modified bitmap image
(although I'm not sure how you'd get PStream to save an EPS image in a
PostScript file as a bitmap).
Mike (from the UK)
Wrong. The Illustrator import module deciphers Illustrator EPS files and
turns them into normal PageStream objects. It's just as if you had opened
them in Adobe Illustrator or Corel Draw. They are a collection of grouped
objects, not a box with a cross or a box with a bitmap header. Illustrator
EPS is a well-documented format which PageStream and Art Expression can
read.
So, you can edit them, delete parts, add parts, color them, and print them
to any type of printer.
This has been in PageStream for some time now. I believe we released the
first version of the module shortly after 2.1 was released.
Michale Soft-Logik
Michael
I don't know Illustrator (which is probably quite obvious by now :-), but I
must therefore assume then that it uses a very limited and/or carefully
structured subset of PostScript to provide its structured images?
If that's the case, then I can understand how PStream could handle it …
otherwise you _would_ have to have a PostScript interpreter built in.
It begs the question, what happens to an Illustrator file that itself
includes an external EPSF? Do these embedded EPS objects just appear in
Illustrator as outline boxes?
Mike (from the UK)
A lot of people get this confused. I think Mike's right here… EPS is a
subset of PostScript. AI files are a subset of PostScript. AI files can be
wrapped in EPS structured comments, making them EPS files. Application
developers and their marketroids often say, yes, we can read EPS files and
edit them – a more general statement than the truth, which is they can
safely edit AI EPS files. What's an external EPSF? An EPS file named by
reference in a PageStream document? I wonder what AI does when you place an
EPS file in a drawing… Hmm, something strange, I never asked that
question before. 🙂
John,
EPS is _not_ a subset of PostScript. It is a set of conventions for
including one PostScript file within another (host) program or PostScript
file.
AI is _not_ a subset of PostScript. Every possible PostScript operator is
available in AI. AI saves it's data in a file format that meets the
definition of EPSF structuring conventions. It is rather unique to AI, but
is well documented, and straight forward (Adobe is after all the inventor
of PostScript).
Other than Pagestream, AI itself and Aldus' EPSF translator (the name
escapes me right now), I don't think any other programs actually read AI
EPSF format. Even Adobe's Photoshop wants Illustrator to export in the more
generic EPSF format before it will munch on Illustrator data.
Rich
I beg to differ. Certain PS commands are not allowed in EPS, therefore,
it's proper to consider it a subset. Those structured comments are allowed
in PostScript, but 'showpage' isn't allowed in EPS. AI files are strictly
structured. They do not necessarily contain the procedures needed to
print, but they always contain the data of the lines, curves, etc. in the
drawing. Therefore, not all AI files are EPS files.
A lot of drawing programs read and write AI files. (I wrote the
translators in Harvard Draw for Windows.) My code handled both straight AI
files and EPS files that happen to contain AI data.
John,
Hmmm. The definition of a "subset" of a language's commands might get a
little strained here. By your definition, the PostScript file that gets
sent to most PostScript devices by application programs is a subset of
Postscript. That is, under certain conditions, common sense must prevail,
and operators that do exist in the language, but are intended for special
setup procedures, should not be used.
In that sense, PostScript as a page description language (PDL) is a subset
of all the possible PostScript operators that are available for device
operation (Printer Control Language, or PCL).
There is a list of operators which are "illegal" or "restricted" and should
not be used in an EPSF. Their use in _any_ file is problematic and only
appropriate by the (human) controller of an imagesetter (who is actually
the system administrator). So the full language always contains more
operators than are recommended for general use. And many consider EPSF as
general use.
Interestingly, 'showpage' is _not_ one of the restricted operators,
although its inclusion in an EPSF could cause problems if the host program
does not know how to handle the situation.
Appendix H of the PostScript Language Reference Manual, 2nd edition nicely
describes all the prudent care that a programmer must exercise.
With regard to showpage:
p 719
Redefine showpage
The showpage operator is permitted in EPS files because it is present in so
many PostScript language files. Therefore, it is reasonable for an EPS to
use the showpage operator, although it is not necessary if the EPS file
will only be imported into another document. The application importing the
EPS file is resonsible for redefining showpage.
Then there is an example for redefining the showpage operator to null:
/showpage {} def
Rich
Richard
I would agree with John that, in a strict sense EPS _is_ a subset of the
PostScript language since some commands are specifically forbidden by the
standard and additional restructions are placed upon the program (albeit
the command set is 99.9% of PostScript and, as you say, even SHOWPAGE is
permitted [although at one time it _wasn't_]).
These, and other, operators are available at all other times … it's just
that their use is ill-advised. They're not expressly forbidden by the
language definition.
Mike (from the UK)
Mike,
Yeah, I think we're saying the same thing.
8)
Rich
I stand corrected regarding 'showpage' and legal operators within EPS
files…
John,
Understood.
The so-called illegal commands in EPS files are banddevice, clear,
cleardictstack, copypage, erasepage, exitserver, framedevice, grestorall,
ititclip, initgraphics, initmatrix, quit, renderbands, setglobal,
setpagedevice, setshared, startjob,
all operators in statusdict and the operators in userdict for establishing
an imageable area.
I can't imagine using any of these operators in _any_ PostScript file other
than a special device set-up program.
Also nulldevice, setgstate, sethalftone, setmatrix, setscreen, settransfer,
undefinefont must be used with great care.
Rich
John
I'd agree with your interpretation of what I was trying to say.
An EPS file doesn't have to have any print procedures (although showpage is
_not_ one of the forbidden operators any more as it can [and should] be
redefined by the `host' PostScript program).
My feeling is that, in order to be able to manipulate an Illustrator file,
there must be a fairly rigid set of rules being obeyed and a fairly small
subset of the PostScript language being used.
Mike (from the UK)
John,
I really hate to disillusion you, but 'shopage' IS allowed in EPS. I
have NO idea what those FOOLS were thinking of when they allowed it in the
spec, but Adobe says it's ok <sigh>
Vic,
The answer is simple. "Those FOOLS" knew what they were doing. There is no
way for the creator of an otherwise generic PostScript file to know if that
file may get used by someone else as an 'encapsulated' variety.
Say, for instance, I want to place your elegantly designed page in my
anthology of beautiful page designs. I can ask for your PostScxript file,
encapsulate it, import it into my properly behaving host file, size it,
rotate it, whatever, and display it along side other page designs, all
without actually touching the original page in any way.
PostScript being the extensible language that it is, allows for handling of
an (otherwise) unwanted operator. Actually, a host program could, if it
were well designed look for _any_ unwanted operator and filter it out or
otherwise nullify it. Setup programs for imagesetters try to do that.
Rich
Richard
Generic PostScript files were never intended for inclusion in other
documents. If you _do_ want to include a PostScript file, then it has to
be designed that way in the first place; simply `wrapping' any old PS file
with the EPS structured comments won't do.
In other words, it's the _original_ PostScript file that must be
well-behaved … after all, there are many perfectly acceptable PS files
that could never work as an EPS but there are few EPS files which couldn't
be used as stand-alone files for output.
Mike (from the UK)
Mike,
I have to disagree with you. PostScript was designed as a very extensible
and flexible language. One of the most importatnt design aspects is the
ability to save the graphics state without any overhead penalties. This
allows an importing program to handle redefining, nullifying, and otherwise
handling just about anything it wants to import.
Adobe has made very strong recommendations regarding structuring
conventions. And these are very important to avoid choas in the writing of
various kinds of spoolers and other utility programs, as well as the
ability of disparate applications to know what to expect from a 'properly
behaving' incoming file.
However, _none_ of the structuring conventions prevents a generic
PostScript program from becoming an importable entity. It is impossible to
anticipate the final use of a PostScript program, although the _intended_
use may be very clear at the time of its creation (ex. a file destined for
an imagetter). This is part of the beauty of the language.
Certainly, adhering to all the conventions re EPS files makes handling of
files which are _always_ intended to be imported into another file much
easier.
Generic PostScript files can and _should_ be designed so that their
eventual use can _always_ be determined by the environment in which they
are finally placed, whether that environment is a PostScript output device,
or the unanticipated inclusion into another file. As a matter of fact if
"simply wrapping any old PS file with structured comments won't do", there
is every reason to believe that the original file is suspect. It should
_not_ be that hard to accomplish the encapsulating. That is, the incoming
PS file should not use commands in a way that creates havoc in any
environment.
The single most important advice I have read re PostScript programming (or
any other computer programming, for that matter) is, "speak in whispers,
leave no footprints."
Rich
Welcome to the land of no real standards, huh? I had a blast with things
like this… even between different versions and platforms Adobe
Illustrator is finicky about the format of its own files: it's sensitive to
the order of seemingly unrelated structured comments, sensitive to the
absence of presence of commands from other programs that supposedly write
AI files, etc.
Are there any commands not allowed in EPS files?
Yes, there are commands which are forbidden in an EPS file, such as
banddevice, exitserver, initgraphics, erasepage, initmatrix and renderbands
… there are also others (such as nulldevice, sethalftone, setmatrix,
underlinefont and setgstate) which must comply with very specific rules so
that they don't affect the global document.
Some of these commands could quite easily appear in a stand-alone
PostScript document but should not in an Encapsulated PS file.
Mike (from the UK)
No, Adobe Illustrator is a very sophisticated drawing program. They just
document their format very well. Aldus Freehand is a similar program, but
the don't document their format very well. Translating EPS to DR2D or
PageStream's internal format is not a big deal if the EPS being translated
is well document.
What happens to embedded EPS objects in Illustrator files? Good question,
I've never thought about that before. I imagine they're just placed as EPSF
blocks because they can't be translated.
BTW, Stylus, the guys who do ProVector, another drawing program, now have
something called PSImport. They claim it will take _any_ EPSF and translate
it to DR2D. Basically a PostScript interpreter. Cool.
Michael Soft-Logik
Will PageStream read in the newer AI files, too ?? Or just AI 88 files.
Freehand (on the MAC) could read in and edit AI 88 files, but can not read
in the new version of AI. What is true of PageStream ?
Brian
Brian,
I too am interested in finding that out. After reading Michael's remark
that Pagestream can import AI as an object and edit it from within the
program, I tried it using AI 3.01 and it imported a mess instead of the
simple box and text object I had made. As an EPSF file it displayed the
attached bitmap image fine and printed it to PS without a hitch, but not as
an object. I tried a version 1 AI import but not the 88 version. I'll have
to go start AMAX back up and redo my experiment.
Chris
Make sure you have the latest Illustrator import module from our Amigaven
section. We've updated it several times. I just uploaded a new IFF DR2D
import module and new IFF ILBM modules.
Michael Soft-Logik
Michael,
I did get the newest ILBM modules from the LIB. I also reread the addendum
for 2.2HL and it says that it doesn't presently support the text mode of
IL. I don't remember if I converted the text to objects before saving it to
disk. It was a very very simple structured graphic. Nothing too
problematic, a few rectangles, a polygon, etc. I'll try another one and let
you know.
Chris
Illustrator 88 import into PageStream and Art Expression is very solid. 3.0
files can be imported, but there are some that won't import. I guess there
are some newer features that we haven't added support for yet. We'll work
on improving the module more in the future to handle 3.0 files better.
Michael Soft-Logik