feat: Flat import of markdown repo
This is a flat (without history) import of (some of) the content from our markdown module. We've imported this without history because the repo contains our blog posts and showcases posts content prior to porting them to strapi. Since this contains many images, it would balloon the size of this repo to import the full history. Instead, please refer to the history of the (archived) markdown repo at: https://github.com/freesewing/markdown
This commit is contained in:
parent
1671a896b5
commit
b34a2ee2ed
6132 changed files with 244167 additions and 0 deletions
20
markdown/dev/guides/best-practices/en.md
Normal file
20
markdown/dev/guides/best-practices/en.md
Normal file
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Design guide
|
||||
order: 300
|
||||
for: developers
|
||||
icons:
|
||||
- thumbup
|
||||
- pattern
|
||||
about: "There's often many different ways to do things. Learn about our conventions and best practices"
|
||||
goals:
|
||||
- Re-using measurement and options names
|
||||
- Re-using CSS classes
|
||||
- Respecting draft settings
|
||||
- Using percentage options where possible
|
||||
- Using translation keys for text
|
||||
- Constructing paths counter-clockwise
|
||||
---
|
||||
|
||||
Here is a list of best practices when designing patterns:
|
||||
|
||||
<ReadMore list />
|
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
title: Construct paths counter-clockwise
|
||||
order: 70
|
||||
---
|
||||
|
||||
Construct your paths counter-clockwise. You have to pick a direction anyway, and going
|
||||
counter-clockwise is a bit of a convention.
|
||||
|
||||
This applies both to naming points (specifically the control points of curves)
|
||||
and the order in which you define your points.
|
||||
|
||||
Obviously, the order in which you add points to your code needs to take a backseat
|
||||
to the logic of your code. But typically what you're doing is constructing an outline
|
||||
of (a part of) a garment.
|
||||
|
||||
So pick a point, and make your way around counter-clockwise.
|
||||
|
||||
When naming control points for curves, re-use the name of the point they are attached to
|
||||
and add `Cp1` to the control point before and `Cp2` to the control point after the point if
|
||||
, once again, you'd follow your path counter-clockwise.
|
||||
|
||||
|
||||
For example:
|
||||
|
||||
```js
|
||||
part.paths.seam = new Path()
|
||||
.move(points.hemCenter)
|
||||
.line(points.hemSide)
|
||||
.line(points.waistSide)
|
||||
.curve(points.waistSideCp2, points.armholeCp1, points.armhole)
|
||||
```
|
||||
|
||||
<Tip>
|
||||
|
||||
##### This convention helps with `Path.offset()` too
|
||||
|
||||
Constructing a path counter-clockwise will also ensure that the path offset goes outwards
|
||||
rather than inwards.
|
||||
|
||||
</Tip>
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
title: Respect draft settings
|
||||
order: 40
|
||||
---
|
||||
|
||||
Apart from the pattern options that you configure for your pattern,
|
||||
all FreeSewing patterns have a set of [draft settings](/reference/settings/) that can be tweaked
|
||||
by the user.
|
||||
|
||||
While many of these will automatically be handled by FreeSewing, there are some
|
||||
that you should take into account while developing your pattern. They are:
|
||||
|
||||
## Complete
|
||||
|
||||
The [complete](/reference/settings/#complete) setting is a boolean that is either true or false.
|
||||
Its goal is to determine whether we should draft a *complete* pattern, or merely the outline.
|
||||
|
||||
## Paperless
|
||||
|
||||
The [paperless](/reference/settings/#paperless) setting is a boolean that is either true or false.
|
||||
|
||||
A *paperless* pattern is a pattern that has extra dimensions so users can trace the
|
||||
paper on fabric or paper without having the need to print it.
|
||||
|
||||
## Seam allowance
|
||||
|
||||
The [sa](/reference/settings/#sa) setting is a number that controls the seam allowance.
|
||||
|
||||
Unless `sa` is zero, you should add the requested seam allowance to your pattern.
|
||||
|
||||
<Tip>
|
||||
|
||||
##### Use a multiple of `sa` for your hem allowance
|
||||
|
||||
Resist the temptation to use an absolute value for any seam allowance, including at the hem.
|
||||
|
||||
Always use a multiple of the `sa` value.
|
||||
|
||||
</Tip>
|
||||
|
||||
## Example
|
||||
|
||||
To respect the `complete`, `paperless`, and `sa` draft settings, structure your parts as such:
|
||||
|
||||
```js
|
||||
export default function(part) {
|
||||
let { complete, sa, paperless } = part.shorthand()
|
||||
// Your paths and points here
|
||||
|
||||
if (complete) {
|
||||
// Your snippets, text, helplines and so on here
|
||||
|
||||
if (sa) {
|
||||
// Your seam allowance here
|
||||
}
|
||||
|
||||
if (paperless) {
|
||||
// Your dimensions
|
||||
}
|
||||
}
|
||||
|
||||
return part
|
||||
}
|
||||
```
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
---
|
||||
title: Re-use CSS classes
|
||||
order: 30
|
||||
---
|
||||
|
||||
While you can style your pattern however you want, try to re-use the CSS class names that
|
||||
are in use in our default [theme plugin](/reference/packages/plugin-theme/).
|
||||
|
||||
Doing so will ensure consistent styling for patterns.
|
18
markdown/dev/guides/best-practices/reuse-measurements/en.md
Normal file
18
markdown/dev/guides/best-practices/reuse-measurements/en.md
Normal file
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Re-use measurements
|
||||
order: 10
|
||||
---
|
||||
|
||||
When designing patterns, re-use the measurements that are already in use as much as possible.
|
||||
Nobody wins when every pattern requires its own set of measurements, or names
|
||||
certain measurements differently.
|
||||
|
||||
<Tip>
|
||||
|
||||
###### See our models packages for standard measurement names
|
||||
|
||||
The [@freesewing/models](/reference/packages/models/)
|
||||
package contains all our standard measurement names.
|
||||
|
||||
</Tip>
|
||||
|
12
markdown/dev/guides/best-practices/reuse-options/en.md
Normal file
12
markdown/dev/guides/best-practices/reuse-options/en.md
Normal file
|
@ -0,0 +1,12 @@
|
|||
---
|
||||
title: Re-use options
|
||||
order: 20
|
||||
---
|
||||
|
||||
The same arguments for re-using measurements are also (somewhat) true for options.
|
||||
|
||||
While your pattern may require some very specific
|
||||
options, there's probably a bunch that are similar to other patterns. Re-use those names.
|
||||
|
||||
As in, `bicepsEase` exists. So don't go creating an `upperArmEase` option.
|
||||
|
32
markdown/dev/guides/best-practices/use-percentages/en.md
Normal file
32
markdown/dev/guides/best-practices/use-percentages/en.md
Normal file
|
@ -0,0 +1,32 @@
|
|||
---
|
||||
title: Use percentage options where possible
|
||||
order: 50
|
||||
---
|
||||
|
||||
When designing patterns, you should refrain from using absolute values.
|
||||
|
||||
That 6cm ease you add might be fine for all scenarios you tested,
|
||||
but then somebody comes around who is twice your size, or who is making clothes for a doll,
|
||||
and things will go off the rails.
|
||||
|
||||
Don't be tempted to add absolute values to your patterns, as they don't scale.
|
||||
Instead, embrace percentages as options.
|
||||
|
||||
<Tip>
|
||||
|
||||
##### Use the antperson tests
|
||||
|
||||
To check how well your pattern scales, you can
|
||||
use the *antperson* test by sampling the pattern for 2 models:
|
||||
|
||||
- A model with measurements of avarage person (the person)
|
||||
- A model with measurements 1/10th of an average person (the ant)
|
||||
|
||||
A well-designed pattern will scale a factor 10 down and hold its shape.
|
||||
If your pattern makes assumptions about size, this test will show that.
|
||||
|
||||
FreeSewing's development environment provides these tests out of the box,
|
||||
so you can see their results at the click of a button.
|
||||
|
||||
</Tip>
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
title: Use translation keys, not text
|
||||
order: 60
|
||||
---
|
||||
|
||||
Don't insert literal text in your patterns. Instead, insert a key that can then be translated.
|
||||
|
||||
For example, if you want to put *Finish with bias tape* on your pattern, don't be
|
||||
tempted to do this:
|
||||
|
||||
```js
|
||||
path.seam.attr("data-text", "Finish with bias tape");
|
||||
```
|
||||
|
||||
That (English) string is now hard-coded in your pattern. As freesewing supports
|
||||
translation out of the box, it would be a real shame not to make use of it.
|
||||
|
||||
Instead, insert a key to identify the string:
|
||||
|
||||
```js
|
||||
path.seam.attr("data-text", "finishWithBiasTape");
|
||||
```
|
||||
|
||||
This way, it can be translated.
|
||||
|
||||
You can find and browse the translations and available translation keys [in the freesewing/freesewing project](https://github.com/freesewing/freesewing/tree/develop/packages/i18n/src/locales).
|
5
markdown/dev/guides/en.md
Normal file
5
markdown/dev/guides/en.md
Normal file
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Guides
|
||||
order: 1020
|
||||
---
|
||||
|
18
markdown/dev/guides/patterns/config/en.md
Normal file
18
markdown/dev/guides/patterns/config/en.md
Normal file
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: Configuration
|
||||
order: 60
|
||||
---
|
||||
|
||||
<Example
|
||||
part="docs_overview"
|
||||
caption="The pattern configuration holds important information about the pattern"
|
||||
options={{focus: "config"}}
|
||||
/>
|
||||
|
||||
A pattern's [configuration](/reference/config/) is created by the pattern designer
|
||||
and details a number of important things about the pattern, like:
|
||||
|
||||
- The measurements that are required to draft the pattern
|
||||
- The different parts in the pattern and how they depend on each other
|
||||
- The different options that are available to tweak the pattern
|
||||
|
51
markdown/dev/guides/patterns/en.md
Normal file
51
markdown/dev/guides/patterns/en.md
Normal file
|
@ -0,0 +1,51 @@
|
|||
---
|
||||
title: Pattern guide
|
||||
order: 200
|
||||
for: contributors
|
||||
icons:
|
||||
- blocks
|
||||
- pattern
|
||||
about: |
|
||||
Learn about the main building blocks that make up a FreeSewing pattern
|
||||
goals:
|
||||
- Learn about points
|
||||
- Learn about paths
|
||||
- Learn about snippets
|
||||
- Learn about parts
|
||||
- Learn about the pattern configuration
|
||||
- Learn about the pattern store
|
||||
- Learn about the pattern itself
|
||||
---
|
||||
|
||||
This illustration is a good starting point to gain a better
|
||||
understanding of the structure of a FreeSewing pattern:
|
||||
|
||||
<Example
|
||||
part="docs_overview"
|
||||
caption="A schematic overview of FreeSewing"
|
||||
/>
|
||||
|
||||
As you learn more about FreeSewing, you'll discover that there's more
|
||||
to this picture than meets the eye. So let's get started.
|
||||
|
||||
If we look at our image, it can can divided into three areas:
|
||||
|
||||
- The left area with the *settings* box
|
||||
- The middle area with the *Pattern* box and everything in it
|
||||
- The right area with the *draft* box and the *SVG* and *React* logos
|
||||
|
||||
<Note>
|
||||
|
||||
The left and right parts are all about how to integrate FreeSewing in your *frontend*.
|
||||
In other words, how you'll plug it into your website, or online store, or a mobile
|
||||
application.
|
||||
|
||||
That part is outside the scope of this text.
|
||||
|
||||
</Note>
|
||||
|
||||
Let's take a closer look at everything that is contained within our central *Pattern* box:
|
||||
|
||||
<ReadMore list />
|
||||
|
||||
|
21
markdown/dev/guides/patterns/parts/en.md
Normal file
21
markdown/dev/guides/patterns/parts/en.md
Normal file
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: Parts
|
||||
order: 40
|
||||
---
|
||||
|
||||
<Example
|
||||
part="docs_overview"
|
||||
caption="Parts divide your pattern into re-usable components"
|
||||
options={{focus: "Part"}}
|
||||
/>
|
||||
|
||||
Parts are a container for the points, paths, and snippets of (a part of) your pattern.
|
||||
They are also re-usable by other patterns, which makes them a powerful tool to build
|
||||
a pattern library.
|
||||
|
||||
If you design a T-shirt pattern with a `front`, `back`, and `sleeve`, each of those would be a part.
|
||||
If you then wanted to make a long-sleeved version of your T-shirt pattern, you only need to design
|
||||
a new sleeve part. You can re-use the `front` and `back` parts of your short-sleeved T-shirt pattern, as they did not change.
|
||||
|
||||
When developing a FreeSewing pattern, you will spend most of your time designing the individual parts.
|
||||
|
44
markdown/dev/guides/patterns/paths/en.md
Normal file
44
markdown/dev/guides/patterns/paths/en.md
Normal file
|
@ -0,0 +1,44 @@
|
|||
---
|
||||
title: Paths
|
||||
order: 20
|
||||
---
|
||||
|
||||
<Example
|
||||
part="docs_overview"
|
||||
caption="Paths are the lines and curves of your pattern"
|
||||
options={{focus: "Paths"}}
|
||||
/>
|
||||
|
||||
Paths are the lines and curves that make up your pattern.
|
||||
|
||||
They are made up of a set of drawing operations that together make up the path.
|
||||
FreeSewing supports the following types of drawing operations:
|
||||
|
||||
- The **move** operation moves our virtual pen but does not draw anything.
|
||||
- The **line** operation draws a straight line
|
||||
- The **curve** operation draws a [Bézier curve](/guides/overview/about/beziercurves/)
|
||||
- The **close** operation closes the path
|
||||
|
||||
To crucial thing to keep in mind is that, with the exception of the **move** operation,
|
||||
all drawing operations start from wherever you are currently on your virtual sheet of paper.
|
||||
|
||||
For example, you might expect the **line** operation to take a start- and endpoint.
|
||||
But in fact, it only takes and endpoint, and will draw a straight line from where our virtual pen
|
||||
currently is to said endpoint.
|
||||
|
||||
Because all but the **move** drawing operations are relative to their operation preceding it,
|
||||
**all Paths must start with a move operation**.
|
||||
|
||||
<Note>
|
||||
|
||||
Understanding that each drawing operation builds upon the next one is an important insight.
|
||||
|
||||
</Note>
|
||||
|
||||
<Tip>
|
||||
|
||||
Our example image (which, if you hadn't realized was created with FreeSewing) has a lot of
|
||||
paths in it. Each box, the arrows, the lines in the React logo, and so on.
|
||||
|
||||
</Tip>
|
||||
|
22
markdown/dev/guides/patterns/pattern/en.md
Normal file
22
markdown/dev/guides/patterns/pattern/en.md
Normal file
|
@ -0,0 +1,22 @@
|
|||
---
|
||||
title: Pattern
|
||||
order: 80
|
||||
---
|
||||
|
||||
<Example
|
||||
part="docs_overview"
|
||||
caption="The pattern you create will be a constructor for instances of your pattern"
|
||||
options={{focus: "Pattern"}}
|
||||
/>
|
||||
|
||||
Last but not least, we've arrived at the level of the pattern itself.
|
||||
The pattern is a container that holds all your parts, along with the configuration
|
||||
and the store.
|
||||
|
||||
In reality, your pattern will be a *constructor* that takes the user's settings as
|
||||
input and will return a new instance of your pattern.
|
||||
|
||||
That pattern instance will have a `draft()` method which will do the actual work of
|
||||
drafting the pattern. Once drafted, you can either call the `render()` method on
|
||||
the pattern instance, or pass it to [our React component](/packages/components) to render it in the browser.
|
||||
|
40
markdown/dev/guides/patterns/points/en.md
Normal file
40
markdown/dev/guides/patterns/points/en.md
Normal file
|
@ -0,0 +1,40 @@
|
|||
---
|
||||
title: Points
|
||||
order: 10
|
||||
---
|
||||
|
||||
<Example
|
||||
part="docs_overview"
|
||||
caption="Points store coordinates"
|
||||
options={{focus: "Points"}}
|
||||
/>
|
||||
|
||||
Developing a pattern with FreeSewing is similar to doing it on paper.
|
||||
But instead of using a pencil and paper, you'll be writing code.
|
||||
|
||||
Before we can draw any line, we need to know where it starts from, and where it ends.
|
||||
That's why we have **points**. They are the most basic building block of a
|
||||
FreeSewing pattern, and their role is to store coordinates.
|
||||
|
||||
Each point must have:
|
||||
|
||||
- A **X-coordinate**
|
||||
- A **Y-coordinate**
|
||||
|
||||
Together, these coordinates determine the location of the point in the 2-dimensional plane we're drawing on.
|
||||
|
||||
<Note>
|
||||
|
||||
Points are unlikely to confuse you. The only gotcha is [the
|
||||
coordinate system](/guides/prerequisites/coordinate-system/) which has a Y-axis that is inverted to what you
|
||||
may intuitively expect.
|
||||
|
||||
</Note>
|
||||
|
||||
<Tip>
|
||||
|
||||
Our example image (which, if you hadn't realized was created with FreeSewing) has a lot of
|
||||
points in it. The corners of the boxes, the location where the text goes, and so on.
|
||||
|
||||
</Tip>
|
||||
|
27
markdown/dev/guides/patterns/snippets/en.md
Normal file
27
markdown/dev/guides/patterns/snippets/en.md
Normal file
|
@ -0,0 +1,27 @@
|
|||
---
|
||||
title: Snippets
|
||||
order: 20
|
||||
---
|
||||
|
||||
<Example
|
||||
part="docs_overview"
|
||||
caption="Snippets are little embelishments that go on your pattern"
|
||||
options={{focus: "Snippets"}}
|
||||
/>
|
||||
|
||||
Snippets are little embellishments you can use and re-use on your pattern.
|
||||
They are typically used for things like logos or buttons.
|
||||
|
||||
Each snippet must have:
|
||||
|
||||
- An anchor point that determine where the snippet will be located
|
||||
- The name of the snippet to insert
|
||||
|
||||
Since our example image does not have any snippets in it, here's another example
|
||||
of a `button`, `buttonhole`, and `logo` snippet added to a FreeSewing pattern:
|
||||
|
||||
<Example
|
||||
part="snippet"
|
||||
caption="An example of the use of snippets"
|
||||
/>
|
||||
|
16
markdown/dev/guides/patterns/store/en.md
Normal file
16
markdown/dev/guides/patterns/store/en.md
Normal file
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
title: Store
|
||||
order: 70
|
||||
---
|
||||
|
||||
<Example
|
||||
part="docs_overview"
|
||||
caption="The store provides pattern-wide key/value storage"
|
||||
options={{focus: "Store"}}
|
||||
/>
|
||||
|
||||
The store provides key-value storage that is shared across your pattern.
|
||||
|
||||
If you have some information in one part that you want to make available
|
||||
outside that part (in another part) you can save it to the store.
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
title: Conditionally loading build-time plugins
|
||||
order: 30
|
||||
---
|
||||
|
||||
You can choose to load your build-time plugin conditionally based on run-time data.
|
||||
|
||||
To do so, you need to create a `condition` method that will determine whether the
|
||||
plugin will be loaded. This method receives the complete settings object and should
|
||||
return `true` if the plugin is to be loaded, and `false` if it should not be loaded.
|
||||
|
||||
```js
|
||||
const condition = settings => {
|
||||
if (settings) {
|
||||
// Remember, settings contains:
|
||||
// settings.options => The user's options
|
||||
// settings.measurements => The measurements
|
||||
return true // Load the plugin
|
||||
}
|
||||
else return false // Do not load the plugin
|
||||
}
|
||||
```
|
||||
You pass your plugin and condition method as a third parameter to the Design constructor
|
||||
with the `plugin` and `condition` keys respectively.
|
||||
|
||||
Let's look at a complete example to illustrate this:
|
||||
|
||||
```js
|
||||
import freesewing from '@freesewing/core'
|
||||
import plugins from '@freesewing/plugin-bundle'
|
||||
import myConditionalPlugin from '@freesewing/plugin-bust'
|
||||
|
||||
const myConditionalPluginCheck = (settings = false) =>
|
||||
settings &&
|
||||
settings.options &&
|
||||
settings.options.draftForHighBust &&
|
||||
settings.measurements.highBust
|
||||
? true
|
||||
: false
|
||||
|
||||
const Pattern = new freesewing.Design(
|
||||
config,
|
||||
plugins,
|
||||
{
|
||||
plugin: myConditionalPlugin,
|
||||
condition: myConditionalPluginCheck
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
Our condition method will return `true` only if the following conditions are met:
|
||||
|
||||
- A `settings` object is passed into the method
|
||||
- `settings.options` is _truthy_
|
||||
- `settings.options.draftForHighBust` is _truthy_
|
||||
- `settings.options.measurements.highBust` is _truthy_
|
||||
|
||||
This is a real-world example from our Teagan pattern. A t-shirt pattern that can be
|
||||
drafted to the high bust (rather than the full chest circumference) if the user
|
||||
choses so.
|
||||
|
||||
But that feat is handled auto-magically by `plugin-bust` which is a build-time plugin.
|
||||
So whether to load this plugin or not hinges on the user settings, which is why we
|
||||
load this plugin conditionally.
|
||||
|
25
markdown/dev/guides/plugins/en.md
Normal file
25
markdown/dev/guides/plugins/en.md
Normal file
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: Plugin guide
|
||||
order: 400
|
||||
icons:
|
||||
- logo
|
||||
- plugin
|
||||
for: developers
|
||||
about: |
|
||||
This guide shows you everything you need to know to understand plugins in FreeSewing, and create your own.
|
||||
goals:
|
||||
- Know about build-time plugins vs run-time plugins
|
||||
- Understanding plugin structure
|
||||
- Hooks and how to use them
|
||||
- Using hooks without a plugin
|
||||
- Using macros
|
||||
---
|
||||
|
||||
Plugins allow you to extend FreeSewing.
|
||||
|
||||
We have [a list of available plugins](/reference/plugins/), but
|
||||
if you can't find what you're looking for, you can write your own plugin.
|
||||
|
||||
We'll cover the following topics in this guide:
|
||||
|
||||
<ReadMore list />
|
21
markdown/dev/guides/plugins/hooks/en.md
Normal file
21
markdown/dev/guides/plugins/hooks/en.md
Normal file
|
@ -0,0 +1,21 @@
|
|||
---
|
||||
title: Hooks
|
||||
order: 60
|
||||
---
|
||||
|
||||
A **hook** is a lifecycle event. The available hooks are:
|
||||
|
||||
- [preRender](/reference/hooks/prerender/): Called at the start of [`Pattern.render()`](/reference/api/pattern#render)
|
||||
- [postRender](/reference/hooks/postrender/): Called at the end of [`Pattern.render()`](/reference/api/pattern#render)
|
||||
- [insertText](/reference/hooks/inserttext/): Called when inserting text
|
||||
- [preDraft](/reference/hooks/predraft/): Called at the start of [`Pattern.draft()`](/reference/api/pattern#draft)
|
||||
- [postDraft](/reference/hooks/postdraft/): Called at the end of [`Pattern.draft()`](/reference/api/pattern#draft)
|
||||
- [preSample](/reference/hooks/presample/): Called at the start of [`Pattern.sample()`](/reference/api/pattern#sample)
|
||||
- [postSample](/reference/hooks/postsample/): Called at the end of [`Pattern.sample()`](/reference/api/pattern#sample)
|
||||
|
||||
You can register a method for a hook. When the hook is triggered, your method will be
|
||||
called. It will receive two parameters:
|
||||
|
||||
- An object relevant to the hook. See the [hooks API reference](/reference/hooks/) for details.
|
||||
- Data passed when the hook was registered (optional)
|
||||
|
27
markdown/dev/guides/plugins/loading-build-time-plugins/en.md
Normal file
27
markdown/dev/guides/plugins/loading-build-time-plugins/en.md
Normal file
|
@ -0,0 +1,27 @@
|
|||
---
|
||||
title: Loading build-time plugins
|
||||
order: 20
|
||||
---
|
||||
|
||||
Build-time plugins are loaded at build time, by passing them to
|
||||
the [`freesewing.Design`](/reference/api/#design) constructor:
|
||||
|
||||
```js
|
||||
import freesewing from "@freesewing/core"
|
||||
import plugins from "@freesewing/plugin-bundle"
|
||||
import config from "../config"
|
||||
|
||||
const Pattern = new freesewing.Design(config, plugins)
|
||||
```
|
||||
|
||||
If you have multiple plugins to load, you can pass them as an array:
|
||||
|
||||
```js
|
||||
import freesewing from "@freesewing/core"
|
||||
import plugins from "@freesewing/plugin-bundle"
|
||||
import gorePlugin from "@freesewing/plugin-gore"
|
||||
import config from "../config"
|
||||
|
||||
const Pattern = new freesewing.Design(config, [plugins, gorePlugin] )
|
||||
```
|
||||
|
26
markdown/dev/guides/plugins/loading-run-time-plugins/en.md
Normal file
26
markdown/dev/guides/plugins/loading-run-time-plugins/en.md
Normal file
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
title: Loading run-time plugins
|
||||
order: 40
|
||||
---
|
||||
|
||||
Run-time plugin are loaded at run time, by passing them to the `use` method of
|
||||
an instatiated pattern. That method is chainable, so if you have multiple plugins
|
||||
you can just chain them together:
|
||||
|
||||
```js
|
||||
import Aaron from "@freesewing/aaron";
|
||||
import theme from "@freesewing/plugin-theme";
|
||||
import i18n from "@freesewing/plugin-i18n";
|
||||
|
||||
const myAaron = new Aaron()
|
||||
.use(theme)
|
||||
.use(i18n)
|
||||
```
|
||||
|
||||
<Tip>
|
||||
|
||||
Plugins that use only hooks are typically run-time plugins
|
||||
|
||||
</Tip>
|
||||
|
||||
|
64
markdown/dev/guides/plugins/macros/en.md
Normal file
64
markdown/dev/guides/plugins/macros/en.md
Normal file
|
@ -0,0 +1,64 @@
|
|||
---
|
||||
title: Macros
|
||||
order: 90
|
||||
---
|
||||
|
||||
Plugin structure for macros is similar, with a few changes:
|
||||
|
||||
- Rather than the hook name, you provide the macro name (that you choose yourself)
|
||||
- The context (`this`) of a macro method is **always** a [Part](/reference/api/part) object.
|
||||
|
||||
Apart from these, the structure is very similar:
|
||||
|
||||
```js
|
||||
import {name, version} from '../package.json';
|
||||
|
||||
export default {
|
||||
name,
|
||||
version,
|
||||
macros: {
|
||||
box: function(so) {
|
||||
this.points.boxTopLeft = so.anchor;
|
||||
this.points.boxTopRight = so.anchor.shift(0, so.size);
|
||||
this.points.boxBottomRight = this.points.boxTopRight.shift(-90, so.size);
|
||||
this.points.boxBottomLeft = new this.Point(so.anchor.x, this.points.boxBottomRight.y);
|
||||
|
||||
this.paths.box = new this.Path()
|
||||
.move(this.points.boxTopLeft)
|
||||
.line(this.points.boxTopRight)
|
||||
.line(this.points.boxBottomRight)
|
||||
.line(this.points.boxBottomLeft)
|
||||
.close()
|
||||
.attr('class', 'box');
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Did you figure out what this plugin does?
|
||||
It provides a `box` macro that draws a box on our pattern in a given location with a give size.
|
||||
|
||||
We can use it like this:
|
||||
|
||||
```js
|
||||
points.boxAnchor = new Point(100, 100);
|
||||
macro('box', {
|
||||
anchor: points.boxAnchor
|
||||
size: 25
|
||||
});
|
||||
```
|
||||
|
||||
Obviously, you can expect to learn how to call a macro in its documentation,
|
||||
rather than have to comb through its code.
|
||||
|
||||
<Note>
|
||||
|
||||
###### Macros take only 1 argument
|
||||
|
||||
When writing a macro, keep in mind that all information that needs to be passed
|
||||
to a macro needs to be contained in a single argument.
|
||||
|
||||
Typically, you use a single plain object to configure the macro.
|
||||
|
||||
</Note>
|
||||
|
25
markdown/dev/guides/plugins/plugin-structure/en.md
Normal file
25
markdown/dev/guides/plugins/plugin-structure/en.md
Normal file
|
@ -0,0 +1,25 @@
|
|||
---
|
||||
title: Plugin structure
|
||||
order: 50
|
||||
---
|
||||
|
||||
Plugins can do two things:
|
||||
|
||||
- They can use hooks
|
||||
- They can provide macros
|
||||
|
||||
Your plugin should export an object with the following structure:
|
||||
|
||||
```js
|
||||
{
|
||||
name: 'myPlugin',
|
||||
version: '1.0.0',
|
||||
hooks: {},
|
||||
macros: {}
|
||||
};
|
||||
```
|
||||
|
||||
The `name` and `version` attributes are self-explanatory.
|
||||
The [hooks](/guides/plugins/hooks/) and [macros](/guides/plugins/macros/) sections
|
||||
explain the `hooks` and `macros` properties.
|
||||
|
38
markdown/dev/guides/plugins/types-of-plugins/en.md
Normal file
38
markdown/dev/guides/plugins/types-of-plugins/en.md
Normal file
|
@ -0,0 +1,38 @@
|
|||
---
|
||||
title: Types of plugins
|
||||
order: 10
|
||||
---
|
||||
|
||||
Plugins come in two flavours:
|
||||
|
||||
- [Build-time plugins](#build-time-plugins)
|
||||
- [Run-time plugins](#run-time-plugins)
|
||||
|
||||
When writing a plugin, ask yourself whether it's a run-time or a build-time plugin.
|
||||
And if the answer is both, please split them into two plugins.
|
||||
|
||||
## Build-time plugins
|
||||
|
||||
A plugin is a build-time plugin if it is required by the pattern at build-time.
|
||||
In other words, the plugin is a dependency for the pattern, and if it's missing
|
||||
the pattern won't load.
|
||||
|
||||
<Tip>
|
||||
|
||||
Our [plugin bundle](/reference/plugins/bundle/) bundles build-time plugins that are used in many patterns.
|
||||
|
||||
</Tip>
|
||||
|
||||
<Note>Plugins that provide a macro are typically build-time plugins</Note>
|
||||
|
||||
|
||||
## Run-time plugins
|
||||
|
||||
A plugin is a run-time plugin if it can be added after instantiating your pattern.
|
||||
Think of it as a plugin to be used in the front-end.
|
||||
|
||||
Run-time plugins are not a dependecy of the pattern. They just _add something_ to it.
|
||||
|
||||
Our [theme plugin](/reference/plugins/theme/) is a good example of a run-time plugin.
|
||||
If it's missing, your pattern will still work, it just won't look pretty.
|
||||
|
26
markdown/dev/guides/plugins/using-hooks-more-than-once/en.md
Normal file
26
markdown/dev/guides/plugins/using-hooks-more-than-once/en.md
Normal file
|
@ -0,0 +1,26 @@
|
|||
---
|
||||
title: Using hooks more than once
|
||||
order: 80
|
||||
---
|
||||
|
||||
What if you want to attach more than one method to a hook?
|
||||
You could spread them over seperate plugins, but there's a better way.
|
||||
|
||||
Rather than assigning a method to your hook, assign an array of methods like this:
|
||||
|
||||
```js
|
||||
import myCoolMethod from './method-a';
|
||||
import myEvenCoolerMethod from './method-b';
|
||||
import {name, version} from '../package.json';
|
||||
|
||||
export default {
|
||||
name,
|
||||
version,
|
||||
hooks: {
|
||||
preRender: [
|
||||
myCoolMethod,
|
||||
myEvenCoolerMethod
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
20
markdown/dev/guides/plugins/using-hooks-without-plugin/en.md
Normal file
20
markdown/dev/guides/plugins/using-hooks-without-plugin/en.md
Normal file
|
@ -0,0 +1,20 @@
|
|||
---
|
||||
title: Using hooks without a plugin
|
||||
order: 85
|
||||
---
|
||||
|
||||
You can attach a method to a hook at run-time without the need for a plugin
|
||||
using the [Pattern.on()](/reference/api/pattern/on) method.
|
||||
|
||||
The method takes the hook name as its first argument, and the hook method as its second.
|
||||
|
||||
Below is an example:
|
||||
|
||||
```js
|
||||
pattern.on('preRender', function(svg) {
|
||||
svg.style += "svg { background: yellow;}";
|
||||
});
|
||||
```
|
||||
|
||||
Congratulations, you've just made your pattern yellow.
|
||||
|
59
markdown/dev/guides/plugins/using-hooks/en.md
Normal file
59
markdown/dev/guides/plugins/using-hooks/en.md
Normal file
|
@ -0,0 +1,59 @@
|
|||
---
|
||||
title: Using hooks
|
||||
order: 70
|
||||
---
|
||||
|
||||
For each hook, your plugin should provide a method that takes the relevant data
|
||||
as its first argument. If data was passed when the hook was loaded, you will receive
|
||||
that as the second object.
|
||||
|
||||
Remember that:
|
||||
|
||||
- The `insertText` hook will receive a locale and string and you should return a string.
|
||||
- All other hooks receive an object. You don't need to return anything, but rather modify the object you receive.
|
||||
|
||||
Let's look at an example:
|
||||
|
||||
```js
|
||||
import myStyle from './style';
|
||||
import myDefs from './defs';
|
||||
import {name, version} from '../package.json';
|
||||
|
||||
export default {
|
||||
name,
|
||||
version,
|
||||
hooks: {
|
||||
preRender: function(svg) {
|
||||
if (svg.attributes.get("freesewing:plugin-"+name) === false) {
|
||||
svg.style += myStyle;
|
||||
svg.defs += myDefs;
|
||||
svg.attributes.add("freesewing:plugin-"+name, version);
|
||||
}
|
||||
},
|
||||
insertText: function(text) {
|
||||
return text.toUpperCase();
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This is a complete plugin, ready to be published on NPM. It uses two hooks:
|
||||
|
||||
- `preRender` : We add some style and defs to our SVG
|
||||
- `insertText` : We transfer all text to UPPERCASE
|
||||
|
||||
<Note>
|
||||
|
||||
###### Note that we avoid running our hook twice
|
||||
|
||||
As you can see, the last thing we do in the `preRender` hook is set an attribute on
|
||||
the SVG tag with the name and version of our plugin.
|
||||
|
||||
We check for this attribute when the `preRender` hook runs, thereby avoiding that
|
||||
our styles and defs will be added twice.
|
||||
|
||||
It is good practice to wrap you hook methods in a call like this, because you have
|
||||
no guarantee the user won't render your pattern more than once.
|
||||
|
||||
</Note>
|
||||
|
BIN
markdown/dev/guides/prerequisites/bezier-curves/bezier.gif
Normal file
BIN
markdown/dev/guides/prerequisites/bezier-curves/bezier.gif
Normal file
Binary file not shown.
After Width: | Height: | Size: 211 KiB |
35
markdown/dev/guides/prerequisites/bezier-curves/en.md
Normal file
35
markdown/dev/guides/prerequisites/bezier-curves/en.md
Normal file
|
@ -0,0 +1,35 @@
|
|||
---
|
||||
title: Bézier curves
|
||||
order: 50
|
||||
---
|
||||
|
||||
While lines on computers are easy to store with a start and end point,
|
||||
curves require more information.
|
||||
|
||||
In FreeSewing — as in SVG and countless of other applications —
|
||||
curves are stored as Bézier curves. They have:
|
||||
|
||||
- A start point
|
||||
- A first control point that’s linked to the start point
|
||||
- A second control point that’s linked to the end point
|
||||
- An end point
|
||||
|
||||
<Example settings={{complete: false}} part="path_curve" caption="An example of a Bézier curve drawn by the Path.curve() method" />
|
||||
|
||||
Bézier curves and their *handles* or *control points* are surprisingly intuitive.
|
||||
The following illustration does a great job at explaining how they are constructed:
|
||||
|
||||

|
||||
|
||||
<Note>
|
||||
|
||||
###### More on Bézier curves
|
||||
|
||||
Wikipedia has a good [introduction to Bézier curves](https://pomax.github.io/bezierinfo/).
|
||||
For a deep-dive into the subject, check out [A Primer on Bézier Curves](https://pomax.github.io/bezierinfo/) by Pomax.
|
||||
|
||||
Note that you don't need understand the mathematics behind Bézier Curves.
|
||||
As long as you intuitively *get* how the control points influence the curve, you're good to go.
|
||||
|
||||
</Note>
|
||||
|
24
markdown/dev/guides/prerequisites/coordinate-system/en.md
Normal file
24
markdown/dev/guides/prerequisites/coordinate-system/en.md
Normal file
|
@ -0,0 +1,24 @@
|
|||
---
|
||||
title: Coordinate system
|
||||
order: 30
|
||||
---
|
||||
|
||||
In FreeSewing -- and in SVG -- coordinates are like text in a book.
|
||||
You start at the top on the left side, and going to the right
|
||||
and downwards means going ahead.
|
||||
|
||||
<Example part="docs_coords" caption="The SVG coordinate system" />
|
||||
|
||||
Which means that on the X-axis, `20` is further to the right than `10`.
|
||||
Likewise, on the Y-axis, `50` is lower than `20`.
|
||||
|
||||
<Note>
|
||||
|
||||
The Y-axis is inverted in many drawing programs, with the origin
|
||||
`(0,0)` being the lower left corner, rather than the upper left corner.
|
||||
|
||||
This is a common point of confusion so keep in mind that the Y-axis may
|
||||
not behave as you would have intuitively expected.
|
||||
|
||||
</Note>
|
||||
|
39
markdown/dev/guides/prerequisites/en.md
Normal file
39
markdown/dev/guides/prerequisites/en.md
Normal file
|
@ -0,0 +1,39 @@
|
|||
---
|
||||
title: Prerequisites
|
||||
order: 100
|
||||
for: developers
|
||||
icons:
|
||||
- start
|
||||
- pattern
|
||||
about: |
|
||||
A guide to go over a few things you should know when you start working with our core library
|
||||
goals:
|
||||
- Understand that FreeSewing provides parametric pattern design
|
||||
- Understand that FreeSewing uses SVG
|
||||
- Understand the coordinate system
|
||||
- Learn that we use millimeter internally
|
||||
- Learn about Bézier curves
|
||||
---
|
||||
|
||||
Here's a few things that, once you get them, will make it easier to understand
|
||||
what FreeSewing is doing, and how it's doing it.
|
||||
|
||||
We'll cover the following topics:
|
||||
|
||||
<ReadMore list />
|
||||
|
||||
<Note>
|
||||
|
||||
##### There's no need to know everything
|
||||
|
||||
FreeSewing sits at the intersection of the world of makers and developers.
|
||||
If your background is in development, you will need no explaining what SVG is, but might not
|
||||
know much about designing sewing patterns.
|
||||
If on the other hand your background is in sewing or pattern design, you might wonder what
|
||||
the heck Node JS is and why you should care.
|
||||
|
||||
Few people straddle both worlds, so as you start using FreeSewing, chances are
|
||||
you'll learn a few new things along the way.
|
||||
|
||||
</Note>
|
||||
|
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
title: Parametric pattern design
|
||||
order: 10
|
||||
---
|
||||
|
||||
The FreeSewing core library is a toolbox for **parametric pattern design**;
|
||||
Using parameters or variables to manipulate the outcome of a given design.
|
||||
|
||||
In sewing patterns, the parameters are what is provided by the user:
|
||||
Their measurements and options that they have selected.
|
||||
|
||||
<Note>
|
||||
|
||||
##### No more grading, ever
|
||||
|
||||
When drafting or designing patterns or garments, it is common practice to start
|
||||
with a fit model (or dress form).
|
||||
The measurements of the fit model are used as input in the initial design.
|
||||
|
||||
Adapting the pattern for a different model is a tedious task,
|
||||
which is why patterns are graded up and down to cover different sizes.
|
||||
|
||||
But in a parametric sewing pattern, adapting to different sizes or models *just works*.
|
||||
|
||||
</Note>
|
||||
|
||||
FreeSewing patterns are implemented **as code**, which has a lot of advantages.
|
||||
|
||||
It allows for patterns that adapt to your measurements or preferences,
|
||||
fine-grained version control, seamless collaboration, and using existing
|
||||
patterns as a starting point for you own, to name but a few.
|
||||
|
||||
That being said, you don't have to be a code monkey to use FreeSewing.
|
||||
|
16
markdown/dev/guides/prerequisites/svg/en.md
Normal file
16
markdown/dev/guides/prerequisites/svg/en.md
Normal file
|
@ -0,0 +1,16 @@
|
|||
---
|
||||
title: SVG
|
||||
order: 20
|
||||
---
|
||||
|
||||
Patterns are rendered as SVG — short
|
||||
for [Scalable Vector Graphics](https://en.wikipedia.org/wiki/Scalable_Vector_Graphics) —
|
||||
an XML-based vector image format and an open standard.
|
||||
|
||||
While you don’t need to be an SVG expert, a basic understanding of the format
|
||||
will greatly help you to understand FreeSewing.
|
||||
|
||||
For example, the coordinate system and the way paths
|
||||
are structured are all related to the SVG drawing system, which is closely related
|
||||
to other 2D drawing technologies such as PostScript or PDF.
|
||||
|
13
markdown/dev/guides/prerequisites/units/en.md
Normal file
13
markdown/dev/guides/prerequisites/units/en.md
Normal file
|
@ -0,0 +1,13 @@
|
|||
---
|
||||
title: Units
|
||||
order: 40
|
||||
---
|
||||
|
||||
Internally, freesewing uses millimeter.
|
||||
When you write `1`, that’s one mm. When you write `7.8`, that’s 7.8mm.
|
||||
|
||||
While you can use cm or inch on the FreeSewing website, that is merely a layer of
|
||||
abstration on top of the internal units, which are always mm.
|
||||
|
||||
So as a pattern designer, you will work with mm.
|
||||
|
Loading…
Add table
Add a link
Reference in a new issue