ouij@xurilka.UUCP (exhausted jazz surfer) (08/18/90)
Synopsis of Level II
Here is Level II info that is derived from
the Adobe Press Kit and the august 1990 byte
clipping.
This list is no means complete and only
intended as an overview of what we PostScript
developers and programmers should be excited
about. Once again, Calling up adobe and asking
for the level II press kit, guarantees that you
will know everything that there is to know!
===========================================================
Level II offers improvements in three areas
a) implementation, new algorithms.
b) language extensions
c) overhaul of color system to meet demands of
professional printing.
Implementation changes
----------------------
Like all programs that get used in the real world,
people have comments or suggestestions as to how
a program should behave or situations where the
program is inadequate. Also developers of Programs
realize improvements. PostScript is no different.
Changes that the average end user probably won't notice
except in improved execution times are
i) new clipping algorithms
ii) improved memory management system
Instead of the current `segmented' memory strategy
currently in use, there is one memory `pool'.
iii) new halftoning technology. Adobe claims that control
over screen angles is more fine tune.
iv) ATM font rendering technology which Adobe claims
``enable PostScript devices to build characters two to three
times faster and improves the quality of text at small
point sizes and low resolution''
Language extensions
-------------------
i) Data compression of four flavours
CCITT Group 3 and 4,
run-length encoding,
JPEG (Join Photographic Experts Group??),
ASCII/85 and ASCII/HEX...
[Byte claims that level II supports Lempel-Ziv-Welch
compression but nowhere in my press kit does adobe
mention LZW, thus I take the position that adobe is
correct. Perhaps some kind soul from adobe would
care to comment?]
I am personally disapointed that LZW compression
was not included since it is the most commonly used
compression scheme around (ie unix utility compress, TIFF,etc).
However this may be due (and this is pure speculation) to
the recent attempt of Unisys which holds the patent to LZW making
legal noise. Also, LZW is not adequate for color (if memory
serves me correct) LZW acheives between 1.1 and 1.7 compression
ratios. JPEG offers as much as 25 to 1.
can anybody comment on what ASCII /85 and ASCII HEX are ???
CCITT stuff will come in handy as we see the proliferation of
PostScript fax machines.
Data compression of images should make *plenty* of people happy.
No longer must one transmit a 1Megabyte plus file at 9600 to
a printer. Now we must wait for the interpreter to finish
uncompressing the image! However this should not be noticeable
since
ii) PostScript now reads binary directly in addition
to ascii. So for images,
the overhead of converting the ascii string to actual representation
is no longer there.
iii) New graphics and text operators.
Supposedly these new operators are all from
Display PostScript: rectangle operators, graphic
state objects, halftone specification, user paths,
stroke adjustments, text operators which offer better
control over font use, kerning, and justification.
Since I know nothing about DPS, i can't comment
except to say that the new text operators are
a welcomed addition.
Compostie font extensions:``These extensions enable
developers to use the PostScript font mechanism to encode
very large character sets and handle non-horizontal writing modes''
iv) forms and patterns. This has been discussed in
in much better detail by
Date: 14 Aug 90 21:49:29 GMT
Reply-To: orthlieb@adobe.COM (Carl Orthlieb)
Organization: Adobe Systems Incorporated, Mountain View
Lines: 54
>David Gelphman pointed this article out to me and had some informative
>things to say about forms and patterns under PostScript Level 2.
[my misconceptions deleted]
> There is a slight misconception here as to the way that forms and
>patterns actually work. In PostScript Level 2, a form is a PostScript
>dictionary which follows certain guidelines (similar to those for fonts).
>One of the keys in the form dictionary is a PaintProc procedure which is
>responsible for imaging the form. When the form is first imaged (with
>the execform operator) the PaintProc procedure will be called to image the
>form. Depending on the amount of available memory, the results of
>executing the PaintProc may also be cached. The actual type of data which
>is cached may depend on the resolution of the output device and other factors.
>In any case, the cache is not necessarily a bitmap representation of the form
>and it is not possible to manipulate the cached representation (just as
>it is not possible to manipulate the cached representation of a font). One
>significant difference between a form and a font is that a form may contain
>color information and still be cached. Indeed calling this mechanism a 'form'
>is perhaps misleading because it is potentially useful for more than the
>standard notion of forms.
> Patterns work in a somewhat similar manner to forms in terms of caching
>but are used in a completely different manner. Patterns are used as paint
>to fill and/or stroke paths, painting characters, or bit images which are
>used as masks. As with forms, patterns can contain arbitrary PostScript
>graphics except there are some restrictions on using patterns within patterns.
> One critical design point is that regardless of whether the imaging of a
>character, a pattern, or form is from a cache or not, the results should
>be identical. The only difference is a performance win when the
>cache is used.
>David G.
forms will be a valuable addition to all. I only hope
that some interpreters will allow saving the bitmap
of the form to disk. In some cases (depending
on the graphic complexity), it would be
faster to read in the bitmap than redefine the form
and reinterprete the PostScript definition.
*******************************************************
Color revamping.
PostScript now tackles color head on by supporting
the following models.
a) CIE XYZ : ``allows a linear transformation of XYZ
followed by an individual transformation of the
resulting three components. (also known as
Calibrated RGB)
side note: for an execellent paper showing the benefits
of CIE XYZ and color reproduction (and how true device
indepedant color can be acheive),
look for a paper which I belive is entitled
``Color Gamut mapping and transformations'' by Maureen
Stone et al, 1988 (or 87) Transactions of Computer Graphics
ACM
b) CIE Y--``the achromatic component (Y) from XYZ
with any arbitrary transformation applied to it.
c) CIE L*a*b* --``uniform color space developed in 1976,
based on the 1931 CIE XYZ standard.''
d) CIE L-- the achromatic component (L) of the L*a*b* standard
e) Indexed-- compresses color specifications, reducing the number of
bits necessary to specify a color
f) Device Gray-- device dependent achromatic space
g) Device RGB
h) Device CMYK including black generation and undercolor removal
screen and transfer functions for four separate color components,
c) Device Separation-- ``to produce color separations of named
spot colors.''
Experience and seeking the advice of leaders in color
reproduction, Adobe has done well by offering a wide
range of models which support device independant color
much better than the color extensions for level I.
My general opinions. Adobe should be well commended
for their effort to make PostScript competitive
and more productive in the industrial world.
I tend to see that adobe is putting in
more hooks to the language for increased
execution speed. However the emphasis will on
the device driver writers.
For example, let us say that I owned a
Word Processor and wanted to print out
to a PS device, i would make sure to
take advantage of the new text operators
to increase speed and offer better
looking output. Same holds true if
I did color work useing a certain model. Level II
has the hooks and is more attractive to the
segment that currently does not use PostScript
because it failed to be competitive with traditional
methods.
The way I see it, All the color stuff will be more
important immediately to people who do high end
printing and the rest of mere mortals who
don't do color sep's or own a color postscript
device (sniff. sob..sob.. the dream is always
the same) will delve heavily
into exploiting Level II specifics by early
91 once we have the new RED book in hand.
For the people who probably make up
over 90% of the PostScript market who use PostScript
but don't realy know what it is about,
wil be happy in very late 91 as
the applications commonly in use
have their level II prologues and device
drivers and once we upgrade our PostScript
devices.....
two small observations:
1) The byte article claims that it will take a
couple of years before
widespread acceptance of level II. I disagree.
If Level II really delivers what is claimed.
All the high end people will be demanding that
their applications deliver level II prologues.
This will force the applications group (
Corel Draw, PageMaker,etc..) to
deliver as fast as possible which will be
beneficial towards the general public.
[jumping into asbestos suit]
2) to some of us, the name of the game is
increased performance. This theme permates
through out the the Press Kit. So naturally,
the question becomes, `well how much faster
is level II'. Interestingly enough, Adobe
claims that currently are no benchmarks
on performance. They will release them
as soon as they are available.
I am disappointed, some sort of figures
should have been released. if this was
the academic world and adobe wanted their
work published, they would have
had to compare it to everything similar
in the known universe, implement it
and provide reams of tables verifying
their hypothesis that level II is
faster.
Only 3 or 4 months to go before
the red book comes out and my
itch is scratched.
Ouij
On vacation till August 25th.
``The earth has a flesh with skin and
``The earth has a skin with it's disease are the thousands of
flesh and it's disease is idiots who purchase PC products''
man'' --Neitzche -- former tech support Ouij