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 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271
|
============================
Hyperkitty's Email Rendering
============================
Hyperkitty supports rich text rendering of Emails. Due to the fact the most
people writing emails aren't *always* aware that they are writing markdown, a
prime philosophy of renderer is to prevent common plain-text to be mangled by
rendering them as markdown.
Hyperkitty currently recognizes some rules that are used to parse the content of
an email and render them as HTML with some CSS styling applied.
Enabling Markdown Rendering
===========================
In Postorius UI, under :guilabel:`Setttings` -> :guilabel:`Archiving` ->
:guilabel:`Archive Rendering Mode`, MailingList owners can choose between
``Plain Text`` and ``Markdown text``.
Hyperkitty will use that to choose between the simple text renderer and
markdown renderer.
Text Renderer
=============
Text renderer is the default renderer for the Emails since the default value of
``archive_rendering_mode`` setting for MailingLists is ``text``. Text renderer
supports the following rules only:
* :ref:`signature-rule`
* :ref:`pgp-signature-rule`
* :ref:`autolink-rule`
* :ref:`quote-rule`
Markdown Renderer
=================
Markdown renderer support all the rendering rules mentioned in the
:ref:`rendering-rules` section below.
.. versionadded:: 1.3.4
.. _rendering-rules:
Rendering Rules
===============
Rules are essentially markup that are given special meaning such that they
affect how the rendered text looks. Apart from well known Markdown rules
(which are documented later in this page), there are some other rules that is
supported by Hyperkitty's renderer that make sense in the context of an Email.
.. _signature-rule:
Signature Rule
--------------
Email signatures are often delimited by ``--<SPACE>\n``. That is recognized as
the boundary of the email and
:py:func:`hyperkitty.lib.renderer.plugin_signature` parses that to produce a
greyed out signature at the bottom of the email. An **empty space** after two
dashes ``--`` is important and used as a standard email signature delimiter.
For example, something like::
--
Thanks,
My Name
http://example.com
.. _pgp-signature-rule:
PGP Signature Rule
------------------
PGP signature rule recognizes inline PGP signatures that looks like this::
----BEGIN PGP SIGNED MESSAGE-----
This is the text.
-----BEGIN PGP SIGNATURE-----
iQEXYZXYZ
-----END PGP SIGNATURE-----
It is parsed and collapsed into a paragraph with a quote switch (``...PGP
SIGNATURE...``) to expand the collapsed signature.
.. _autolink-rule:
Autolink Rule
-------------
This recognizes the URLs in the text which may or may not be included in angle
brackets (``<http://example.com>``) and converts them to Hyperlinks. It will
also truncate the text to 76 characters with following ``...`` characters if
the length of the URL is longer than 76 characters.
This rule will also convert Email addresses into ``mailto:aperson@example.com``
URLs. It does not verify the validity of the Email address or even if the email
address is a valid email address. The parsing is naive in many ways.
.. _quote-rule:
Quote Rule
----------
Or, Blockquote rule. This rule recognizes the lines starting with one or more
``>`` and converts them to blockquotes. They are also collapsed with a switch
(``...``) for expanding and collapsing each section. Hyperkitty currently will
parse upto 6 levels of nested quotes.
A different color styling is provided for each level of blockquote to make it
easy to differentiate between a user's reply and the previous user's reply and
so on and so forth.
For example, each level is indicated with a ``>``::
> This is level 1 quote
> > This is Level 2 quote
> > > This level 3 quote.
Each of them are collapsed with their own quote switch (``...``) to expand or
collapse them.
The rendering of the blockquote can often times be found to be buggy, where
text from a higher level quoting will appear under lower level quote when there
are sentence breaks. Like for example::
> > > This line of sentence will be broken unintentionally
> > into the lower
> > > level because of the improper folding of the email text
> > by
> > > some of the email clients.
This type of text will appear with a mixed level of quoting and can often times
be very hard to read. This is caused by email client adding hard line breaks in
the sentences when replying which makes it impossible to differentiate between
the level of quote.
Hyperkitty's current parser is unable to deal with these embarrassing quote
wraps and will unfortunately present the text as mixed levels of quotes. As the
current parser evolves, it *might* be possible to provide a better rendering
experience for this with some heuristics.
Image Rule
----------
Remote image support for Hyperkitty is optional and disabled by default due to
the fact that they can often be used to track users. Hyperkitty also doesn't
have support to upload attachments when replying from web interface, which
makes it hard to support inline images.
To enable the support for images, administrators can add
``HYPERKITTY_RENDER_INLINE_IMAGE = True`` to Hyperkitty's ``settings.py``.
The default value of above setting is ``False`` and all Markdown image syntax
is just ignored. If the above setting is set to True, the images are rendered
inline with the text.
::

Lists
-----
::
* List Items
* List Item 2
* List Item 3
* List Item 4
- List Item
- List Item 2
Bold
----
::
**Bold Text**
Italics
-------
::
*Italics*
Horizontal Rule
---------------
::
---
***
Code
----
::
`inline code for text`
```
Multi-line code segment
```
Code can also be indented by 4 spaces without any backticks.
Hyperlink
---------
::
[Text](https://url)
[Text][1]
[1]: https://URL
Footnotes
---------
::
This text has a footnote reference[^note]
[^note]: Foonotes for testing.
Headers
-------
Markdown headers using ``##`` syntax or using ``==`` or ``--`` are not
supported in Hyperkitty. This is because these characters are very often used
in different context and results in untentional ``<h1>`` and ``<h2>`` tags in
the rendered output.
Extending Hyperkitty Renderer
=============================
Hyperkitty uses the `mistune <https://pypi.org/project/mistune/>`_ library as
the renderer but customizes the rendering rules to tailor the rendering
behavior to its liking. Many of the above mentioned rules are implemented as
mistune plugins using their standard plugin interface.
As it has been mentioned in the first paragraph of this page, the default set
of rules that are enabled in Hyperkitty is going to be limited by what can be
assumed in a unstructured plain text email.
But, new rendering rules that conform the above design can be added or
contributed to Hyperkitty. It is possible to also extend the renderer to
support optional rules that can be enabled by site administrators if they
choose to do so. These rules would have to be `mistune plugins
<https://mistune.readthedocs.io/en/latest/plugins.html>`_ and need to be either
a 3rd party package or contributed to Hyperkitty.
|