Documentation of bugs etc.

1 files changed, 76 insertions, 24 deletions

diff --git a/doc/dw-line-breaking.doc b/doc/dw-line-breaking.doc
index 12e89829..8e520c62 100644
--- a/doc/dw-line-breaking.doc
+++ b/doc/dw-line-breaking.doc
@@ -167,10 +167,11 @@ word \f$i\f$.
 \f$h_i\f$ is the width of the hyphen, if the word \f$i\f$ is a part of
 the hyphenated word (except the last part); otherwise 0.
 
-Let \f$l\f$ be the (ideal) width (length) of the line. Furthermore,
-all words from \f$a\f$ to \f$b\f$ are added to the line. \f$a\f$ is
-fixed: we do not modify the previous lines anymore; but our task is to
-find a suitable \f$b\f$.
+Let \f$l\f$ be the (ideal) width (length) of the line, which is
+e. at the top given by the browser window width. Furthermore, all words
+from \f$a\f$ to \f$b\f$ are added to the line. \f$a\f$ is fixed: we do
+not modify the previous lines anymore; but our task is to find a
+suitable \f$b\f$.
 
 We define:
 
@@ -333,17 +334,16 @@ be easily extended.
 
 <h3>High Priority</h3>
 
-<ul>
-<li>There seem to be problems when breaking words containing hyphens
-already. Example: "Abtei-Stadt", which is divided into "Abtei-" and
-"Stadt", resulting possibly in "Abtei--[new line]Stadt". See also
-below under "Low Priority", on how to deal with hyphens and dashes.</li>
-</ul>
+<b>Bugs in hyphenation:</b> There seem to be problems when breaking
+words containing hyphens already. Example: "Abtei-Stadt", which is
+divided into "Abtei-" and "Stadt", resulting possibly in
+&quot;Abtei-<span></span>-[new line]Stadt&quot;. See also below under
+"Low Priority", on how to deal with hyphens and dashes.
 
 <h3>Medium Priority</h3>
 
-<ul>
-<li>Break hyphens and dashes. The following rules seem to be relevant:
+<b>Break hyphens and dashes:</b> The following rules seem to be relevant:
+
 <ol>
 <li>In English, an em-dash is used with no spaces around. Breaking
 before and after the dash should be possible, perhaps with a penalty >
@@ -353,21 +353,73 @@ instead.)</li>
 be possible. As described above ("Abtei-Stadt"), this collides with
 hyphenation.</li>
 </ol>
+
 Where to implement? In the same dynamic, lazy way like hyphenation? As
-part of hyphenation?</li>
-</ul>
+part of hyphenation?
+
+<b>Incorrect calculation of extremes:</b> The minimal width of a text
+block (as part of the width extremes, which are mainly used for
+tables) is defined by everything between two possible breaks. A
+possible break may also be a hyphenation point; however, hyphenation
+points are calculated in a lazy way, when the lines are broken, and
+not when extremes are calculated. So, it is a matter of chance whether
+the calculation of the minimal width will take the two parts "dil-"
+and "lo" into account (when "dillo" has already been hyphenated), or
+only one part, "dillo" (when "dillo" has not yet been hyphenated),
+resulting possibly in a different value for the minimal width.
+
+Possible strategies to deal with this problem:
+
+<ol>
+<li>Ignore. The implications should be minimal.
+<li>Any solution will make it neccessary to hyphenate at least some
+words when calculating extremes. Since the minimal widths of all words
+are used to calculate the minimal width of the text block, the
+simplest approach will hyphenate all words. This would, of course,
+eliminate the performace gains of the current lazy approach.
+<li>The latter approach could be optimized in some ways. Examples: (i)
+If a word is already narrower than the current accumulated value for
+the minimal width, it makes no sense to hyphenate it. (ii) In other
+cases, heuristics may be used to estimate the number of syllables, the
+width of the widest of them etc.
+</ol>
 
 <h3>Low Priority</h3>
 
-<ul>
-<li>Should dw::core::Content::BREAK still be used? Currently, this is
-    redundant to dw::Textblock::BadnessAndPenalty.</li>
-<li>The calculation of badness is designed for justified text. For
-    other alignments, it may be modified. (TODO: document this in
-    detail.)</li>
-<li>It should be simple to assign a larger penalty for hyphens, when
-    the line before is already hyphenated. This way, hyphens in
-    adjacent are pelalized further.</li>
-</ul>
+<b>Mark the end of a paragraph:</b> Should dw::core::Content::BREAK
+still be used? Currently, this is redundant to
+dw::Textblock::BadnessAndPenalty.
+
+<b>Other than justified text:</b> The calculation of badness is
+designed for justified text. For other alignments, it may be
+modified. The point is the definition of strechibility and for the
+line.
+
+Consider left-aligned text. Most importantly, not the spaces between
+the words, but the space on the right border is adjusted. If the
+actual line width (sum of words and normal spaces, \f$W_a^b\f$ above)
+equals the the ideal width (e.&nbsp;g. given by the browser window
+width, \f$l\f$ above), this space is zero, so it is not possible to
+shrink it further. For this reason, the shrinkability is now already
+set to 0.
+
+On the other hand, there should be a strechability for the space on
+the right border. However, only the spaces between the words have a
+strechability; later, the differences are summed up and used to fill
+the space on the right. This works, but is a bit unprecise, since the
+strechability of the space on the right depends on the number of words
+in the line.
+
+(Likewise, if you modify the code to assign a positive value for the
+shrinkability for left-aligned text, the difference is summed up and
+used for the right border; since this difference is negative, the
+lines will, when spaces are shrunken, get too long!)
+
+Analogue considerations must be made vor right-aligned and centered
+text. (For centered texts, there are two adjustable spaces.)
+
+<b>Hyphens in adjacent lines:</b> It should be simple to assign a
+larger penalty for hyphens, when the line before is already
+hyphenated. This way, hyphens in adjacent are penalized further.
 
 */