Fixed spell checker errors

Author: BasicPrimitives

server/src/static/crossteamgroup.md

@@ -2,7 +2,7 @@
 ### Cross Functional Team Visualization
 * Group titles
 * Custom templates
-* Selection checkmarks
+* Selection check marks
 
 ### Frame
 * Displays selected nodes placed outside viewport on the frame

server/src/static/dynamicloading.md

@@ -1,7 +1,7 @@
 ## Demoed features
 ### Navigation and auto layout 
 * This demo dynamically loads chart nodes as user navigates around diagram. The top 3 levels stay loaded permanently. All other levels are loaded only as user browses down into them and they are discarded as it navigates out to any other branch of the hierarchy.
-* Items selection and pinning. If user pins loaded node it stays loaded and not being descarded when user goes away to other branch.
+* Items selection and pinning. If user pins loaded node it stays loaded and not being discarded when user goes away to other branch.
 
 ### General
 * Diagram reset

server/src/static/familychartitemsordering.md

@@ -1,6 +1,6 @@
 ## Demoed features
 ### User guided family chart nodes ordering
-Family Tree Component orders and aligns nodes automatically, it searches for the best order of family nodes. This is very handy for initial rendering, but lack of ordering rules keeps layout engine reordering nodes every time we add new nodes into diagram. So end users have to adopt to global layout changes every time they make changes to diagram nodes. The opposite situation when user defines position for every node drives us back to the age of diagram editors and manual nodes placement. This is inconvinient, so we combine the best of two approaches: autolayout and user guided nodes order. Our layout engine follows end user ordering rules as long as they are applicable and ignores them when they are not relevant.
+Family Tree Component orders and aligns nodes automatically, it searches for the best order of family nodes. This is very handy for initial rendering, but lack of ordering rules keeps layout engine reordering nodes every time we add new nodes into diagram. So end users have to adopt to global layout changes every time they make changes to diagram nodes. The opposite situation when user defines position for every node drives us back to the age of diagram editors and manual nodes placement. This is inconvenient, so we combine the best of two approaches: auto layout and user guided nodes order. Our layout engine follows end user ordering rules as long as they are applicable and ignores them when they are not relevant.
 
 This demo diagram displays relations guiding layout engine in form of horizontal red dotted lines. The arrow direction defines who gets its order position first and who is next.
 
@@ -17,4 +17,4 @@ This demo diagram displays relations guiding layout engine in form of horizontal
 
 ### Annotations
 * Offbeat Connector Annotation - use nodes context buttons to show connector annotation between any 2 nodes of diagram
-* Background Annotation - select nodes to enable background annotation. Background annotation automerges for neighbouring nodes.
+* Background Annotation - select nodes to enable background annotation. Background annotation auto merges for neighbouring nodes.

server/src/static/highlightannotations.md

@@ -3,9 +3,9 @@
 * Straight connector annotations
 * Stacking connector annotations
 
-Diagram displays permanent connector annotations for current cursor node and dynamic for current highlited node. 
+Diagram displays permanent connector annotations for current cursor node and dynamic for current highlighted node. 
 
-Component is designed to pefrom minimal volume of rendering and layout calculations. When user moves mouse pointer over nodes, chart shows highlight and draws on-screen connector annotations. Diagram layout does not depen on annotations, it does not reserve any space for them, so component draws connector annotations on top of diagram nodes without general layout, so user gets instant visual feedback for node under mouse cursor. This is very handy when we have a lot of connector annotations and we don't want them to be shown all the time.
+Component is designed to perform minimal volume of rendering and layout calculations. When user moves mouse pointer over nodes, chart shows highlight and draws on-screen connector annotations. Diagram layout does not depend on annotations, it does not reserve any space for them, so component draws connector annotations on top of diagram nodes without general layout, so user gets instant visual feedback for node under mouse cursor. This is very handy when we have a lot of connector annotations and we don't want them to be shown all the time.
 
 ### General
 * Diagram reset

server/src/static/javascript

@@ -1 +1 @@
-Subproject commit 57bcf49ed098984402adbea234e9bd8451ff6b82
+Subproject commit b1c8e3e00615ec8fa7774c3bf030f20ce94fd603

server/src/static/largehierarchy.md

@@ -2,7 +2,7 @@
 ### Navigation and auto layout 
 * Fitting large diagram into available screen space. In order to make navigation of large hierarchies possible, component folds nodes into markers.
 * Showing context menu and details for node in user focus. Component shows details of cursor node immediate children and parents, so user can click them and navigate step by step further around the diagram.
