File: renderer-api.tex

package info (click to toggle)
plastex 3.1-4
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 6,132 kB
  • sloc: python: 23,341; xml: 18,076; javascript: 7,755; ansic: 46; makefile: 40; sh: 26
file content (256 lines) | stat: -rw-r--r-- 11,211 bytes parent folder | download | duplicates (2)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256

\section{\module{plasTeX.Renderers} --- The \plasTeX\ Rendering Framework}

\declaremodule{standard}{plasTeX.Renderers}
\modulesynopsis{The \plasTeX\ rendering framework}


The renderer is responsible for taking the information in a \plasTeX\
document object and creating a another (usually visual) representation of it.  
This representation may be HTML, XML, RTF, etc.  While this could be
implemented in various ways.  One rendering framework is included with
\plasTeX.

The renderer is essentially just a dictionary of functions\footnote{
``functions'' is being used loosely here.  Actually, any Python callable
object (i.e. function, method, or any object with the \method{__call__}
method implemented) can be used}.  The
keys in this dictionary correspond to names of the nodes in the document
object.  The values are the functions that are called when a
node in the document object needs to be rendered.  The only argument
to the function is the node itself.  What this function
does in the rendering process is completely up to it; however, it should
refrain from changing the document object itself as other renderers 
may be using that same object.

There are some responsibilities that all renderers share.  Renderers
are responsible for checking options in the configuration object.
For instance, renderers are responsible for generating filenames, 
creating directories, writing files in the proper encoding, generating
images, splitting the document into multiple output files, etc.
Of course, how it accomplishes this is really renderer dependent.
An example of a renderer based on Zope Page Templates (ZPT) is included
with \plasTeX.  This renderer is capable of generating XML and HTML
output.


\subsection{Renderer Objects}

\begin{classdesc}{Renderer}{}
Base class for all renderers.  \class{Renderer} is a dictionary and
contains functions that are called for each node in the \plasTeX\
document object.  The keys in the dictionary correspond to the names of
the nodes.
\end{classdesc}

This renderer implementation uses a mixin called \class{Renderable} that
is mixed into the \class{Node} class prior to rendering.  \class{Renderable}
adds various methods to the \class{Node} namespace to assist in the
rendering process.  The primary inclusion is the \method{\_\_str\_\_()}
method.  This method returns a string representation of the current node
and all of its child nodes.  For more information, see the \class{Renderable}
class documentation.

\begin{memberdesc}[Renderer]{default}
the default renderer value.  If a node is being rendered and no key in
the renderer matches the name of the node being rendered, this 
function is used instead.
\end{memberdesc}

\begin{memberdesc}[Renderer]{fileExtension}
contains the file extension to use for generated files.  This extension is
only used if the filename generator does not supply a file extension.
\end{memberdesc}

\begin{memberdesc}[Renderer]{files}
a list of files created during rendering.
\end{memberdesc}

\begin{memberdesc}[Renderer]{imageAttrs}
contains a string template that renders the placeholder for the image 
attributes: width, height, and depth.  This placeholder is inserted into
the document where the width, height, and depth of an image is needed.
The placeholder is needed because images are not generated until after
the document is rendered.  See the \class{Imager} API 
(section \ref{sec:imager-api}) for more information.
\end{memberdesc}

\begin{memberdesc}[Renderer]{imageUnits}
contains a string template that renders the placeholder for the image 
attribute units.  This placeholder is inserted in the document any time
an attribute of a particular unit is requested.  This placeholder will
always occur immediately after the string generated by \member{imageAttrs}.
The placeholder is needed because images are not generated until after
the document is rendered.  See the \class{Imager} API 
(section \ref{sec:imager-api}) for more information.
\end{memberdesc}

\begin{memberdesc}[Renderer]{imager}
a reference to an \class{Imager} implementation.  Imagers are responsible
for generating images from \LaTeX\ code.  This is needed for output types 
which aren't capable of displaying equations, \LaTeX\ pictures, etc. such
as HTML.
\end{memberdesc}

\begin{memberdesc}[Renderer]{vectorBitmap}
a boolean indicating whether bitmap versions should be generated for vector
images. The bitmap version is used to read off the height, width and depth of
the image. If such information is not used by the renderer, we can skip
producing the bitmap, which may take a long time.

This defaults to \code{True}.
\end{memberdesc}

\begin{memberdesc}[Renderer]{imageTypes}
contains a list of file extensions of valid image types for the renderer.
The first element in the list is the default image format.  This format
is used when generating images (if the image type isn't specified by
the filename generater).  When static images are simply copied from
the document, their format is checked against the list of supported image
types.  If the static image is not in the correct format it is converted
to the default image format.  Below is an example of a list of image
types used in the HTML renderer.  These image types are valid because 
web browsers all support these formats.
\begin{verbatim}
imageTypes = ['.png','.gif','.jpg','.jpeg']
\end{verbatim}
\end{memberdesc}

