I'd love to try this out, but there's no README with instructions about how to build and run it :)

Point.on and Point.translate should be filters to.
This requires:

• adapting "on" and "translate" so that a Point is built first if the params aren't already an instance
• test

Issue can be viewed for the /x (serif bottom-right)

this requires renaming the .next property to .$next

See https://docs.google.com/document/d/1OvqeGgvgn9zaCE0kq0jm_8QZfcDpBK1xTThD45nL5b4/

• All constructors and instance methods
• the behavior of segment.$render
• the moveSegmentEnd that happens at the end of processSubcomponent
• C+ / C- commands

The from and args properties are $parsed and should be executed before being used

C'est aussi une fonctionnalité à ta portée Yannick, qu'on pourra faire mercredi si ça te tente.

Rules:

• "replace" subcomponents shouldn't do a "from self[n] {{ 'start' }}" but rather a "from self[n-1] {{ 'end' }}"
• "replace" subcomponents shouldn't do a "to self[n] {{ 'end' }}" but rather a "to self[n+1] {{ 'start' }}"
• "replace" subcomponents should be listed in the order they are attached to the outline. Otherwise we can't spot a subcomponent being ignored because of the previous on
• a subcomponent must reach its "to" coordinates (well, not necessarily)
• a subcomponent cannot replace the M and Z of its parent component
• you can't use "S" or "T" segment in an inverted component. The inversion mechanism isn't yet able to deal with it

Les sliders natifs sont pratiques parce qu'ils marchent sans qu'on ai rien besoin de faire mais ils sont moches.
Il faut créer nos propres sliders à l'aide des directives Angular.
C'est une amélioration à ta portée Yannick, si tu es intéressé.

We now have a "segment-endpoint" directive in "directives/endpoint.js" which creates individual blue squares for each segment's endpoint in the glyph.
It could be useful to display the position of the related endpoint when a blue square is hovered.

This is something Yannick could do too.

• [email protected]
• [email protected]
• Matthieu
• [email protected]

When you add serifs on \A, sliders work but on mouseRelease it is getting weird
Same kind of issue with \f but it is seems to be the opposite behaviour (ok on release, weird while sliding)

Both of cases, it seems the combinaison width + serif is the the origin of this issue

I've written my thoughts here: https://docs.google.com/document/d/17JOOZV6UGGNTmJaDuAmQSf-3t-2wqHaC1UwA4B_Lz5I/edit?usp=sharing

Font-wide inputs (what we currently have), Glyph-specific inputs and component-specific inputs

serif-bottom-right.txt

// row 3 : the first parameter should be:
// {{ serifWidth }}
// not:
// {{ serifWidth - serifHeight * serifCurve }}
// but it allows to make some "fleur de Lys" shape : )
// Should we keep this ? (in a experimental mode?)

Generating binary font files such as .otf is hard! It's not like anything we've done so far. Here is what we know:

• It should be possible to generate "svg opentype" fonts (firefox only) using the js files of this project: https://github.com/rocallahan/svg-opentype-workshop The only problem is that the CmapTable.js file looks incomplete, and it's required to generate a font without using an existing one that already has a complete cmap.
• fontforge can be used as a command-line tool to generate .otf and other binary formats files from svg sources. The challenge is to compile it using emscripten in order to do that right in the browser. The command lines "API" (see http://fontforge.org/cliargs.html ) uses scripts that can be written either in python or in a specific language (see http://fontforge.org/scripting-tutorial.html ).
• It should be relatively easy to generate ttx with cff outlines files by studying the documentation and some example files, see https://github.com/behdad/fonttools Hinting looks slightly more complex. But .ttx isn't very useful: it has been replaced by UFO, and .svg fonts can also be converted to .otf using fontforge.
• There's a JS lib able to read outlines from OpenType fonts with TrueType outlines: https://github.com/nodebox/opentype.js There's also a cff branch that should soon add support for PostScript outlines (the only ones interesting to us). We contacted him via Twitter and he said font creation was on the roadmap. This looks like a very promising long-term solution and we should do what we can to help it happen.

We need a domain name: one that is available, easy to remember and that would allow us to be at the top of the search results on Google.

ou "Pourquoi on ne trace pas le glyphe uniquement à partir de valeurs de sliders ?".

1. Parce que pour les glyphes qui ont plusieurs courbes complexes, comme "a", "g", "s", "B" c'est crucial d'avoir une référence (???)
2. Parce qu'à terme on devra être capable d'importer des glyphes dans le logiciel pour les rendre paramètrable.

See https://docs.google.com/document/d/1saOSIPBw5MwS7zDesvQ8gz5APWzUmeeYIscorhqn_Xo/edit?usp=sharing