From 6cd133d2f242d36bd48ddea44acd868f70782d0b Mon Sep 17 00:00:00 2001
From: Gevel Tekens <geveltekens@gmail.com>
Date: Tue, 4 Feb 2025 23:13:27 +0100
Subject: Fix several typos

See: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman3.com/thread/L3FFAINJJMIOZQNID5HC2DHKJIIIHEYH/
---
 devdoc/Dillo.txt                     |  2 +-
 devdoc/Images.txt                    |  2 +-
 devdoc/dw-changes.doc                |  2 +-
 devdoc/dw-fixed-positions.doc        |  4 ++--
 devdoc/dw-images-and-backgrounds.doc |  4 ++--
 devdoc/dw-interrupted-drawing.doc    |  2 +-
 devdoc/dw-layout-views.doc           |  2 +-
 devdoc/dw-layout-widgets.doc         |  2 +-
 devdoc/dw-line-breaking.doc          | 10 +++++-----
 devdoc/dw-miscellaneous.doc          |  4 ++--
 devdoc/dw-out-of-flow-floats.doc     |  6 +++---
 devdoc/dw-out-of-flow.doc            |  2 +-
 devdoc/dw-size-request-pos.doc       |  2 +-
 devdoc/dw-stacking-context.doc       |  2 +-
 devdoc/dw-usage.doc                  |  6 +++---
 devdoc/dw-widget-sizes.doc           |  2 +-
 devdoc/lout.doc                      |  2 +-
 devdoc/rounding-errors.doc           |  2 +-
 devdoc/uml-legend.doc                |  4 ++--
 19 files changed, 31 insertions(+), 31 deletions(-)

(limited to 'devdoc')

diff --git a/devdoc/Dillo.txt b/devdoc/Dillo.txt
index e7f18de7..99e940be 100644
--- a/devdoc/Dillo.txt
+++ b/devdoc/Dillo.txt
@@ -84,7 +84,7 @@ upon HTTP header arrival.
 
    Well,  the  html  parser  gets  fed,  and proper functions are
 called  for  each tag (to parse and call the appropriate methods)
-and the whole page is contructed in a streamed way.
+and the whole page is constructed in a streamed way.
    Somewhere  in  the  middle of it, resize and repaint functions
 are  activated  and  idle  functions draw to screen what has been
 processed.
diff --git a/devdoc/Images.txt b/devdoc/Images.txt
index 62082e48..0f56ec4c 100644
--- a/devdoc/Images.txt
+++ b/devdoc/Images.txt
@@ -15,7 +15,7 @@ handles it by:
      associated widget (DwImage).
      i.e. If 'Image' is the var for the structure, then
           'Image->dw' is the widget.
-   - Requesting the image to be feeded by the cache.
+   - Requesting the image to be fed by the cache.
    - Sending some info to the browser interface.
 
 * The  cache  can  either request the image data from the net, or
diff --git a/devdoc/dw-changes.doc b/devdoc/dw-changes.doc
index 7050df9a..0210cf79 100644
--- a/devdoc/dw-changes.doc
+++ b/devdoc/dw-changes.doc
@@ -51,7 +51,7 @@ Related to the FLTK port, there have been many changes, this is a
 
 <li> Instead of border_spacing in the old DwStyle, there are two attributes,
      dw::core::style::Style::hBorderSpacing and
-     dw::core::style::Style::vBorderSpacing, since CSS allowes to specify
+     dw::core::style::Style::vBorderSpacing, since CSS allows to specify
      two values. Without CSS, both attributes should have the same value.
 
 <li> Images are handled differently, see \ref dw-images-and-backgrounds.
diff --git a/devdoc/dw-fixed-positions.doc b/devdoc/dw-fixed-positions.doc
index d62565ff..f7fcdef7 100644
--- a/devdoc/dw-fixed-positions.doc
+++ b/devdoc/dw-fixed-positions.doc
@@ -19,7 +19,7 @@ As defined by CSS
 Idea for tables
 ---------------
 
-Often, tables have a header, which contains informations necessary to
+Often, tables have a header, which contains information necessary to
 interpret the columns in the table body. For this, HTML defines the elements
 &lt;thead&gt; and &lt;tbody&gt;
 <sup><a href="#note-table-footer" id="ref-table-footer">[1]</a></sup>.
@@ -28,7 +28,7 @@ For large tables, the problem occurs that the table header gets out of
 the reader's view. In paged media, where a large table covers multiple
 pages, this is often solved by *repeating* the table header on each
 page occupied by the table. When using a viewport, a table larger than
-the vieport could be displayed like this:
+the viewport could be displayed like this:
 
 1. If the top of the table is within the viewport, show the table
    header at the usual position.
