Version history improvements
diff --git a/src/manual/en_US/book.xml b/src/manual/en_US/book.xml
index 675fad2..c1124a0 100644
--- a/src/manual/en_US/book.xml
+++ b/src/manual/en_US/book.xml
@@ -30147,16 +30147,17 @@
<programlisting role="output">"fullName": null,</programlisting>
- <para>Note with this approach you don't complicate the
+ <para>Note that with this approach you don't complicate the
template anymore to avoid printing quotation marks. Of
course, <literal>?cn</literal> works on numerical and
- boolean values as well.</para>
+ boolean values as well (and of course those won't be quoted,
+ only strings).</para>
</listitem>
<listitem>
- <para><literal>c_format</literal>-s which are not merely for
- backward compatibility, the number formatting changes
- relatively to how <literal>?c</literal> did it in earlier
+ <para><literal>c_format</literal>-s other than
+ <literal>"legacy"</literal> use slightly different number
+ formatting than <literal>?c</literal> did in earlier
versions. The change affects some non-whole numbers, and
whole numbers with over 100 digits. The goal of this change
is to make the formatting lossless, and also to avoiding
@@ -30168,12 +30169,14 @@
<para>Setting the <link
linkend="pgui_config_incompatible_improvements_how_to_set"><literal>incompatible_improvements</literal>
setting</link> to 2.3.32 will change the default of
- <literal>c_format</literal> to <literal>"JavaScript or
- JSON"</literal>, which has these number formatting changes
- (just like all <literal>c_format</literal>-s that aren't
- just to emulate old behavior have). But this only affects
- number formatting done with <literal>?c</literal>,
- <literal>?cn</literal>, and with <quote>c</quote>
+ <literal>c_format</literal> for <literal>"legacy"</literal>
+ to <literal>"JavaScript or JSON"</literal>, and therefore
+ changes number formatting too.</para>
+
+ <para>Of course, all this only affects number formatting
+ done with <literal>?c</literal>, <literal>?cn</literal>, and
+ with <literal>"c"</literal> (or
+ <literal>"computer"</literal>)
<literal>number_format</literal>, and not number formatting
in general.</para>
</listitem>
@@ -30238,11 +30241,11 @@
returns a
<literal>freemarker.core.TemplateNumberFormat</literal>, and
deprecated <literal>getCNumberFormat()</literal> that returns a
- <literal>java.text.NumberFormat</literal>. The new
- <literal>?c</literal> behavior (see earlier) is only reflected
- by the new method, and what the deprecated methods returns is
- stuck at 2.3.31 <literal>incompatible_improvements</literal>
- mode.</para>
+ <literal>java.text.NumberFormat</literal>. The behavior defined
+ in the <literal>CFormat</literal> (see earlier) is only
+ reflected exactly by the return value of the new method. The
+ deprecated method returns a format that's a best effort
+ approximation.</para>
</listitem>
<listitem>
@@ -30259,6 +30262,15 @@
</listitem>
<listitem>
+ <para>Fixed performance bug with XML processing
+ (<literal>freemarker.ext.dom</literal>) when converting an XML
+ element that contains lots of text nodes (instead of a single
+ big text node) to a string. (<link
+ xlink:href="https://github.com/apache/freemarker/pull/82">GitHub
+ PR 82</link>)</para>
+ </listitem>
+
+ <listitem>
<para>Improved <literal>StringUtil.jsStringEnc</literal> and
<literal>javaSctringEnc</literal> to support quoting. Also
<literal>jsStringEnc</literal> now have a mode that targets both
@@ -30270,7 +30282,7 @@
<para><link
xlink:href="https://issues.apache.org/jira/browse/FREEMARKER-198">FREEMARKER-198</link>:
Fixed possible deadlock when the
- <literal>Configuration</literal> and
+ <literal>Configuration</literal>, and
<literal>DefaultObjectWrapper</literal> class
<emphasis>static</emphasis> initialization is triggered in
different threads around the same time. (In the very unlikely
@@ -30285,9 +30297,9 @@
xlink:href="https://issues.apache.org/jira/browse/FREEMARKER-190">FREEMARKER-190</link>:
Updated dom4j version used during FreeMarker project compilation
from 1.3 to 2.1.3. Users can still use FreeMarker with dom4j 1.3
- (mostly just luck, but it works), also anyway almost nobody uses
- FreeMarker's dom4j support (which is long deprecated). We were
- forced to do this change because old dom4j versions have
+ (mostly just luck, but it works). FreeMarker's dom4j support is
+ long deprecated anyway, and almost nobody uses it anyway. We
+ were forced to do this change because old dom4j versions have
security vulnerabilities, and although FreeMarker is not
affected by them (like we do not pull in dom4j as dependency
into the projects of our users), we were flagged as vulnerable
@@ -30295,15 +30307,6 @@
</listitem>
<listitem>
- <para>Fixed performance bug with XML processing
- (<literal>freemarker.ext.dom</literal>) when converting an XML
- element that contains lots of text nodes (instead of a single
- big text node) to a string. (<link
- xlink:href="https://github.com/apache/freemarker/pull/82">GitHub
- PR 82</link>)</para>
- </listitem>
-
- <listitem>
<para>Slightly improved
<literal>DefaultMemberAccessPolicy-rules</literal> (used by
default), and <literal>unsafeMethods.properties</literal> (long
