-
Notifications
You must be signed in to change notification settings - Fork 3
/
knitout.html
626 lines (556 loc) · 23.4 KB
/
knitout.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>The "Knitout" (.k) File Format</title>
<style>
* {
/*outline: 1px solid red;*/
}
body {
padding: 0% 8%;
margin: 2em auto;
max-width: 50em;
}
code {
background: #efefef;
padding: 1px 2px;
border-radius: 2px;
border: 1px solid #888;
}
pre {
outline: 1px solid #888;
background: #efefef;
display: block;
margin: 0.5em 2em ;
padding: 0.5em 0.5em 0.5em 0.5em;
overflow: scroll;
}
pre > code {
background:none;
padding:0;
border-radius:0;
border:none;
}
table {
border-spacing: 0px;
width:100%;
margin: 2em 0.5em;
}
tr {
width: 100%;
}
td {
padding: 0.5em 1.5em;
border-top: 1px solid #888;
/*margin: 12px;*/
}
/*@media (max-width: 700px) {
body {
padding: 2em;
}
}*/
code op {
color: #d33682;
}
code par {
color: #268bd2;
}
code comment {
color: #444;
}
code clarification {
color: #859900;
}
</style>
</head>
<body>
<h1>The "Knitout" (.k) File Format v0.6</h1>
<p>
Knitout (.k) is a file format that can represent low-level knitting machine instructions in a machine-independent way.
The format is easy to read and write from code, and reasonably human-readable.
It is hoped that knitout can serve as an output file format for design tools, and an input file format for knitting machines and simulators.
</p>
<p>Knitout has no relation to the custom sock vendor of the same name.</p>
<p>
The remainder of this document describes the format itself, the design principles behind the format, and ends with some comments about particular decisions.
</p>
<h2>History</h2>
<ol>
<li>Version 0.6 -- carriers header and naming requirements. (Jim McCann)</li>
<li>Version 0.5.4 -- clarify kickbacks, clarify wording in other sections, adjust CSS style. (Jim McCann)</li>
<li>Version 0.5.3 -- clarify that carrier names are strings. (Jim McCann)</li>
<li>Version 0.5.2 -- clarify that ;;Carriers header is required. (Jim McCann)</li>
<li>Version 0.5.1 -- add ;!source: comments, fix typo in example. (Jim McCann)</li>
<li>Version 0.5 -- racking sign swapped. (Jim McCann)</li>
<li>Version 0.4 -- total re-write, placed in the public domain. (Jim McCann)</li>
</ol>
<h2>Contributing</h2>
<p>
Please do not hesitate to get in touch with ideas, comments, or improvements for the specification.
Without your input, knitout cannot grow into a useful specification.
</p>
<p>
To provide feedback, use the <a href="https://github.com/textiles-lab/knitout/issues">Issues</a> page.
You may also contact the authors directly using the <a href="mailto:knitout-feedback@cs.cmu.edu">knitout-feedback@cs.cmu.edu</a> e-mail alias.
</p>
<h2>File Format</h2>
<p>
Knitout is a straightforward list of knitting instructions to execute to create a knit object, along with a header describing specific information about the machine it is designed to run on.
</p>
<h3>Filenames, Encoding, Line Endings</h3>
<p>
Knitout files are named with the <code>.k</code> extension.
</p>
<p>
Knitout files contain UTF8-encoded text.
</p>
<p>
Knitout is line-oriented, and knitout files use the LF character to terminate lines (<code>'\n'</code>, U+000A).
</p>
<p>
Programs that write knitout format files should name then with a <code>.k</code> extension,
encode them as UTF8,
use only the "space" (U+0020) and "tab" (U+0009) characters for whitespace,
and use the LF character (U+000A) as a line ending.
Programs that read knitout files should support files produced in this way, and may support other extensions, encodings, whitespace characters, and line endings (though they should warn that the file is not standard).
</p>
<h3>Magic String</h3>
<pre><code>;!knitout-2
</code></pre>
<p>
Knitout files begin with a magic string <code>;!knitout-VERSION</code> followed by a linefeed.
<code>VERSION</code> is an integer indicating the current version.
The version number will be incremented when features are moved from extensions into the main language.
</p>
<p>
Programs that write knitout should always use the latest version of which they are aware.
Programs that read knitout must accept any version number, but should warn if the version is later than one they support.
</p>
<h3>Comment Header</h3>
<pre><code><comment>;;Machine: SWG091N2
;;Gauge: 15
;;Yarn-5: 50-50 Rust
;;Carriers: 1 2 3 4 5 6 7 8 9 10
;;Position: Right</comment>
</code></pre>
<p>
After the magic string, knitout files contain a series of special comments (starting with <code>;;</code>) known as the "comment header."
These comments give additional information about the machine intended to execute the knitout code in the file.
</p>
<p>
Each line in the comment header begins with the string "<code>;;</code>", followed by the header name, followed by the string "<code>: </code>", followed by the header value.
</p>
<h4>Required Headers</h4>
<p>
The following headers are required because their values influence the topology of the finished knit item:
</p>
<table>
<tr>
<th>Name</th><th>Value</th>
<th>Meaning</th>
</tr>
<tr>
<td>Carriers</td><td>C1 C2,C3;C4 C5 ...</td>
<td>Carrier layout.
A space-separated list of rail definitions (front-to-back).
For machines with one carrier per rail, each rail definition is a single carrier name.
For machines that support multiple carriers on a rail, each rail definition is a comma-separated list of names in left-to-right order with a semicolon dividing the left-side and right-side carriers (e.g., <code>L1,L2,L3;R1,R2</code>).
Knitout backends may be more strict in carrier header requirements (including requiring an exact string for the carriers header).
</td>
</tr>
</table>
<p>
Tools that write knitout <em>must</em> include a <code>Carriers</code> header;
tools that read knitout must warn if a <code>Carriers</code> header is missing, though they may also continue to process the file.
</p>
<h4>Other Headers</h4>
<p>
The following headers are optional:
</p>
<table>
<tr>
<th>Name</th><th>Value</th>
<th>Meaning</th>
</tr>
<tr>
<td>Machine</td><td>M</td>
<td>the model name M of the target machine</td>
</tr>
<tr>
<td>Gauge</td><td>G</td>
<td>the gauge G (in needles/inch) of the target machine</td>
</tr>
<tr>
<td>Yarn-C</td><td>type color</td>
<td>yarn to load in carrier C</td>
</tr>
<tr>
<td>Position</td><td>P</td>
<td>where to place the operations on the needle bed; Left, Center, Right, and Keep are standard values</td>
</tr>
<tr>
<td>X-*</td><td>*</td>
<td>extension header</td>
</tr>
</table>
<h3>Operations</h3>
<pre><code><op>knit</op> <par>+ f14 A B</par> <comment>;knit together</comment>
<op>knit</op> <par>+ f15 A B</par>
<op>knit</op> <par>+ f16 A B</par>
<comment>;note to self: maybe put in a tuck here?</comment>
<op>knit</op> <par>+ f17 A</par>
<op>knit</op> <par>+ f18 A</par>
<op>knit</op> <par>+ f19 A</par>
</code></pre>
<p>
After the comment header, all lines in the file contain an (optional) operation followed by an (optional) comment.
The operation is everything up to the first ';' character, the comment is everything after:
</p>
<pre><code><op>knit</op> <par>+ f14 A B</par> <comment>;knit together</comment>
<clarification>^--operation--^ ^--comment--^</clarification>
<op>knit</op> <par>+ f14 A B</par>
<clarification>^--operation-^ (no comment)</clarification>
<comment>;note to self</comment>
<clarification>^-comment--^ (no operation)</clarification>
</code></pre>
<p>
The operation is a whitespace-separated list of tokens.
Leading and trailing whitespace may appear and is ignored.
The first token is the opcode, and the remaining tokens [if any] are the parameters.
</p>
<table>
<tr><th colspan="3">Opcodes</th></tr>
<tr>
<th>Opcode</th>
<th>Parameters</th>
<th>Description</th>
</tr>
<tr>
<td>in</td>
<td>CS</td>
<td>Indicate that the given carrier set should be brought into action from the yarn grippers when next used.</td>
</tr>
<tr>
<td>inhook</td>
<td>CS</td>
<td>
Indicate that the given carrier set should be brought into action using the yarn inserting hook when next used.
The inserting hook will be parked just before the first stitch made with the carriers.
</td>
</tr>
<tr>
<td>releasehook</td>
<td>CS</td>
<td>Release the yarns currently held in the yarn inserting hook.
Must be proceeded by a call to inhook with the same carrier set and at least one knitting operation.</td>
</tr>
<tr>
<td>out</td>
<td>CS</td>
<td>Bring a set of carriers out of action by directly moving into the grippers.</td>
</tr>
<tr>
<td>outhook</td>
<td>CS</td>
<td>Bring a set of carriers out of action, using a yarn inserting hook to bring their yarns to the grippers.</td>
</tr>
<tr>
<td>stitch</td>
<td>L T</td>
<td>Before forming a loop, pull needle by L machine units. After forming a loop, pull needle by T machine units.</td>
</tr>
<tr>
<td>rack</td>
<td>R</td>
<td>Set the offset of the back bed relative to the front bed.</td>
</tr>
<tr>
<td>knit</td>
<td>D N CS</td>
<td>Pull a loop formed in direction D by the yarns in carriers CS through the loops on needle N, dropping them in the process.
Knitting with an empty carrier set will drop.</td>
</tr>
<tr>
<td>tuck</td>
<td>D N CS</td>
<td>Add a loop formed in direction D by the yarns held by carriers in CS to those already on needle N.
Tucking with an empty carrier set will pull on the stitches without doing anything else (an "a-miss").</td>
</tr>
<tr>
<td>split</td>
<td>D N N2 CS</td>
<td>Pull a loop formed in direction D by the yarns in carriers CS through the loops on needle N, transferring the old loops to opposite-bed needle N2 in the process.
Splitting with an empty carrier set will transfer.</td>
</tr>
<tr>
<td>drop</td>
<td>N</td>
<td>Synonym for "knit + N".</td>
</tr>
<tr>
<td>amiss</td>
<td>N</td>
<td>Synonym for "tuck + N".</td>
</tr>
<tr>
<td>xfer</td>
<td>N N2</td>
<td>Synonym for "split + N N2".</td>
</tr>
<tr>
<td>miss</td>
<td>D N CS</td>
<td>Move the specified carriers as if they had just formed a loop in direction D at location N.
(Not generally needed, used when performing explicit kickbacks or purposeful yarn capture.)</td>
</tr>
<tr>
<td>pause</td>
<td></td>
<td>Pause the machine until the operator enters a command to continue.
(Not generally needed, but can be useful when, e.g., having the operator change yarns.)</td>
</tr>
<tr>
<td>x-*</td>
<td>*</td>
<td>Extension opcode.
</td>
</tr>
</table>
<table>
<tr><th colspan="4">Parameters</th></tr>
<tr><th>Symbol</th><th>Examples</th><th>Name</th><th>Description</th></tr>
<tr><td>D</td><td>"+", "-"</td>
<td>Direction</td>
<td>A direction on the machine bed. "+" indicates increasing needle number (typically, rightward movement), "-" indicates decreasing needle number (typically, leftward movement).</td>
</tr>
<tr><td>N</td><td>"f1", "b-2", "fs3"</td>
<td>Needle</td>
<td>A machine needle. Consists of a location prefix followed by a number. On a V-bed machine, needles are prefixed "f" and "b" for front and back. A V-bed with slide needles adds "fs" and "bs" for front and back sliders.</td>
</tr>
<tr><td>CS</td><td>"A B", "2", ""</td>
<td>Carrier Set</td>
<td>List of zero or more carrier names.
Carrier names are strings that do not contain the <code>' '</code> (space), <code>','</code> (comma), or <code>';'</code> (semicolon) character.
Backends may impose further requirements.
</td>
</tr>
<tr><td>L or T</td><td>"2", "-7.5", "30"</td>
<td>Stitch Value</td>
<td>A floating point number giving the number of machine units to retract a needle. Used with the "stitch" instruction.
The meaning of a stitch value may vary between machines and manufacturers; be aware that negative stitch values <b>are</b> supported by at least one manufacturer.</td>
</tr>
<tr><td>R</td><td>"4", "5.0", "2.25", "-1.75"</td>
<td>Racking Value</td>
<td>Number indicating the offset of the front bed relative to the back bed.
That is, at racking R, back needle index B is aligned to front needle index B+R.
Needles are considered aligned if they can transfer.
That is, at racking 2, it is possible to transfer from f3 to b1.
May be fractional on some machines. E.g., on Shima machines, 0.25/-0.75 are used for all-needle knitting.</td>
</tr>
</table>
<h3>Extensions</h3>
<p>Support for extending knitout is supplied through the extension headers namespace (<code>X-*</code>) and the extension opcode namespace (<code>x-*</code>).
Programs that read knitout files should warn upon encountering an extension header or opcode they do not support; but should otherwise ignore the header or opcode.
</p>
<h3>Source Comments</h3>
<p>To aid in debugging, a special type of comment is provided that identifies the source code location corresponding to the current line in the knitout file.
These "source comments" always begin with the string "<code>!source: </code>". Anything after this is considered the source location.
</p>
<p>Tools that parse knitout files should make no assumptions about the format of source locations, and should print source information intact when reporting errors.
</p>
<pre><code><op>knit</op> <par>+ f1 A</par> <comment>;!source: knit.js:53</comment>
<op>knit</op> <par>+ f2 A</par> <comment>;!source: helper.cpp -- do_knit().2</comment></code></pre>
<h2>Interpretation</h2>
<p>Knitout operations are straightfoward to interpret when generating machine control code.
However, knitout files don't provide any direct guidance on two important issues: carriage passes and kickbacks.
</p>
<h3>Carriage Passes</h3>
<p>In general, backends should attempt to produce machine instructions that fabricate a given knitout file in as few passes as possible, with the constraint that the result must be "as if" the stitches and rackings were performed one-at-a-time in the order written.
</p>
<p>
When writing knitout files, one should generally be assume that a backend will at least unify stitches into carriage passes, instead of performing each stitch in its own pass.
Backends may go further, unifying stitches with different carriers on different parts of the bed into single passes, or using multiple knitting systems to perform multiple stitches on the same needle in a single pass.
</p>
<h3>Kickbacks</h3>
<p>When interpreting knitout files, implementations should maintain a <em>logical position</em> for each yarn carrier that is currently in action.
The logical position of a carrier is set and updated by needle operations involving the carrier or the needle to which its logical position is associated.
</p>
<p>
In practice -- owing to things like yarn carrier stopping distances -- the <em>physical</em> position of a yarn carrier is often different from its logical position.
A knitout interpreter must add yarn carrier motions (called "kickbacks" in manual knit programming) to ensure that any differences between the physical and logical positions of yarn carriers are not observable in the finished knit.
We call these "implicit kickbacks" and -- among other things -- they make knitout much easier to write colorwork with.
</p>
<p>
Carrier logical positions are infinitesimally left or right of a needle, which -- for the purposes of this discussion -- we will write by appending a <code>+</code> or <code>-</code> to a needle or slider name.
So, for instance, the position just to the right of needle <code>f3</code> will be written <code>f3+</code>.
This is the same position as <code>fs3+</code>, but keeping them distinguished is sensible because of the way loop tracking works.
</p>
<h4>Update rules</h4>
<ol>
<li><b>Set:</b> After <code>tuck D N CS</code>, <code>knit D N CS</code>, <code>split D N N2 CS</code>, or <code>miss D N CS</code>, the logical position of each carrier in <code>CS</code> is set to <code>ND</code>.
</li>
<li><b>Motion:</b> After <code>split D N N2 CS</code> or <code>xfer N N2</code>, the logical position of any carrier <em>not in <code>CS</code></em> that has logical position <code>N+</code> is updated to have position <code>N2+</code>, and similarly for <code>N-</code> and <code>N2-</code>.
</li>
</ol>
<h4>Examples</h4>
<p>The "set" rule:</p>
<pre><code><op>knit</op> <par>+ f-3 A</par> <comment>;A has logical position f-3+</comment>
<op>tuck</op> <par>- b2 C D</par> <comment>;C and D have logical position b2-</comment>
<op>split</op> <par>+ f3 b3 B</par> <comment>;B has logical position f3+</comment>
<op>miss</op> <par>- bs10 E</par> <comment>;E has logical position bs10-</comment>
</code></pre>
<p>The "motion" rule:</p>
<pre><code><op>knit</op> <par>+ f3 X</par> <comment>;X has logical position f3+</comment>
<op>xfer</op> <par>f3 b3</par> <comment>;X has logical position b3+</comment>
<op>split</op> <par>- b3 fs3 Y</par> <comment>;X has logical position fs3+, Y has logical position b3-</comment>
<op>rack</op> <par>-1</par> <comment>;logical positions unchanged</comment>
<op>xfer</op> <par>fs3 b4</par> <comment>;X has logical position b4+</comment>
</code></pre>
<p>Basic example:</p>
<pre><code><op>knit</op> <par>+ f1 A</par> <comment>;A has logical position f1+, physical position is likely further right</comment>
<op>xfer</op> <par>f2 b2</par> <comment>;A should be kicked left; yarn from f1+ to A's physical position would interfere</comment>
<op>knit</op> <par>+ f10 B</par> <comment>;B has logical position f10+, physical position is likely further right</comment>
<op>knit</op> <par>+ f9 C</par> <comment>;no kickback needed</comment>
<op>knit</op> <par>+ f11 C</par> <comment>;kickback needed: yarn from f10+ to B's physical position would interfere</comment>
</code></pre>
<p>
Using the <code>miss</code> operation to override implicit kickback behavior:
</p>
<pre><code><op>knit</op> <par>+ f1 A</par> <comment>;A has logical position f1+</comment>
<op>miss</op> <par>+ f2 A</par> <comment>;A's logical position set to f2+</comment>
<op>xfer</op> <par>f2 b2</par> <comment>;A should be kicked right (or not at all)</comment>
</code></pre>
<p>
Direction matters:
</p>
<pre><code><op>knit</op> <par>+ f1 A</par> <comment>;A has logical position f1+, physical position is likely further right</comment>
<op>miss</op> <par>- f1 A</par> <comment>;A has logical position f1-, physical position is likely further left</comment>
<op>xfer</op> <par>f2 b2 </par> <comment>;no kickback needed: yarn from f1- to A's physical position is not in the way</comment>
</code></pre>
<h2>Example File</h2>
<p>
This example file uses an alternating-tuck cast-on, followed by two rows of plain knitting, and drops instead of binding off.
</p>
<pre><code><comment>;!knitout-2</comment>
<comment>;;Machine: SWG091N2</comment>
<comment>;;Gauge: 15</comment>
<comment>;;Yarn-5: 50-50 Rust</comment>
<comment>;;Carriers: 1 2 3 4 5 6 7 8 9 10</comment>
<comment>;;Position: Right</comment>
<op>inhook</op> <par>5</par>
<op>tuck</op> <par>- f10 5</par>
<op>tuck</op> <par>- f8 5</par>
<op>tuck</op> <par>- f6 5</par>
<op>tuck</op> <par>- f4 5</par>
<op>tuck</op> <par>- f2 5</par>
<op>tuck</op> <par>+ f1 5</par>
<op>tuck</op> <par>+ f3 5</par>
<op>tuck</op> <par>+ f5 5</par>
<op>tuck</op> <par>+ f7 5</par>
<op>tuck</op> <par>+ f9 5</par>
<op>releasehook</op> <par>5</par>
<op>knit</op> <par>- f10 5</par>
<op>knit</op> <par>- f9 5</par>
<op>knit</op> <par>- f8 5</par>
<op>knit</op> <par>- f7 5</par>
<op>knit</op> <par>- f6 5</par>
<op>knit</op> <par>- f5 5</par>
<op>knit</op> <par>- f4 5</par>
<op>knit</op> <par>- f3 5</par>
<op>knit</op> <par>- f2 5</par>
<op>knit</op> <par>- f1 5</par>
<op>knit</op> <par>+ f1 5</par>
<op>knit</op> <par>+ f2 5</par>
<op>knit</op> <par>+ f3 5</par>
<op>knit</op> <par>+ f4 5</par>
<op>knit</op> <par>+ f5 5</par>
<op>knit</op> <par>+ f6 5</par>
<op>knit</op> <par>+ f7 5</par>
<op>knit</op> <par>+ f8 5</par>
<op>knit</op> <par>+ f9 5</par>
<op>knit</op> <par>+ f10 5</par>
<op>outhook</op> <par>5</par>
</code></pre>
<h2>Design Notes</h2>
<p>
This section provides notes on the thinking behind the design choices that went into knitout.
</p>
<h3>Design Principles</h3>
<p>
<b>Low-level.</b>
The format is low-level. It contains no flow-control, abstractions, or grouping primitives.
</p>
<p>
<b>Output-oriented.</b>
Knitout contains exactly the instructions required to fabricate a knit object.
</p>
<p><b>Debug-able.</b>
As an output language, it is important that instructions in a knitout file can be tied back to their source in design programs.
Thus, if there is a problem in fabrication or simulation, an error can be reported with a reasonable source location.
</p>
<p><b>Easy to use.</b>
It should be simple to write software that reads or writes knitout files.
</p>
<h3>Challenges and Resolutions</h3>
<p><b>C:</b> Should we use implicit or explicit kickbacks?</p>
<p><b>R:</b> Implicit.
Explicit kickbacks make it easier to write a backend, but harder to write design tools, write knitout files by hand, or to interpret what knitout files are producing.
We expect that more frontend tools will be written than backend tools, and prefer the clarity that comes from not having to constantly think about yarn capture when producing a knitout file.
The <code>miss</code> opcode allows frontend authors who wish to schedule their own kickbacks to do so.
</p>
<p>
It may make sense to introduce an extension header ";;X-Kickbacks: Explicit" to control this behavior.
</p>
<p><b>C:</b> Should the format support 'drop', 'amiss', and 'xfer'?</p>
<p><b>R:</b> Yes.
These are synonyms for 'knit', 'tuck', and 'split' with no yarns; which makes them redundant.
On the other hand, they are expected and would certainly be provided by any interface; also, having these in the language avoids the weirdness of needing to specify a left/right direction for a transfer.
</p>
<p><b>C:</b> How to support the wide variety of takedown systems and features? (E.g. fabric presser, rollers, combs, segmented combs.)</p>
<p><b>R:</b>
For now, we leave this for extensions; if common themes begin to emerge, we will make the features core operations.
We are likely to support an "x-presser on/auto/off" operation for the SWG backend.
</p>
<p><b>C:</b> One generally can't bring a yarn into action without actually making a stitch with it. Should we combine 'in[hook]' and knitting instructions? Should we require that it be followed by a knitting instruction?</p>
<p><b>R:</b>
We considered, but rejected, several resolutions:
</p>
<ol>
<li>
Make 'in[hook]' a prefix to a knitting instruction (e.g. 'inhook knit + f2 A C').
This seems to increase file parsing complexity.
</li>
<li>
Require that 'in[hook]' always be immediately followed by a knitting instruction for the named yarns.
This seems to increase file writing complexity, and perhaps file parsing complexity.
</li>
<li>
Remove 'in[hook]', and have implicit yarn ins.
This seems to make it easier to make errors in writing knitout files.
</li>
</ol>
<p>
Each of these possible resolutions seems to make it harder to read, write, or understand knitout files.
Instead, we changed the language of the specification to make it clear that 'in[hook]' <em>marks</em> carriers to be inserted when next they are used, instead of inserting them directly.
</p>
<p>
In addition, we suggest that programs that read knitout files should produce a warning if carriers are marked for inserting but not used for a long time.
</p>
<p><b>C:</b> Should the back bed move left or right relative to the front bed for positive racking values?</p>
<p><b>R:</b> Positive racking values move the back bed right.
Here are two justifications, both of which are relatively weak:
</p>
<ul>
<li>One way to indicate the racking would be to attach a pointer to the back bed and a scale to the front bed. (One wouldn't put the scale on the back bed because it is hard to see.)
The selected convention means that the numbers on the scale are increasing left-to-right.
</li>
<li>
When trying to align a front and back needle, "front index minus back index" seems like a natural order for subtraction.
</li>
</ul>
<p>
(However, in knitout 0.4, racking values worked the opposite way.)
</p>
</body>
</html>