Compatibility API¶
Names and signatures matching the docxtpl distribution, so existing code
migrates by changing its import line. See
Migrating from docxtpl.
compat
¶
The docxtpl-compatible surface.
Existing code needs no change at all: this distribution installs the docxtpl
package, so the import line a project already has keeps working.
from docxtpl import DocxTemplate, RichText, InlineImage
Everything here is a thin adapter over the modern API in docxtpl.template
and docxtpl.content. The names, argument names and return types match what
docxtpl documents; the implementations are this package's own. Where the two
disagree the compatibility surface wins for these classes, because code
depending on it cannot be changed by us.
New code should use |Template|, |Text|, |Fragment|, |Image| and |Preformatted| instead. Nothing here is deprecated — the compatibility surface is supported indefinitely — but the modern names are typed more precisely and are keyword-only where an argument is easy to pass in the wrong position.
DocxTemplate
¶
Bases: Template
docxtpl.DocxTemplate, implemented over |Template|.
Source code in src/docxtpl/template.py
docx
property
¶
docxtpl.DocxTemplate.docx — the underlying python-docx document.
The same object as |Template.document|, under the name existing code
reaches for: tpl.docx.add_paragraph(…), tpl.docx.tables[0].
template_file
property
¶
docxtpl.DocxTemplate.template_file — what the template was loaded from.
allow_missing_pics
property
writable
¶
docxtpl.DocxTemplate.allow_missing_pics.
The same flag as |Template.allow_missing_replacements|, which covers media and embedded objects as well as pictures.
render
¶
render(
context: Any,
jinja_env: Optional[Environment] = None,
autoescape: bool = False,
*,
sandboxed: bool = False,
strict: bool = False,
) -> None
docxtpl.DocxTemplate.render().
sandboxed and strict are this package's additions and are
keyword-only, so the two positional arguments stay exactly docxtpl's.
See |Template.render|.
Source code in src/docxtpl/compat.py
get_undeclared_template_variables
¶
get_undeclared_template_variables(
jinja_env: Optional[Environment] = None,
context: Optional[Dict[str, Any]] = None,
) -> Set[str]
docxtpl.DocxTemplate.get_undeclared_template_variables().
With context, the answer is what the template needs and that context
does not supply — the missing variables rather than all of them.
Source code in src/docxtpl/compat.py
get_docx
¶
init_docx
¶
docxtpl.DocxTemplate.init_docx() — go back to the unrendered template.
Rendering mutates the document, so a second render() applies to the
already-rendered one. Reloading is how existing code renders the same
template against several contexts in a loop.
Source code in src/docxtpl/compat.py
render_footnotes
¶
docxtpl.DocxTemplate.render_footnotes() — the notes and nothing else.
Endnotes as well as footnotes: they are the same kind of thing, and a template with a tag in one usually has one in the other.
Source code in src/docxtpl/compat.py
render_properties
¶
docxtpl.DocxTemplate.render_properties() — the property parts.
All three of them: core, extended and custom. docxtpl renders the
first two, and a template whose custom properties held tags would have
no other way to reach them.
Source code in src/docxtpl/compat.py
new_subdoc
¶
new_subdoc(
docpath: Optional[FragmentSource] = None,
) -> Subdoc
docxtpl.DocxTemplate.new_subdoc().
docpath is a path, as docxtpl documents it, and also a stream or an
open docx.document.Document — which is what composing a document from
pieces rendered by other templates needs.
Source code in src/docxtpl/compat.py
build_url_id
¶
replace_pic
¶
replace_zipname
¶
RichText
¶
RichText(
text: str = "",
style: Optional[str] = None,
color: Optional[str] = None,
highlight: Optional[str] = None,
size: Optional[int] = None,
subscript: Optional[bool] = None,
superscript: Optional[bool] = None,
bold: bool = False,
italic: bool = False,
underline: Union[bool, str, None] = False,
strike: bool = False,
font: Optional[str] = None,
url_id: Optional[str] = None,
rtl: bool = False,
lang: Optional[str] = None,
)
Bases: Text
docxtpl.RichText, implemented over |Text|.
The formatting arguments are positional here, in the order docxtpl
declares them, because existing code passes them that way:
R().add("x", None, "ff0000"). |Text| makes the same arguments
keyword-only, which is the improvement and also the reason this override
exists.
docxtpl.RichText().
Source code in src/docxtpl/compat.py
add
¶
add(
text: str = "",
style: Optional[str] = None,
color: Optional[str] = None,
highlight: Optional[str] = None,
size: Optional[int] = None,
subscript: Optional[bool] = None,
superscript: Optional[bool] = None,
bold: bool = False,
italic: bool = False,
underline: Union[bool, str, None] = False,
strike: bool = False,
font: Optional[str] = None,
url_id: Optional[str] = None,
rtl: bool = False,
lang: Optional[str] = None,
) -> RichText
docxtpl.RichText.add(), which takes its arguments positionally.
Source code in src/docxtpl/compat.py
RichTextParagraph
¶
RichTextParagraph(
text: Union[str, RichText, None] = None,
parastyle: Optional[str] = None,
*,
align: Optional[str] = None,
spacing: Optional[int] = None,
)
docxtpl.RichTextParagraph — a paragraph with its own properties.
Compatibility-only, and deliberately so: |Fragment| covers producing a styled paragraph with the whole document API behind it, and a second way to do it in the modern surface would be a second thing to keep working.
The content of each paragraph is a string or a |RichText|; parastyle names
a paragraph style defined in the document. align and spacing are this
package's additions and are keyword-only, so that the positional arguments
stay exactly docxtpl's.
docxtpl.RichTextParagraph().
Source code in src/docxtpl/compat.py
add
¶
add(
text: Union[str, RichText],
parastyle: Optional[str] = None,
*,
align: Optional[str] = None,
spacing: Optional[int] = None,
) -> RichTextParagraph
Append a paragraph and return self, so calls chain.
Source code in src/docxtpl/compat.py
Subdoc
¶
Subdoc(
tpl: Template, docpath: Optional[FragmentSource] = None
)
Bases: Fragment
docxtpl.Subdoc, implemented over |Fragment|.
Content is added to the object itself — sd.add_paragraph("…") — as well as
through sd.document, because that is how docxtpl's own examples do it.
Anything this class does not define is looked up on the document, so the
whole python-docx-ng API is available without naming it.
docxtpl.Subdoc(tpl, docpath=None).
docpath takes everything |Fragment.from_file| does: a path, a stream,
or a document already open.
Source code in src/docxtpl/compat.py
InlineImage
¶
InlineImage(
tpl: Template,
image_descriptor: ImageSource,
width: Optional[Length] = None,
height: Optional[Length] = None,
anchor: Optional[str] = None,
)
Bases: Image
docxtpl.InlineImage, implemented over |Image|.
docxtpl.InlineImage(), whose size arguments are positional.
anchor names a bookmark to link the picture to. It is accepted for
signature compatibility and, as in the original when the name does not
resolve, has no effect on the produced markup.
Source code in src/docxtpl/compat.py
Listing
¶
Bases: Preformatted
docxtpl.Listing, implemented over |Preformatted|.