From 0da4311c3a08fa606b9cef8a9fc52c3df3cf1acd Mon Sep 17 00:00:00 2001 From: Rotzbua Date: Wed, 28 Dec 2022 17:03:26 +0100 Subject: [PATCH] Fix typos --- documentation/src/api_burn.rst | 2 +- documentation/src/api_drawing.rst | 2 +- documentation/src/api_edges.rst | 4 ++-- documentation/src/api_existing_parts.rst | 2 +- documentation/src/api_navigation.rst | 2 +- documentation/src/faq.rst | 6 +++--- documentation/src/install.rst | 4 ++-- 7 files changed, 11 insertions(+), 11 deletions(-) diff --git a/documentation/src/api_burn.rst b/documentation/src/api_burn.rst index d7fbab9..e504ea6 100644 --- a/documentation/src/api_burn.rst +++ b/documentation/src/api_burn.rst @@ -4,7 +4,7 @@ Burn correction The burn correction -- aka kerf -- is done in two separate steps. The first mechanism is used during drawing. After rendering there is a post processing step that replaces the inverted arcs of the inner corners by -Bezier loops that can be cut in a continous motion. +Bezier loops that can be cut in a continuous motion. The first mechanism is integrated into the low level commands of Boxes.py. So for the most part developers do not need to diff --git a/documentation/src/api_drawing.rst b/documentation/src/api_drawing.rst index f0dabdc..b871d7a 100644 --- a/documentation/src/api_drawing.rst +++ b/documentation/src/api_drawing.rst @@ -29,7 +29,7 @@ These should probably be Edge classes. But right now they are still functions. Tab support ........... -Tabs are small interuptions in the border of a part to keep it in +Tabs are small interruptions in the border of a part to keep it in place. They are enabled with the **tabs** parameter. All **Edges** automatically create about two tabs. So parts like :py:meth:`boxes.Boxes.rectangularWall` will have 8 tabs holding them diff --git a/documentation/src/api_edges.rst b/documentation/src/api_edges.rst index b1115f7..e3b13f3 100644 --- a/documentation/src/api_edges.rst +++ b/documentation/src/api_edges.rst @@ -10,7 +10,7 @@ Edge instances have a Settings object associated with them that keeps the details about how the edge should look like. Edges that are supposed to work together share the same Settings object to ensure they fit together - assuming they have the same length. Most edges are -symetrical to unsure they fit together even when drawn from different +symmetrical to unsure they fit together even when drawn from different directions. Although there are a few exception - mainly edges that provide special features like hinges. @@ -21,7 +21,7 @@ properly. When drawing an Edge there is a virtual straight line that is the border the shape of the part (e.g. an rectangle). But the actual Edge has often to be drawn elsewhere. Best example if probably the ``F`` Edge that matches the normal finger joints. It has to start -one material thickness outside of the virual border of the part so the +one material thickness outside of the virtual border of the part so the cutouts for the opposing fingers just touch the border. The Edge classes have a number of methods to deal with these kind of offsets. diff --git a/documentation/src/api_existing_parts.rst b/documentation/src/api_existing_parts.rst index df53869..a9d6ff5 100644 --- a/documentation/src/api_existing_parts.rst +++ b/documentation/src/api_existing_parts.rst @@ -18,7 +18,7 @@ Currently there are the following parts: Parts Class ........... -More parts are available in a separete class. An instance is available as +More parts are available in a separate class. An instance is available as **Boxes.parts** .. automethod:: boxes.parts.Parts.disc diff --git a/documentation/src/api_navigation.rst b/documentation/src/api_navigation.rst index 7845a10..5994173 100644 --- a/documentation/src/api_navigation.rst +++ b/documentation/src/api_navigation.rst @@ -37,6 +37,6 @@ It can be used with the following code pattern: Parts of the code still directly use the back end primitives **Boxes.ctx.save()** and **Boxes.ctx.restore()**. But this has several disadvantages and is -discouraged. For one it requires matchiung calls. It also does not +discouraged. For one it requires matching calls. It also does not reset the starting point of the next line. This is "healed" by a follow up **.moveTo()**. Use **.moveTo(0, 0)** if in doubt. diff --git a/documentation/src/faq.rst b/documentation/src/faq.rst index f41b851..93320aa 100644 --- a/documentation/src/faq.rst +++ b/documentation/src/faq.rst @@ -15,14 +15,14 @@ Why do my parts not fit together? Well, this could be a bug in Boxes.py but there are a few more likely causes to check for: -* The material you use does not have the thickness you think. Measure it with at least a caliper. Even a few hundredth of a milimeter will make the difference between a loose fit, a light or a heavy pressfit or no fit at all. +* The material you use does not have the thickness you think. Measure it with at least a caliper. Even a few hundredth of a millimeter will make the difference between a loose fit, a light or a heavy pressfit or no fit at all. -* You might have choosen the "burn" value too big. As it compensates for the material cut away by the laser smaller values make a looser fit, bigger values make a tighter fit. The right value may be different for different materials and different thicknesses. +* You might have chosen the "burn" value too big. As it compensates for the material cut away by the laser smaller values make a looser fit, bigger values make a tighter fit. The right value may be different for different materials and different thicknesses. Why is my box a bit too big? ---------------------------- -By default all sizes are inner sizes. So on the outside the box is bigger as the walls need to go somewhere. Some generators offer an "outside" param that includes the walls in the measurements. In general you should check the generated parts for plausability before hitting the start button on your laser cutter. +By default all sizes are inner sizes. So on the outside the box is bigger as the walls need to go somewhere. Some generators offer an "outside" param that includes the walls in the measurements. In general you should check the generated parts for plausibility before hitting the start button on your laser cutter. Why is my box a bit too small? ------------------------------ diff --git a/documentation/src/install.rst b/documentation/src/install.rst index eb9bfd2..ca84b7e 100644 --- a/documentation/src/install.rst +++ b/documentation/src/install.rst @@ -58,7 +58,7 @@ Running from working dir ------------------------ Due to lazy developer(s) Boxes.py can also run from the Git checkout. -The scripts in :code:`scripts/` are all suppossed to just work right +The scripts in :code:`scripts/` are all supposed to just work right after :code:`git clone`. The Inkscape needs a bit manual work to get running. See below. @@ -76,7 +76,7 @@ binary package) **git repository easy way** After cloning it may be most convenient to generate the .inx files -right in place by executing :code:`scripts/boxes2inkscape` with the taget +right in place by executing :code:`scripts/boxes2inkscape` with the target path as only parameter. - global: :code:`scripts/boxes2inkscape /usr/share/inkscape/extensions/`