[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Quikscript review

From: Peter Samuel
Subject: Quikscript review
Date: Tue, 8 Nov 1994 17:46:08 +1100 (AEST)

Recently, yet another document formatting package was announced:

    Newsgroups: comp.lang.postscript,comp.text
    Subject: New release of Quikscript
    Sender: address@hidden (Graham Freeman)
    Organization: Australian Defence Force Academy
    Date: Mon, 31 Oct 94 13:39:10 AEST

As I'm only an occasional user of lout - increasing the frequency all
the time - I thought I'd have a look at Quikscript and post a brief
review. If you'd like to have a look yourself, it is available at:

    ftp://ftp.adfa.oz.au/pub/postscript/Quikscript.tar.Z        118k

there is also a README in

    ftp://ftp.adfa.oz.au/pub/postscript/QsREADME        1k

all the files in the Qs distribution are available individually from


(What is it with us Australians - always trying to invent a better
document formatting system :)

"This is a quick review of the Quikscript (Qs) document formatting system.
It is based upon reading the users guide - NOT on actual use of the
system. These are also my opinions and may not represent all the facts.

In no particular order:

- Quikscript is completely portable. It is completely operating system
  independent. All that is required is an editor and a PostScript
  interpreter of some form, eg a printer or ghostscript.

- Document formatting is performed by the PostScript interpreter.
  Depending on the speed of the interpreter this may or may not be a
  benefit in terms of speed. By speed I mean the time taken to go from
  raw input to printed/viewed page.

  Each document is prepended with the Qs PostScript dictionary which
  does all the hard work. Depending on your PostScript interpreter, it
  should be possible to have the Qs dictionary remain resident in the
  printer from job to job.

  Because processing is done by the PostScript interpreter, error
  checking may be difficult without feedback from the PostScript
  interpreter. Use of ghostscript/ghostview or similar may go most of
  the way to solving this problem.

- Qs keywords are %x% based where x is the keyword. Users of SCCS will
  encounter clashes where Qs keywords will be replaced by invalid
  stings by SCCS or SCCS keywords will be incorrectly interpreted as Qs
  keywords. On further reading the % character can be changed to some
  other character quite easily.

- There is no provision for including comments - like /* */ in C and #
  in sh, awk, perl, lout etc. Comments are unavailable even if you
  change the escape character to something other than %.

- Syntax is very troff like in that commands must be turned off as well
  as turned on. Eg to enter italics you use:

      %IT%words in italics%RO%

  where %IT% is the keyword for italics and %RO% is the keyword for
  roman. This is similar to the troff notation:

      \f2words in italics\fP
    but entirely different to lout's "object" mechanism:

        @I {words in italics}

- Keywords can be changed to something else merely by editing the Qs
  dictionary file.

- Tables are created by relative positioning from the left margin.
  This may create problems if font sizes are changed at a later date.

- Equation setting is not as easy as eqn or eq. It relies on
  specifically changing fonts and performing explicit positioning. It
  is also harder to read at a glance. For example compare:

      %IT%%FN,Sym%S%FN%%W,1%%^%8%T,?1%%V%i=1%=%( Max(0, Slope%V%i%^%p%=%) )%RO%

  with the same equation in lout

      @Eq { sum from i=0 to 8 (Max(0, Slope supp p on i )) }

- Pure PostScript can be embedded simply. This allows for Qs to be
  modified from within the document itself. This mechanism is perhaps a
  little easier than lout's packages - tab, fig, report etc - in that
  all document configuration options are available to be changed all
  the time. Simple "packages" are supplied to:

      altpagnm.qs       alternate side page numbering format
      border.qs         put a border around the page
      cntpagnm.qs       centre page numbers
      dijkstra.qs       dijkstra font - simulates hand writing
      draft.qs          stamp "Draft" on each page
      europfnt.qs       european font encoding
      outlinft.qs       outline font
      pagrange.qs       print pages in a selected range
      rotate.qs         rotate pages
      smallcap.qs       small capitals

  These are simply sent to the printer with the document. eg:

      lpr Qs draft.qs document.qs

  User must be familiar with PostScript to create new "packages" and
  PostScript is definitely less intuitive than lout or even troff.

- Graphics are performed using the embedded PostScript features
  mentioned above. All graphics work - including EPS - is performed in

- There is no functionality to draw graphs - other than to include an
  EPS graph from some other source.

- A comprehensive list of all the operators is provided. Nice feature.

- 2 column or 3 column output is available but the Qs package files
  seem to have been omitted from the distribution. These can be
  obtained from the qsdir directory mentioned above.

    ftp://ftp.adfa.oz.au/pub/postscript/qsdir/2colleaf.qs       1k
    ftp://ftp.adfa.oz.au/pub/postscript/qsdir/3col.qs           1k

- 3 C program utilities are provided with the distribution.

      catex - like cat except it does %include expansion as well as
              inline macro expansion

      catm - like catex but with a mail merge like feature that will
              output the same file many times, performing substitutions
              based on a list file

      notab - replace tabs with spaces while preserving appearance

  There are no manual pages for the programs but the Qs user manual
  describes their use in detail.

- Page numbering is automatic.

- Because Qs is written entirely in PostScript it is possible to change
  its functionality very quickly. Some of the more esoteric areas will
  require considerable PostScript knowledge - others will require none
  at all.

  One possibility that just came to mind was to change the keywords to
  look like HTML commands so that one document can perform two
  functions. This will probably only work for simple documents.

- There is no cross referencing functionality. Tables of contents, page
  number referencing and bibliographies must be hand coded and recoded
  as the document changes. It would be difficult if not impossible to
  do multiple passes of the document through a PostScript interpreter
  so I would imagine that this functionality will never exist in Qs.

- Because the input documents *are* PostScript, Adobe DSC comments such as

      %%Page x y

  are not provided automatically.

- There is no concept of sections or subsections, and hence no
  automatic numbering of same.

While Qs does not have all the rich features of troff, lout or TeX, it
does represent (to me anyway) a new approach to document formatting, ie
allow the printing engine to perform the formatting rather than
providing preformatted instructions to the printer.

This approach makes Qs completely operating system independent and
requires no compilation at all.

For user's unfamiliar with any of the current crop of established
document formatting systems (troff, TeX, lout) Qs will go most of the
way to serve those user's needs. I can see that it could be useful for
documents ranging from simple to medium complexity. However I don't see
it as a serious challenger to troff, TeX or even lout for more complex

I've Cced this post to both Jeff Kingston and Graham Freeman and invite
their comments and/or corrections.

Peter Samuel                                address@hidden
Technical Consultant                        or at present:
Uniq Professional Services                  address@hidden
Phone: +61 2 339 3843                       Fax: +61 2 339 3688

reply via email to

[Prev in Thread] Current Thread [Next in Thread]