fix typos in various pages

src/content/docs/docs/Upgrading/Upgrading to fabric 6.0.mdx

@@ -46,7 +46,7 @@ Some classes have been renamed because their name was a reserved keyword
 
 ## Classes vs Functions
 
-Before fabric was using functions with agumented prototype and an utility to create inheritance and mixins.
+Before fabric was using functions with augmented prototype and an utility to create inheritance and mixins.
 That was ok and functional, but didn't really play well with Typescript.
 
 So before we would have something like this:

src/content/docs/docs/Upgrading/Upgrading to fabric 7.0.mdx

@@ -40,7 +40,7 @@ On top of supported platform changes, there are some notable api changes:
 
 ### WARNING: Object.originX and object.originY now default to 'center'
 
-**This is the only real annonying breaking change.**
+**This is the only real annoying breaking change.**
 
 In fabric 8.0 or later we would like to remove those entirely.
 Unless you set them back to 'left' and 'top', it means that the object is positioned by its center.
@@ -132,7 +132,7 @@ Now you find only viewportPoint and scenePoint in the events
 ### Blur Filter
 Blur filter drawImage implementation has been dropped.
 It had inconsistencies with the webgl one, and didn't work well with transparent pictures.
-WEBGL is really available everywhere and if you need to blur an image with the CPU at leat now the output is consistent.
+WEBGL is really available everywhere and if you need to blur an image with the CPU at least now the output is consistent.
 
 ### Objects
 #### Text
@@ -146,7 +146,7 @@ WEBGL is really available everywhere and if you need to blur an image with the C
 ### Utils
 - `rotatePoint` is gone, use `point.rotate` instead
 - `request` is gone. We use fetch, node 18 supports fetch. There is no reason to use the old request object and status
-- `setStyle` is gone, it was taking care of old browser stlye handling differences.
+- `setStyle` is gone, it was taking care of old browser style handling differences.
 - `parseAttributes`, `parseStyleAttribute`, `parseFontDeclaration`, `parsePointsAttribute`, `parseTransformAttribute` and `getCSSRules`
 have been removed from the package. Those utils were meant for internal usage and never for exposing this part of the api.
 

src/content/docs/docs/configuring-defaults.mdx

@@ -13,7 +13,7 @@ import code1 from './configuring-controls/code1.js?raw';
 
 If you are looking for configuring default controls please check this other page [Configuring controls](/docs/configuring-controls/).
 
-Every object in Fabric.js ( rect, path, circle...) come with a serie of state properties that determine how the object looks like and some of the default interactive behaviours.
+Every object in Fabric.js ( rect, path, circle...) come with a series of state properties that determine how the object looks like and some of the default interactive behaviours.
 
 You can configure those value when instantiating the object or you may want to set certain properties at project level and forget about them.
 There are a couple of common reasons why you would like to do that globally:
@@ -58,7 +58,7 @@ Differently from Fabric.js version 5 and earlier, this won't affect already cons
 
 Javascript Classes syntax does not support properties on the Prototype that Fabric.js was leveraging with Objects before.
 
-If you really like the old behaviour you can still switch to it by writing some code.
+If you really like the old behavior you can still switch to it by writing some code.
 
 Here is an example for FabricObject:
 

src/content/docs/docs/events.mdx

@@ -17,11 +17,11 @@ Simple examples are:
 - When a transformation is finished
 
 Events have been always part of fabric.js, way before the custom controls api and selection callbacks were introduced.
-As a result events have also been used to modify standard fabric.js behaviours creating complex code flows.
+As a result events have also been used to modify standard fabric.js behaviors creating complex code flows.
 
 ### When to use events
 
-Try to do *not* depend too much from events, is not a great pattern outisde mouse and selections.
+Try to do *not* depend too much from events, is not a great pattern outside mouse and selections.
 At the time i joined the project events were already there and with time there have been additions but never cleanups.
 Try to think in this way: In Fabric.sj events are meant to alert you of things happening that you 
 can't reach because are part of code you didn't write.
@@ -80,9 +80,9 @@ dispose();
 The disposer is a function that when called will remove the event listener, this may be easier
 to use than keeping a reference to the handler function used with `on` as an alternative.
 