\begin{memberdesc}[Renderer]{vectorImageTypes}
contains a list of file extensions of valid vector image types for the
renderer.  The first element in the list is the default vector image 
format.  This format is used when generating images.  Static images
are simply copied into the output document directory.  Below is an
example of a list of image types used in the HTML renderer.  These
image types are valid because there are plug-ins available for these
formats.
\begin{verbatim}
vectorImageTypes = ['.svg']
\end{verbatim}
\end{memberdesc}

\begin{memberdesc}[Renderer]{newFilename}
filename generator.  This method generates a basename based on the options
in the configuration.  

The generator has an attribute called \member{namespace} which contains the
namespace used to resolve the variables in the filename string.  This
namespace should be populated prior to invoking the generator.  After
a successful filename is generated, the namespace is automatically cleared
(with the exception of the variables sent in the namespace when the 
generator was instantiated).

\note{This generator can be accessed in the usual generator fashion, or
called like a function.}
\end{memberdesc}

\begin{memberdesc}[Renderer]{outputType}
a function that converts the content returned from each rendered
node to the appropriate value.
\end{memberdesc}

\begin{memberdesc}[Renderer]{textDefault}
the default renderer to use for text nodes.
\end{memberdesc}


\begin{methoddesc}[Renderer]{cleanup}{document, files\optional{, postProcess}}
this method is called once the entire rendering process is finished.  
Subclasses can use this method to run any post-rendering cleanup tasks.
The first argument, \var{document}, is the document instance that is
being rendered.  The second argument, \var{files}, is a list of all of the
filenames that were created.

This method opens each file, reads the content, and 
calls \method{processFileContent} on the file content.  It is suggested
that renderers override that method instead of \method{cleanup}.

In addition to overriding \method{processFileContent}, you can post-process
file content without having to subclass a renderer by using the 
\var{postProcess} argument.  See the \method{render} method for more information.
\end{methoddesc}

\begin{methoddesc}[Renderer]{find}{keys\optional{, default}}
locate a rendering method from a list of possibilities.  

\var{keys} is a list of strings containing the requested name of a
rendering method.  This list is traversed in order.  The first renderer
that is found is returned.

\var{default} is a default rendering method to return if none of the keys
exists in the renderer.
\end{methoddesc}

\begin{methoddesc}[Renderer]{initialize}{}
this routine is called after the renderer is instantiated.  It can be used
by subclasses to do any initialization routines before the rendering process.
\end{methoddesc}

\begin{methoddesc}[Renderer]{processFileContent}{document, content}
post-processing routine that allows renders to modify the output documents
one last time before the rendering process is finished.  \var{document}
is the input document instance.  \var{content} is the content of the 
file in a string object.  The value returned from this method will be
written to the output file in the appropriate encoding.
\end{methoddesc}

\begin{methoddesc}[Renderer]{render}{document\optional{, postProcess}}
invokes the rendering process on \var{document}.  You can post-process each
file after it is rendered by passing a function into the \var{postProcess}
argument.  This function must take two arguments: 1) the document object and
2) the content of a file as a string object.  It should do whatever 
processing it needs to the file content and return a string object.
\end{methoddesc}


\subsection{Renderable MixIn}

\begin{classdesc}{Renderable}{}
The \class{Renderable} mixin is mixed into the \class{Node} namespace
prior to the rendering process.  The methods mixed in assist in the 
rendering process.
\end{classdesc}

\begin{memberdesc}[Renderable]{filename}
the filename that this object will create.  Objects that don't create 
new files should simply return \var{None}.   The configuration determines
which nodes should create new files. 
\end{memberdesc}

\begin{memberdesc}[Renderable]{image}
generate an image of the object and return the image filename.  See
the \class{Imager} documentation in section \ref{sec:imager-api} for
more information.
\end{memberdesc}

\begin{memberdesc}[Renderable]{vectorImage}
generate a vector image of the object and return the image filename.  See
the \class{Imager} documentation in section \ref{sec:imager-api} for
more information.
\end{memberdesc}

\begin{memberdesc}[Renderable]{url}
return the relative URL of the object.  

If the object actually creates a file, just the filename will
be returned (e.g. \file{foo.html}).  If the object is within a file, 
both the filename and the anchor will be returned 
(e.g. \file{foo.html\#bar}).
\end{memberdesc}

\begin{methoddesc}[Renderable]{__str__}{}
invoke the rendering process on all of the child nodes.  The rendering process
includes walking through the child nodes, looking up the appropriate 
rendering method from the renderer, and calling the method with the child
node as its argument.

In addition to the actual rendering process, this method also prints out 
some status information about the rendering process.  For example, if 
the node being rendered has a non-empty \member{filename} attribute, that
means that the node is generating a new file.  This filename information
is printed to the log.  One problem with this methodology is that the 
filename is not actually created at this time.  It is assumed that the
rendering method will check for the \member{filename} attribute and actually
create the file.
\end{methoddesc}