PostScript, The Forgotten Art of Programming
Time to do something more interesting. To draw a line, enter:
newpath 100 400 moveto 300 200 lineto 500 300 lineto stroke
This instruction starts a new path by moving to point (100, 400), drawing a line to point (300, 200), then to (500, 300) and, finally, painting the current path. Without the stroke you wouldn't see a thing. Instead of absolute positions you can also use relative movements with rmoveto and rlineto. The thickness of the lines can be controlled by the setlinewidth option, e.g., to draw a hair line:
0.01 setlinewidthFilling shapes is also easy. Replace stroke by closepath fill; the command closepath connects the last point with the first point to form the shape and fill fills the shape with the current color or grayscale. In this case we get a black triangle. If you do 0.9 setgray, the fill color will be a light gray (0 is black and 1 is white). You can also select colors with sethsbcolor or setrgbcolor, but these options are a bit more complicated. (For further information, see the Red Book in the References.)
Placing text takes some initial preparation: First select the proper font:
/Times-Roman findfont 10 scalefont setfont
selects a 10-point Times-Roman font. Other well-known fonts are Helvetica and Courier. Placing text is easy; you move to the position where you want the text, add parentheses to enclose the text and add the command show. In the case where the text contains parentheses or a backslash you must “escape” them by inserting a backslash before the character to be escaped. Sounds familiar, right? So the line:
400 400 moveto (Hello World) showprints a greeting you have seen many times before.
There is one final command that is crucial if you want to see anything rolling out of the printer: showpage. This command transfers the picture, made by the PostScript interpreter of your printer, to paper and clears the memory afterwards so that you can start a new page. The command run can be used to load your file:(file.ps) run executes the file named file.ps.
Compliant PostScript is nothing more than PostScript with some special comments and layout instructions for your PostScript program, so that other programs can read your PostScript program and perform certain operations on it. There are numerous examples of available operations: reversing the pages, scaling the pages, rotating the pages, placing two or four pages on one page, etc. Even the program Ghostview uses compliant PostScript, the title and page numbers that you see are retrieved from the PostScript comments.
Since this is all done through comments, it does not matter to your printer if the PostScript is compliantor not—the printer skips all comments. However, in a Unix environment it is common to use the output of one program as the input for another. Thus, it is quite natural not to consider a PostScript file as an end station. In a Unix environment compliant PostScript files are a must; otherwise, the print filters will not be able to process the files.
In a Microsoft environment with Microsoft's well-known word processor, PostScript is an end station. The generated output suggests that it is level-2 compliant PostScript, but, alas, it is not. There are so few rules to make your document level-1 compliant (see Red Book) or even level- 2 compliant (see DSC in the References), that you might wonder how it ever wouldn't be.
I will stick to level-1 compliant (it is a bit easier as level-2 has more overhead). In the Red Book, level-1 compliant PostScript is described in just eight pages; so if you want to know all the ins and outs, it is the right source.
There are three types of comments:
Header comments go before any PostScript code.
Body comments primarily serve to mark the boundaries of pages.
Trailer comments follow all PostScript code and are normally used to describe certain features that were not yet known from the header comments, so they were deferred (e.g., number of pages, fonts to be used and bounding box).
Normally, a comment in PostScript starts with a % (percent symbol), but these structuring comments start with %% (or %! if it is the very first line). A %% comment is directly followed by a keyword denoting its type of structuring comment, and if arguments are needed, they follow a :(colon) and are separated by spaces. As an example, let's look at the following template (the number in front of each line is just for reference):
1 %!PS-Adobe-1.0 2 %%DocumentFonts: 3 %%Title: 4 %%Creator: 5 %%CreationDate: 6 %%For: 7 %%Pages: 8 %%BoundingBox: 9 %%EndCommentsThe first line suggests that these files are going to be level-1 compliant. One common misunderstanding is that people think the 1 in 1.0 denotes the compliance level, but that is not the case. Only level-1 and level-2 compliancy exist, so even if you see %!PS-Adobe-3.2 , it is not level- 3 compliant (it should be level-2 compliant).
The second line contains the fonts to be used in this file. Some programs find it handy to know in the beginning which fonts they should load. However, when you create a program that generates PostScript, you often do not know this at this time. This header comment can be deferred to the trailer comments. In that case you will have to replace the font1 font2... part of the line in the header with (atend).
The third line is easy; text indicates the title of the document. Often this is the file name, but it does not have to be. Spaces in text are no problem. The fourth line is equally easy; here text should be replaced by the author or the application that created this file.
In the fifth line text should be a date and time humans can interpret. Line 6 is optional, and text should be replaced by the intended recipient. If absent, the intended recipient is Creator.
In line 7 number should reflect the number of pages in the document. Since this number is often not known beforehand, it is frequently deferred to the trailer comments. Again, substitute (atend) in this case.
Line 8 contains four arguments: the x and y coordinates for the lower left corner and the upper right corner. In the case of multiple pages you should use the bounding box, so that all pages lie in the bounding box. To fill in the right values, you will find Ghostview very handy. The bounding box can also be deferred to the end; again you would specify (atend).
Finally, line 9 ends the header section. Besides line 1 and 9 the order of the other lines can be chosen as you see fit.
After the header you normally see some PostScript definitions of variables and subroutines. These variables are intended to remain constant throughout the rest of the PostScript program.
Next, it is time for the body comments. The first body comment is %%EndProlog, which ends the “invariant” section of the program. Most print filters leave everything up to this line intact.
Each page is preceded by (again line numbers are only for reference purposes):
1 %%Page: 2 %%PageFonts: elm
The first line contains label and ordinal. label should be replaced by a string, containing no white space, that indicates which page it is. Sounds a bit weird, but this means that Roman numerals are okay, and if you have two pages on one, then 1,2 or 3,4 is a valid page number as well. In our case, it is just a plain number. The ordinal part indicates the value of the page number. Having two types of page numbers is just for your convenience.
The second line is optional and describes which fonts are to be used in the output. If absent, the fonts specified for DocumentFonts in the header are used.
Although it is not necessary, if you want to create just a single page, the next PostScript command is save, which makes a copy of the environment you have built so far. At the end of the page you will find the line:
This command retrieves the original situation and prints the page. It means that anything you do between save and restore is fair game, i.e., you can't screw up other pages if a filter reorders the pages.
After the final page you have %%Trailer. Most filters leave this line and everything that follows it intact. In some PostScript programs some cleaning up occurs here, but in most PostScript programs the trailer comments follow directly (again, line numbers are for reference purposes):
1 %%DocumentFonts: 2 %%Pages: 3 %%BoundingBox:
Of these three lines, only those that were deferred in the header comments should be included here in the trailer.
If you want to make your PostScript level-2 compliant, you need to read the DSC (see references).
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide