From 71bdb35d52747e6d7d9f55df4524d57c2966be94 Mon Sep 17 00:00:00 2001 From: "Jeffrey H. Kingston" Date: Tue, 14 Sep 2010 19:21:41 +0000 Subject: Lout 3.17. git-svn-id: http://svn.savannah.nongnu.org/svn/lout/trunk@2 9365b830-b601-4143-9ba8-b4a8e2c3339c --- doc/expert/pre_bend | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 doc/expert/pre_bend (limited to 'doc/expert/pre_bend') diff --git a/doc/expert/pre_bend b/doc/expert/pre_bend new file mode 100644 index 0000000..8f742a9 --- /dev/null +++ b/doc/expert/pre_bend @@ -0,0 +1,61 @@ +@Section + @Tag { backend } + @Title { "@BackEnd" and the PlainText and PDF back ends } +@Begin +@PP +backend.sym @Index { @@BackEnd symbol } +The @@BackEnd symbol, which takes no parameters, has for its result a +string naming the back end currently in use. Three back ends are available, +PostScript, PDF and PlainText. The symbol is generally used like this: +@ID @Code { +"@BackEnd @Case {" +" PlainText @Yield { ... }" +" PostScript @Yield { ... }" +" PDF @Yield { ... }" +"}" +} +to obtain different objects depending on the back end. No @Code else +is required since these are the only possible values. +@PP +When a @Code "@Case" symbol has @Code "@BackEnd" for its left parameter +and the left parameter of each @Code "@Yield" symbol within it consists +of a sequence of one or more literal words (including {@Code else}), Lout +will optimize by evaluating the @Code "@Case" symbol at the time it is +read. This optimization ensures that there is only a small once-only +performance penalty for multiple back ends, and it permits these +@Code "@Case" symbols (but no other symbols) to appear within the object +following @Code "@Include" and @Code "@PrependGraphic" symbols. +@PP +The PlainText back end differs from the PostScript one in two main +respects. First, there is effectively just one font: although all +the font commands work exactly as usual, they don't actually change +anything. Each character in this font is taken to be one tenth +of one inch wide and 20 points high. Second, the output is an +ordinary text file, not a PostScript file. +@PP +Clearly, with ordinary text output the possibility of advanced graphics +features such as rotation and scaling is curtailed. Nevertheless, all +symbols have well-defined (possibly null) effects in the PlainText +back end, so there is no additional danger of crashing the system or +obtaining grossly unreasonable output by a change to PlainText. +@PP +The PlainText back end is obtained by the @Code "-p" option to Basser +Lout. The character size can be changed by adding two lengths to +the @Code "-p" option, like this: +@ID @Code "lout -p0.1i12p ..." +which invokes the PlainText back end with each character being 0.1 +inches wide and 12 points high. However, experience suggests that +the best approach is to define all horizontal lengths as multiples of +the @Code "s" unit (the width of a space, hence the width of all +characters) and to define all vertical lengths as multiples of the +@Code "f" unit (the font size, equal to the height of every character), +and not to change the character size in the command line. +@PP +There is a @Code "-P" option which is identical with the @Code "-p" +option except that it inserts a form-feed character between each two +components of the output, but not before the first or after the last. +@PP +The PDF back end is obtained by typing {@Code "lout -Z"}. It is similar +to PostScript but much more limited in functionality. Consult a separate +document distributed with Lout for further information. +@End @Section -- cgit