-The handlers are called bound on the instance, so in the handler funcion the `this` is  either the fabric object or the fabric canvas.
-Fat arrow functions can't be bound to anyhting else than the context in which they were created, so if you don't want unexpected
- side effects **use functions for event handers**.
+The handlers are called bound on the instance, so in the handler function the `this` is  either the fabric object or the fabric canvas.
+Fat arrow functions can't be bound to anything else than the context in which they were created, so if you don't want unexpected
+ side effects **use functions for event handlers**.
 
 Fabric.js calls `fire` to trigger event listeners, the listeners that are hosted on the instance are then called bound in order
  of registration and with a data object as first and only argument.
@@ -96,15 +96,15 @@ As an example the `mouse:down` event will have:
 - `e` the original mouse event
 - `scenePoint` the point where the event happened in the canvas coordinate system
 - `viewportPoint` the point where the event happened in the viewport coordinate system
-- `target` the object that was hit by the event, possibly undefimed
+- `target` the object that was hit by the event, possibly undefine
 - `subTargets` an array of objects that were hit by the event, possibly empty, if the target has children
 - `transform` the current ongoing transform action (if any, like scaling for example)
 
 ### Events list
 
 There isn't an hand curated even list with descriptions and data passed in the argument.
 One way to get to know the events is to look at the event demo here: [Events inspector](/demos/events-inspector/) or to use a type enabled ide and look at 
-auto completition for the on method.
+auto completion for the on method.
 
 ### Custom events
 

src/content/docs/docs/fabric-object-caching.mdx

@@ -1,7 +1,7 @@
 ---
 date: '2016-11-26'
-description: 'Caching of object, properties and beahvior'
-title: Caching of object, properties and beahvior
+description: 'Caching of object, properties and behavior'
+title: Caching of object, properties and behavior
 sidebar:
   order: 700
 ---
@@ -21,7 +21,7 @@ In general every top level object on the fabric.canvas ends up on its own image
  and in case it refreshes the copy and then uses it for painting again.
 
 The caching strategy is very simple in Fabric.js and there are few properties on the objects or in the top level configuration to slightly tweak it.
-In practice then this process has a lot of costrains and perfomance pitfalls. Please be sure to read this entire page to
+In practice then this process has a lot of contrains and performance pitfalls. Please be sure to read this entire page to
  understand the basics.
 
 ## Tweaks and configuration
@@ -46,7 +46,7 @@ Also spot differences in scaling between `noScaleCache` true or false.
 In canvases below left canvas is `true`, that means that during the scaling transformation the object is not regenerated.
 The right canvas has scaling that invalidates the cache every scale change.
 You can also open your developer tools and record scaling performances in both cases and compare.
-Take care that the below yellow care is a large complex object made of 417 innner objects and gradients.
+Take care that the below yellow care is a large complex object made of 417 inner objects and gradients.
 if you scale an object more than 3 times the original size you will notice blurring that then gets fixed with a new cached
  copy as soon as you perform a mouse up. Try it by yourself by scaling the little yellow cars on both canvases:
 
@@ -116,7 +116,7 @@ When a cache property is set in an object that is inside a group, all the parent
 
 Caching has a list of compromises in order to be somehow convenient most of the time.
 A cached canvas can't be too big or it will be too slow to be refreshed for example.
-It can't be too small or it will not trigger certain GPU optmization paths in browsers
+It can't be too small or it will not trigger certain GPU optimization paths in browsers
  ( this information may be obsolete with browser changes )
 
 In the Fabric.js configuration object there are 3 values that relate to caching:
@@ -151,10 +151,10 @@ minCacheSideLimit will determine the mini size of a side of the cache. At any ob
 If you are caching a Rect that is 1 by 1, you will have a 256 by 156 canvas with a single pixel filled.
 
 maxCacheSizeLimit and perfLimitSizeTotal are determining the maximum side and the maximum surface of the cache canvas.
-So with a value of 4k pixels and a perfLimitSizeTotal of around 2 milion pixels, if your object is 5000 by 10000 it will cached to a size of
+So with a value of 4k pixels and a perfLimitSizeTotal of around 2 million pixels, if your object is 5000 by 10000 it will cached to a size of
  4096 by (2097152 / 4096). The biggest side will be reduce to 4096 and the other one will be fit in what 2Milion pixels allow.
 