diff --git a/devdoc/dw-images-and-backgrounds.doc b/devdoc/dw-images-and-backgrounds.doc
index 8f07766a..e58e28cf 100644
--- a/devdoc/dw-images-and-backgrounds.doc
+++ b/devdoc/dw-images-and-backgrounds.doc
@@ -30,7 +30,7 @@ initiated:
 - Html_load_image: for embedded images (implemented by dw::Image,
   which implements dw::core::ImgRenderer);
 - StyleEngine::apply (search for "case
-  CSS_PROPERTY_BACKGROUND_IMAGE"): for backgrond images; there are
+  CSS_PROPERTY_BACKGROUND_IMAGE"): for background images; there are
   some implementations of dw::core::ImgRenderer within the context of
   dw::core::style::StyleImage.
 
@@ -214,7 +214,7 @@ dw::Image is only created with type RGB. This leads to several problems:
   with different background colors.
 - The dicache only handles background colors, not background images.
 
-The solution is basicly simple: keep alpha support out of dicache;
+The solution is basically simple: keep alpha support out of dicache;
 instead implement RGBA in dw::Image. As it seems, the main problem is
 alpha support in FLTK/X11.
 
diff --git a/devdoc/dw-interrupted-drawing.doc b/devdoc/dw-interrupted-drawing.doc
index c7037666..586665b6 100644
--- a/devdoc/dw-interrupted-drawing.doc
+++ b/devdoc/dw-interrupted-drawing.doc
@@ -70,7 +70,7 @@ Since
 
 1. #sc-2 is a child of #sc-1, but
 2. #fl-1 is a child of the body, and
-3. a widget can only draw its descendants (not neccessary children,
+3. a widget can only draw its descendants (not necessary children,
    but drawing siblings is not allowed),
 
 #sc-1 cannot be drawn as a whole; instead drawing is **interrupted**
diff --git a/devdoc/dw-layout-views.doc b/devdoc/dw-layout-views.doc
index d1118489..ec14775e 100644
--- a/devdoc/dw-layout-views.doc
+++ b/devdoc/dw-layout-views.doc
@@ -11,7 +11,7 @@ Additionally, there is a structure representing common properties of
 the platform. A platform is typically related to the underlying UI
 toolkit, but other uses may be thought of.
 
-This design helps to archieve two important goals:
+This design helps to achieve two important goals:
 
 <ul>
 <li> Abstraction of the actual drawing, by different implementations
diff --git a/devdoc/dw-layout-widgets.doc b/devdoc/dw-layout-widgets.doc
index e0215562..30cce970 100644
--- a/devdoc/dw-layout-widgets.doc
+++ b/devdoc/dw-layout-widgets.doc
@@ -38,7 +38,7 @@ structure, so you should not have the document structure in mind.
 <h2>Styles</h2>
 
 Each widget is assigned a style, see dw::core::style for more
-informations.
+information.
 
 
 <h2>Iterators</h2>
diff --git a/devdoc/dw-line-breaking.doc b/devdoc/dw-line-breaking.doc
index 14ab97c4..134b498a 100644
--- a/devdoc/dw-line-breaking.doc
+++ b/devdoc/dw-line-breaking.doc
@@ -156,7 +156,7 @@ So we need the following values:
   stretched);
 - the shrinkability \f$y_i\f$, a value denoting how much the space
   after word\f$i\f$ can be shrunken (typically \f${1\over 3} s_i\f$
-  for justified text; otherwise 0, since the spaces are not shrinked);
+  for justified text; otherwise 0, since the spaces are not shrunk);
 - the penalty \f$p_i\f$, if the line is broken after word \f$i\f$;
 - a width \f$h_i\f$, which is added, when the line is broken after
   word \f$i\f$.
@@ -227,7 +227,7 @@ Ragged Borders
 --------------
 
 For other than justified text (left-, right-aligned and centered), the