-* Items selection and pinning. As user broses diagram it may pin nodes it is intrested in, so their details stay visible.
+* Items selection and pinning. As user browses diagram it may pin nodes it is interested in, so their details stay visible.
 ### General
 * Diagram reset
 * PDF file generation

server/src/static/orgeditor.md

@@ -26,4 +26,4 @@
 
 
 ### Matrix children layout 
-Usually organizational charts grow horizontally more than vertically. So keeping nodes in square formation saves horizontal space. It is important to fit matrix into width of screen, it is fine to scroll nodes vertically or horizontally, but necessaty to scroll both ways creates usability issue, so chart support extra option `maximumColumnsInMatrix` limiting number of columns. For example when node has 4 children they are matrxied into 2 * 2 matrix, 9 children are matrixed into 3 * 3 matrix, 16 into 4 * 4 and so on, but if we put limitation for number of columns for example at 4 then 20 children would be matrixed into 4 * 5 matrix.
+Usually organizational charts grow horizontally more than vertically. So keeping nodes in square formation saves horizontal space. It is important to fit matrix into width of screen, it is fine to scroll nodes vertically or horizontally, but necessity to scroll both ways creates usability issue, so chart support extra option `maximumColumnsInMatrix` limiting number of columns. For example when node has 4 children they are matrixed into 2 * 2 matrix, 9 children are matrixed into 3 * 3 matrix, 16 into 4 * 4 and so on, but if we put limitation for number of columns for example at 4 then 20 children would be matrixed into 4 * 5 matrix.

server/src/static/react

@@ -1 +1 @@
-Subproject commit 35db028286142ab3c5009192c0416c4becfa137a
+Subproject commit 9581614adfca5f9c8c770791625e3cabbbf4bf6f

server/src/static/techtree.md

@@ -1,8 +1,8 @@
 ## Demoed features
 ### User guided family chart nodes ordering
-This dependency graph demostrates usage of `primaryParent` layout option. It contains around 170 nodes with some of the nodes being arranged into multiple explicit sequences that show the evolution and order of dependency of said nodes. We need to display all of the node sequences together in one hierarchy meanwhile allowing the user to see the seperate individual sequences and their nodes. In order to accomplish this, we can set priority for how nodes should align under their parents. In a family diagram every node may have multiple parents and by default aligns itself to be equally distanced from all of them. In this case however, we are intrested in having nodes be closer or farther away from a specific parent. This is done by giving higher priority to one of its parents. Our family diagram provides the property `primaryParent` which can be applied to a node. Automatically indicating that the child node or nodes should be alligned closer to said parent within the hierarchy. This property is optional and doesn't change any node relations, so if it is applied to a non-exsisting parent then it will simply be ignored.
+This dependency graph demonstrates usage of `primaryParent` layout option. It contains around 170 nodes with some of the nodes being arranged into multiple explicit sequences that show the evolution and order of dependency of said nodes. We need to display all of the node sequences together in one hierarchy meanwhile allowing the user to see the separate individual sequences and their nodes. In order to accomplish this, we can set priority for how nodes should align under their parents. In a family diagram every node may have multiple parents and by default aligns itself to be equally distanced from all of them. In this case however, we are interested in having nodes be closer or farther away from a specific parent. This is done by giving higher priority to one of its parents. Our family diagram provides the property `primaryParent` which can be applied to a node. Automatically indicating that the child node or nodes should be aligned closer to said parent within the hierarchy. This property is optional and doesn't change any node relations, so if it is applied to a non-existing parent then it will simply be ignored.
 
-This alignment priority can then be used to create a full sequence, branch or chain of nodes within a grander herarchy. This can be seen if you take a look at the sequence of flight related technologies starting from `Subsonic flight` and ending with `Cutting-Edge Aeronautics`.
+This alignment priority can then be used to create a full sequence, branch or chain of nodes within a grander hexarchy. This can be seen if you take a look at the sequence of flight related technologies starting from `Subsonic flight` and ending with `Cutting-Edge Aeronautics`.
 
 ### Annotations
 * Offbeat Connector Annotations - red annotations display `primaryParent` references to enforce the hierarchy

server/src/static/verticallayoutorganizationalchart.md

@@ -9,7 +9,7 @@
 * Places group title on the right and context buttons on the left
 * Rotates root's group title 180 degree
 * Places vertical managers formation on the left of the root connection line
-* Aligns horiozontal children formation to the left of the managers node
+* Aligns horizontal children formation to the left of the managers node
 
 ## Children layout 
 Chart supports following layouts for children