A Gonzo PostScript Powerpoint Emulator

A Gonzo PostScript Powerpoint Emulator

Loading
Loading Social Plug-ins...
Language: English
Save to myLibrary Download PDF
Go to Page # Page of 7
 
Author: Don Lancaster (Fellow) | Visits: 2618 | Page Views: 2647
Domain:  High Tech Category: IT Subcategory: New Software 
Upload Date:
Short URL: https://www.wesrch.com/electronics/pdfEL11TZX3NNWKA
Loading
Loading...



px *        px *

* Default width and height in pixels. Change it to your required dimensions.

 
Contents:
A Gonzo PostScript PowerPoint Emulation
Don Lancaster Synergetics, Box 809, Thatcher, AZ 85552 copyright c2003 as GuruGram #20 http://www.tinaja.com don@tinaja.com (928) 428-4073

was rather disappointed when I first tried to web distribute a slide show that I initially created in PowerPoint. Files were fragmented and huge, appearance was awful, display was glacial, and linking was cumbersome. Worst of all, it was not letting me do my things my way. So, I instead decided to use my Gonzo Utilities written in raw PostScript to emulate much if not all of PowerPoint. The new emulation can be used from the ground up to create new slide shows, or can be used to convert an existing PowerPoint presentation to one that web distributes significantly better. It should be most useful on Linux and similar open source platforms as well. The results are totally GIF free. Large bitmaps are also easily avoided. A demo of the new emulator appears here along with its generating sourcecode. The actual gonzo utilities are found here. As always, Gonzo gives you incredible control, total device independence and complete flexibility. But is proudly not WYSIWYG. Gonzo also has a moderate to steep learning curve. What follows will make the most sense if you have an open sourcecode window and a demo slideshow nearby. Let's first pick up a few of tools we will need...

I

Backgrounds and Patterns
PowerPoint slide and splash backgrounds are normally .GIF files. Besides licensing restrictions, these have problems with file size and PDF conversion. The PostScript pattern capability found in the PostScript Language Reference Manual would seem to be a good workaround to huge .GIF bitmaps. A pattern is simply a "rubber stamp" that gets repeated over an area. These can have quite small file sizes, yet can quickly replicate themselves. Easily covering what would normally take a huge bitmap. Any repeatable image or artwork is a good pattern candidate. Here's how to take a small image and convert it into a replicating pattern...
--1--

You first create a pattern dictionary...
/bodypatdict > store

And an image (or other proc) that you want to replicate...
/bodyrandimage { gsave 5 dup image grestore} def scale % always one % width in pixels % height in pixels

% proc to get string data % color resolution % per red book 4.10 % call the image

In this case bodypatstring is a string source of image data which we will look at shortly. This could also be a small bitmap read as a file or inline as an currentfile embedding. And here is how the pattern actually gets used...
save /snap1 exch store bodypatdict matrix makepattern /bodypat exch def 00 slidewide slidehigh /Pattern setcolorspace bodypat setcolor rectfill snap1 restore % show the body background % Identity matrix % Instantiate the pattern % for the actual slide size

% Fill rectangle with pattern

--2--

A save and restore should also be used around each individual slide. Otherwise a "consumed" string pointer on the previous slide may generate errors.

Some Random Patterns
One problem I found with patterns is that they can be excruciatingly slow if the underlying generating proc is highly complex. A solution to this is to initially convert any really slow code into an image, and then replicate the image. We've already seen some interesting random images used for photo backgrounds and for our Dodge & Burn utilities. Here's a new random pattern generator with some unique features. You start with an array of [ r g b texture ]. Where r, g, and b are the "nominal" color desired. And texture is the "spread" of the three pixel colors used to make up the random pattern. A "spread" of 40 might be appropriate for adding modest background interest, while 120 will give more dramatic splash color variations. Three rgb pixel values are then generated whose values deviate from "nominal" by a zero-centered random number whose limit is set by texture. Like so...
/buildpixels {aload pop /texture exch store /b0 exch store /g0 exch store /r0 exch store 123 srand /r1 r0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store /g1 g0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store /b1 b0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store /r2 r0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store /g2 g0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store /b2 b0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store /r3 r0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store /g3 g0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store /b3 b0 texture random texture 2 div sub add cvi dup 255 ge {pop 255}if dup 0 lt {pop 0} if store } store

We then take these pixels and generate a 50 x 50 random array of them...
--3--

/makeimagestring { 12345 srand /iarray mark issize { r1 g1 b1} repeat ] store issize 2 div cvi { iarray issize random 3 mul cvi [ r2 g2 b2 ] putinterval} repeat issize 2 div cvi { iarray issize random 3 mul cvi [ r3 g3 b3 ] putinterval} repeat iarray makestring } store

% make repeatable % fill all w/color 1 % fill half w/color 2

% fill third w/color 3

And then convert the array to an image string using this disgustingly elegant off-the-wall routine...
/makestring {dup length string dup /NullEncode filter 3 -1 roll {1 index exch write} forall pop} def

Here is what our initial body and splash random patterns look like...

A 50x50 image adds 3 x 2500 = 7500 bytes to the length of your PDF file. Being random, compression is not going to help at all. A body and splash pattern pair will thus need 15K. You can reduce these values by going to smaller replicating images. Smaller images may add unattractive repeating patterns, though. Speaking of which, note the PostScript srand random seed operator. This guarantees you will get the same random pattern each time. Should a chosen pattern have glitches or repeats in it, simply try a different seed.