-spaces between the words are not shrinked or stretched (so \f$y_i\f$
+spaces between the words are not shrunk or stretched (so \f$y_i\f$
 and \f$z_i\f$ are 0), but additional space is added to the left or
 right border or to both. For this reason, an additional stretchability
 \f${Y_0}_a^b\f$ is added (see definition above). Since this space at
@@ -275,7 +275,7 @@ Hyphens
 =======
 
 Words (instances of dw::Textblock::Word), which are actually part of a
-hyphenated word, are always drawn as a whole, not seperately. This
+hyphenated word, are always drawn as a whole, not separately. This
 way, the underlying platform is able to apply kerning, ligatures, etc.
 
 Calculating the width of such words causes some problems, since it is
@@ -342,7 +342,7 @@ calculating a line without hyphenation:
 
 After this, the line is re-calculated.
 
-A problem arrises when the textblock is rewrapped, e.&nbsp;g. when the
+A problem arises when the textblock is rewrapped, e.&nbsp;g. when the
 user changes the window width. In this case, some new instances of
 dw::Textblock::Word must be inserted into the word list,
 dw::Textblock::words. This word list is implemented as an array, which
@@ -448,7 +448,7 @@ resulting possibly in a different value for the minimal width.
 Possible strategies to deal with this problem:
 
 - Ignore. The implications should be minimal.
-- Any solution will make it neccessary to hyphenate at least some
+- Any solution will make it necessary 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,
diff --git a/devdoc/dw-miscellaneous.doc b/devdoc/dw-miscellaneous.doc
index f7e44e73..7a56b33b 100644
--- a/devdoc/dw-miscellaneous.doc
+++ b/devdoc/dw-miscellaneous.doc
@@ -83,12 +83,12 @@ conditions it is allowed to (directly or indirectly) call
 dw::core::Widget::queueResize within an implementation of
 dw::core::Widget::markSizeChange.
 
-Here is the orginal test case (slow, when `if (lines->size () > 0)` is removed
+Here is the original test case (slow, when `if (lines->size () > 0)` is removed
 again):
 
     (for i in $(seq 1 20); do echo '<div style="float:left"><div></div>'; done) > tmp.html; src/dillo tmp.html
 
-You may change the numner (20), or examine smaller cases with
+You may change the number (20), or examine smaller cases with
 <a href="http://home.gna.org/rtfl/">RTFL</a>:
 
     (for i in $(seq 1 3); do echo '<div style="float:left"><div></div>'; done) > tmp.html; src/dillo tmp.html | rtfl-objview -OM -A "*" -a resize -a resize.oofm
diff --git a/devdoc/dw-out-of-flow-floats.doc b/devdoc/dw-out-of-flow-floats.doc
index 72237fca..7decdc13 100644
--- a/devdoc/dw-out-of-flow-floats.doc
+++ b/devdoc/dw-out-of-flow-floats.doc
@@ -92,10 +92,10 @@ When searching for a solution, several difficulties show up:
 
 1. The available width, which is used for the width of the textblock,
    is defined independent of floats. Aside from problems when changing
-   this definition, a dependance on floats would be difficult to
+   this definition, a dependence on floats would be difficult to
    implement, since *sizeRequest* is independent of a position. (See
    also \ref dw-out-of-flow.)
-2. I must admit that I do not rembember the exact rationale and the
+2. I must admit that I do not remember the exact rationale and the
    test case behind adding the exception in
    dw::Textblock::getWidgetRegardingBorderForLine (see above), but
    simply removing this exception will result in a possible
@@ -124,7 +124,7 @@ Instead, this approach is focussed:
   all lines; *y* is irrelevant in this case.
 - Since the textblock will tend to become taller when getting
   narrower, and so possibly cover more (wider) floats, and so become
-  narrower again etc., there may be multible solutions for calculating
+  narrower again etc., there may be multiple solutions for calculating
   the size. Generally, a smaller height (and so larger width) is
   preferred.
 - There remains a problem: what if a word is too large? Should a
diff --git a/devdoc/dw-out-of-flow.doc b/devdoc/dw-out-of-flow.doc
index 2adf51e9..933b30bf 100644
--- a/devdoc/dw-out-of-flow.doc
+++ b/devdoc/dw-out-of-flow.doc
@@ -59,7 +59,7 @@ Implementation overview
   dw::core::Content::WIDGET_IN_FLOW is used. Notice that in the first case,
   there are two pieces of content referring to the same widget. An application
   of this distinction is iterators. (For selection and searching, the generating
-  hierarchy is used, whih is different from the widget hierarchy.)
+  hierarchy is used, which is different from the widget hierarchy.)
 
 Handling widgets out of flow is partly the task of class implementing
 dw::oof::OutOfFlowMgr, which is stored by dw::oof::OOFAwareWidget::outOfFlowMgr,
diff --git a/devdoc/dw-size-request-pos.doc b/devdoc/dw-size-request-pos.doc
index 5a8a4d80..f2a966ec 100644
--- a/devdoc/dw-size-request-pos.doc
+++ b/devdoc/dw-size-request-pos.doc
@@ -63,7 +63,7 @@ occurs with inline blocks.
 This conflict is handled in different ways:
 
 1. Fortunately, this case is irrelevat for floats: an inline block
-   constitutes its own floats container, so that there is no dependance
+   constitutes its own floats container, so that there is no dependence
    on a position within another widget.
 
 2. For positioned elements, this case is relevant, since an inline
diff --git a/devdoc/dw-stacking-context.doc b/devdoc/dw-stacking-context.doc
index 6138ca5d..a0eef7f0 100644
--- a/devdoc/dw-stacking-context.doc
+++ b/devdoc/dw-stacking-context.doc
@@ -74,7 +74,7 @@ of dw::core::Widget::draw and dw::core::Widget::getWidgetAtPoint
 
 <td rowspan="4"> Likewise, the implementation should (i) test
                  dw::oof::OOFAwareWidget::getWidgetOOFAtPoint, and
-                 (ii) search through the chilren. Also, duplicate
+                 (ii) search through the children. Also, duplicate
                  calls should be avoided using
                  dw::core::StackingContextMgr::handledByStackingContextMgr.
 
diff --git a/devdoc/dw-usage.doc b/devdoc/dw-usage.doc
index a23920b8..bcd0fbb0 100644
--- a/devdoc/dw-usage.doc
+++ b/devdoc/dw-usage.doc
@@ -98,7 +98,7 @@ Now, the font can be created:
    styleAttrs.font = dw::core::style::Font::create (layout, &fontAttrs);
 \endcode
 
-As the last attributes, the background and forground colors are
+As the last attributes, the background and foreground colors are
 defined, here dw::core::style::Color::createSimple must be called:
 
 \code
@@ -265,7 +265,7 @@ There are three dw::core::View implementations for FLTK:
      dw::fltk::ui::FltkComplexButtonResource::createNewWidget for details.
 </ul>
 
-More informations about views in general can be found in \ref
+More information about views in general can be found in \ref
 dw-layout-views.
 
 
@@ -344,7 +344,7 @@ dw::core::Layout::scrollTo. It expects several parameters:
 <ul>
 <li>a horizontal adjustment parameter, defined by dw::core::HPosition,
 <li>a vertical adjustment parameter, defined by dw::core::VPosition, and
-<li>a rectangle (\em x, \em y, \em width and \em heigh) of the region
+<li>a rectangle (\em x, \em y, \em width and \em height) of the region
     to be adjusted.
 </ul>
 
diff --git a/devdoc/dw-widget-sizes.doc b/devdoc/dw-widget-sizes.doc
index a6fcac4c..6876dee9 100644
--- a/devdoc/dw-widget-sizes.doc
+++ b/devdoc/dw-widget-sizes.doc
@@ -187,7 +187,7 @@ finished? These rules are important in two circumstances:
 
 Generally, the rules defined below are, in case of doubt, rather
 strict; when changing the rules, loosening is simpler than to tighten
-them, since this will make it neccessary to review old code for calls
+them, since this will make it necessary to review old code for calls
 previously allowed but now forbidden.
 
 Short recap:
diff --git a/devdoc/lout.doc b/devdoc/lout.doc
index 4e1503c6..1ddd844e 100644
--- a/devdoc/lout.doc
+++ b/devdoc/lout.doc
@@ -61,7 +61,7 @@ signals for deletion.
 <h2>Debugging</h2>
 
 In debug.hh, there are some some useful macros for debugging messages,
-see the file for mor informations.
+see the file for mor information.
 
 
 <h2>Identifying Classes at Runtime</h2>
diff --git a/devdoc/rounding-errors.doc b/devdoc/rounding-errors.doc
index a442033e..acf32c64 100644
--- a/devdoc/rounding-errors.doc
+++ b/devdoc/rounding-errors.doc
@@ -17,7 +17,7 @@ avoided by transforming the formula into
 
 \f[y_i = {(\sum_{j=0}^{j=i} x_j) a \over b} - \sum_{j=0}^{j=i-1} y_j\f]
 
-Of corse, when all \f$y_i\f$ are calculated in a sequence,
+Of course, when all \f$y_i\f$ are calculated in a sequence,
 \f$\sum_{j=0}^{j=i} x_j\f$ and \f$\sum_{j=0}^{j=i-1} y_j\f$ can be
 accumulated in the same loop. Regard this as sample:
 
diff --git a/devdoc/uml-legend.doc b/devdoc/uml-legend.doc
index 54004ccd..b367a658 100644
--- a/devdoc/uml-legend.doc
+++ b/devdoc/uml-legend.doc
@@ -19,7 +19,7 @@ digraph G {
 \enddot
 
 (In most cases, the attributes and operations are left away, for
-better readibility. Just click on it, to get to the detailed
+better readability. Just click on it, to get to the detailed
 description.)
 
 Of course, in C++, there are no interfaces, but here, we call a class,
@@ -42,7 +42,7 @@ digraph G {
 
 <h2>Objects</h2>
 
-In some cases, an examle for a concrete constellation of objects is
+In some cases, an example for a concrete constellation of objects is
 shown. An object is represented by a box containing a name and the
 class, separated by a colon.
 
-- 
cgit v1.2.3