-You can change those value to experiment with what quality and speed fit best for your application by doing the follwing:
+You can change those value to experiment with what quality and speed fit best for your application by doing the following:
 
 ```ts
 import { config } from 'fabric';
@@ -339,11 +339,11 @@ Once painted and optimally centered the cache canvas is built and then painted o
 
 ### Performance pitfalls and issues
 
-Performance gains are not always there and there are also issues with blurryness rarely.
+Performance gains are not always there and there are also issues with blurriness rarely.
 
 Caching is beneficial depending on what your project looks like.
 If Are you drawing just a bunch of circles, rects or simple polygons caching is not a big deal. Calling `ctx.fillRect` or `ctx.drawImage`
-is mostly the same and if itsn't exactly the same you save on cache canvas creation and size comparision and a lot of ram.
+is mostly the same and if isn't exactly the same you save on cache canvas creation and size comparison and a lot of ram.
 
 On the other side if you importing and displaying large and complex svgs or groups well in that case cache is helpful.
 
@@ -384,10 +384,10 @@ In general viewport zooming is a performance killer with many objects and cache.
 
 The canvas vector drawing is anti aliased. This means that if you draw a black single pixel line at at position X, you will get 
  the line across pixel X and X-1. This across line means that both pixels will be grey and none black, you get a blurry line.
-it is very important that things are drawn as crisp as possible in the cache canvas to avoid to add blurryness on top of blurryness.
+it is very important that things are drawn as crisp as possible in the cache canvas to avoid to add blurriness on top of blurriness.
 To produce the below screenshot i created 2 cached rects, one wide 51px, another wide 51.5px, both with a 1px stroke.
 
-![Cache blurryness](/article_assets/cache_compare.png)
+![Cache blurriness](/article_assets/cache_compare.png)
 
 Fabric.js is able to make both sides crisp in the case of the 51px rect, by pixel align the rect on a 256px surface, understanding that
  we need to draw on integer pixels as much as possible. For the 51.5 pixel rect this is not possible and a single side is blurry.

src/content/docs/docs/index.md

@@ -1,7 +1,7 @@
 ---
 date: '2015-03-09'
 title: 'Introduction to Fabric.js'
-description: 'A thorough guide to profeciently using Fabric.js'
+description: 'A thorough guide to proficiently using Fabric.js'
 ---
 
 A brief introduction to Fabric.js and especially what the user can expect from this guide

src/content/docs/docs/using-custom-properties.mdx

@@ -10,7 +10,7 @@ sidebar:
 When building your application you may need to attach to objects some custom properties.
 One very common need is to have an `id` or a `name` on objects.
 
-If you are using Typescript or if you want your IDE to suggest you completition you will need to clearly state which those properties are.
+If you are using Typescript or if you want your IDE to suggest you completion you will need to clearly state which those properties are.
 
 On top of that there is the serialization issue that will require you to pass down those properties in the argument of the function `toObject`.
 
@@ -42,15 +42,15 @@ declare module "fabric" {
 FabricObject.customProperties = ['name', 'id'];
 ```
 
-This change will make the types work correcty:
+This change will make the types work correctly:
 
 ![](/article_assets/custom_props/constructor.png)
 ![](/article_assets/custom_props/property.png)
 ![](/article_assets/custom_props/export.png)
 
 ### Custom methods
 
-In general it makes things simplier if you can stick to external utility functions, but in the cases in which you want to attach a specific method to the prototype of different classes, you have to do modify the interface again:
+In general it makes things simpler if you can stick to external utility functions, but in the cases in which you want to attach a specific method to the prototype of different classes, you have to do modify the interface again:
 
 ```ts
 // declare the methods for typescript

src/content/docs/docs/why-fabric.md

@@ -1,7 +1,7 @@
 ---
 date: '2024-11-17'
 title: 'Fabric.js'
-description: 'Introductio to Fabric.js'
+description: 'Introduction to Fabric.js'
 ---
 
 ## What is Fabric.js