Handling URL's and Links
There are two elements to an Acrobat link: The url itself and an action box in which that url will be activated on clicking. Manually reentering and repositioning on-page action boxes with Acrobat can be an enormously painful process.
--4--

Instead, Gonzo provides for fully automatic action box tracking by placing markers inside its text. Thus, the action boxes will automatically move around as text gets longer or shorter. As well as automatically scaling the action box size to approximate the font height and message length. Final page placement requires no further effort at all. Full details appear in our AUTOURL.PDF tutorial found in our GuruGram library.

Emulator Organization
The key to the Gonzo emulation is to have a slideshowdict dictionary that names and positions everything that is likely to be needed. In general, you'll want to use indirect references when and where possible, so you can add as many styles and options as you care to. Eventually building up an entire library of useful patterns and layouts. One very important slideshowdict dictionary entry is the sequence array. Which sets the order that your slides will appear in...
/sequence [ /an_introduction_to_magic_sinewaves /magic_sinewaves_are /magic_sinewave_features ........ /for_additional_help /this_has_been ] store

Slides are easily added, removed, duplicated, or rearranged by changing this array. Slides can be hidden by commenting them with a leading "%". Note that the slides can be defined in any order in your code. Only their position in this sequence array determines their output order. The actual slideshow emulator routine is amazingly simple...
/makeslideshow {setupshow sequence { save /snapxx exch store cvx exec showpage snapxx restore } forall } store

This first initializes your pattern strings and does a few other housekeeping items. It then grabs the slides one by one and executes them in order. A slide description will typically be a title and a titleproc, a body and a bodyproc, and perhaps some additional stroke graphics.
--5--

A single makeslideshow command generates the entire presentation.

A Guided Tour
The emulated slide show is around 50K long, or less than one-fifth the original. As noted, the code can be further shortened if desired. Each and every slide images nearly instantly without lengthy bitmap delays. All slides have outstanding typography and fully magnifiable superb artwork. All links work as expected and need no further prep. The final show is totally device independent and requires only a .PDF reader for the platform of interest. No GIF's are used at all, avoiding all licensing problems. Nor is any part of the PowerPoint code. Single-file sourcecode is a mere 35K long. Here's some slide-by-slide comments on features and details of note...
an_introduction_to_magic_sinewaves -- This title slide uses an ivory background

and a magenta splash, helped along with a few magenta lines. The URL link is auto generated by the sourcecode. My preference is to never underline a URL.
magic_sinewaves_are -- A typical body slide. I chose to use gray as a title color to reduce the harshness of black. Same with the bulleted entries. Bullets are a Zapf Dingbat and once set, stay the desired size. Bullets could be tinted if desired. and_limitations -- colored text is easily highlighted, but use red sparingly and

only for key points.
magic_sinewave_appearance -- This uses a real magic sinewave to exactly

generate the needed artwork. Only a few dozen bytes of code are needed. Display time is ridiculously faster than a converted .GIF bitmap. The degree symbols are faked using a superscript font and a plain old "o".
typical_unfiltered_spectrum -- Again, this uses a few bytes of Gonzo stroke graphics to create a graph. Horizontal and vertical lettering can be mixed and matched at will. PowerPoint .GIF graphs do not translate lettering very well. typical_unfiltered_spectrum_FLASH -- This adds a "key point" message on top of

an existing slide. It also shows us how we can do progressive builds. Flashing has been added to this slide by using JavaScript as detailed in the PDFFLASH.PDF of GuruGram #48.
magic_sinewave_generation -- A typical electronic schematic. This takes heavier lettering than the normal Gonzo electronic symbols. As before, the viewing time is

much faster than an converted .GIF bitmap.
two_important_magsine_types -- Two colored text entries were added to

prevent the "everything bold" from overwhelming. Note the fine kerning of the math expressions. An extra point of spread goes between the parenthesis or the slashes.
--6--

key_magsine_secret_I -- A mix of a simple stroke graphic, text, and a red

highlight.
key_magsine_secret_II -- A slightly smaller font is used for the numerals. Gonzo places no sane limits on font sizes or variations. Again, there is slight kerning on the parenthesis. fourier_pulse_properties -- The big math expressions form a graphic in

themselves. Note that a "*" is normally too small and too high to look good. So a larger and subscripted font was used for the asterisks. As usual, some subtle kerning makes for top appearance.
the_magic_equations -- This is waaay too much math detail to show in a slide.

But it is the key point of the presentation and is easily magnified. Most viewers eyes will blur over anytime they see either math or poetry. While still delivering the message "this is a key bunch of very messy math". I didn't fix the asterisks here, but easily could have done so.
equation_simplification -- Always work in a terrible and unexpected pun. quantization -- A typical slide with an auto-tracking, auto-boxing link. how_big_should_n_be -- Use exclamation points very sparingly. for_additional_help -- Combining several URL's with text. this_has_been -- Keep "penalty of death" notices small. But still obvious.

Getting Fancy
Note that Acrobat PDF has a full screen mode that lets you do fancy transitions, automated sequencing, and such. Thus, most PowerPoint features are easily emulated. Flashing is easily done using the JaveScript concepts of PDFFLASH.PDF found in GuruGram #48. For some reason, Adobe steadfastly refuses to let you run full screen .PDF from within a browser. Thus, you'll have to actually download the file before running a full screen display.

For More Help
Additional background along with related utilities and tutorials appears on our GuruGram, PostScript, Acrobat, and Fonts & Bitmaps library pages. Consulting assistance on any and all of these and related topics can be found at
http://www.tinaja.com/info01.asp. As can our presentation development

services. Additional GuruGrams await your ongoing support as a Synergetics Partner.

--7--