-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathguide.tcg
1854 lines (1452 loc) · 61.1 KB
/
guide.tcg
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
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
---
title: "TCG Markdown User's Guide"
type: GUIDANCE
...
---
# Disclaimers, Notices, and License Terms
THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING
ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR
PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR
SAMPLE.
Without limitation, TCG disclaims all liability, including liability for
infringement of any proprietary rights, relating to use of information in this
specification and to the implementation of this specification, and TCG disclaims
all liability for cost of procurement of substitute goods or services, lost
profits, loss of use, loss of data or any incidental, consequential, direct,
indirect, or special damages, whether under contract, tort, warranty or
otherwise, arising in any way out of use or reliance upon this specification or
any information herein. This document is copyrighted by Trusted Computing Group
(TCG), and no license, express or implied, is granted herein other than as
follows: You may not copy or reproduce the document or distribute it to others
without written permission from TCG, except that you may freely do so for the
purposes of (a) examining or implementing TCG specifications or (b) developing,
testing, or promoting information technology standards and best practices, so long
as you distribute the document with these disclaimers, notices, and license terms.
Contact the Trusted Computing Group at www.trustedcomputinggroup.org for
information on specification licensing through membership agreements. Any marks
and brands contained herein are the property of their respective owners.
---
# Change History
| Revision | Date | Description |
| ------------ | ---------- | --------------- |
| 0.1/1 | 2023/12/17 | Initial draft |
---
\tableofcontents
\listoftables
\listoffigures
---
# Scope and Purpose
::: Note :::
This document demonstrates the TCG Pandoc toolset, which automatically adds
"TCG Confidential" at the bottom of all drafts. This document is itself not TCG
Confidential because it is a part of an open-source repository.
::::::::::::
The purpose of this guide is to demonstrate the usage of Markdown-plus-GitHub
document-authorship flows for TCG workgroup usage.
This document contains a boilerplate section at the front called Document Style.
This section is typically included in TCG Specifications and isn't as relevant for Guidance and
Reference documents. It's included here, mainly to demonstrate the usage of Markdown for specifications.
# Getting Started
## Creating a Repository
You can create a repository from scratch, or you can use
[the template repository](https://github.com/TrustedComputingGroup/specification-example)
to get started a little more quickly. There's a little green "Use this template" button in the top right
(see @fig:use-template-button).
![The "Use this template" button](use_template.jpg){#fig:use-template-button width=50%}
## GitHub Actions {#sec:basic-gh-action}
Even if you used the template repository, please double-check this. As the tools
are being actively developed, there is probably a newer version of the tools
available for you!
::: Note :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Use `ghcr.io/trustedcomputinggroup/pandoc:latest` at your own risk. As the tools
may change defaults from version to version, it is better to pin your doc to
a particular version of the tools and periodically update the tools as needed.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
A typical GitHub Markdown repo will:
* Render the spec to PDF on pull requests and attach the PDF to the PR.
* Render the spec to PDF and Word on releases and attach them to the release.
* Cache the LaTex intermediate files to the GitHub actions cache. This allows
small changes to the doc to render faster.
The recommended way to do this is to use the
[reusable GitHub workflows](https://docs.github.com/en/actions/using-workflows/reusing-workflows)
in
[trustedcomputinggroup/pandoc](https://github.com/trustedcomputinggroup/pandoc)'s
.github/workflows directory.
Another project's `.github/workflows/render.yml` might look a bit like this:
```yaml
name: Render
on:
workflow_call:
inputs:
workflow:
description: the workflow to run ('pr', 'push', 'release', 'manual')
required: true
type: string
revision:
description: version to render (default is default branch)
required: false
type: string
manual_diffbase:
description: diffbase for manual workflow
required: false
type: string
jobs:
render:
uses: trustedcomputinggroup/pandoc/.github/workflows/[email protected]
with:
container-version: 0.15.4
input: spec.tcg
workflow: ${{ inputs.workflow }}
revision: ${{ inputs.revision }}
manual_diffbase: ${{ inputs.manual_diffbase }}
```
The reusable workflows provided by this repository support four different operations:
Table: Reusable Workflow Operations {#tbl:reusable-workflows}
+----------------------+----------------------------+
| Workflow | Description |
+======================+============================+
| pr | Render the spec and diff |
| | the change in the PR, |
| | attaching both to the |
| | "Artifacts" tab of the PR. |
+----------------------+----------------------------+
| push | Render the spec and attach |
| | it to the action's |
| | "Artifacts" tab. |
+----------------------+----------------------------+
| release | Render the spec and attach |
| | it to the release. |
+----------------------+----------------------------+
| manual | (Triggered manually) |
| | Render the spec at the |
| | revision `revision` with |
| | optional diffing to |
| | `manual_diffbase`. |
+----------------------+----------------------------+
## Local Testing
These tools have a number of dependencies on LaTeX and LaTeX plugins. The
simplest way to get a consistent build is to use the docker container that gets
used for the GitHub actions.
`docker_run` is provided as a convenience script for Linux systems.
Usage:
```sh
./docker_run --pdf=output.pdf ./input.md
```
You can specify a particular version of the docker container using the
`DOCKER_IMAGE` environment variable:
```sh
DOCKER_IMAGE=ghcr.io/trustedcomputinggroup/pandoc:0.6.5 ./docker_run --pdf=output.pdf ./input.md
```
If you're working on a change to these tools, it can be beneficial to build and
tag a local version of the container and then run it locally:
```sh
docker build --tag working .
DOCKER_IMAGE=working:latest ./docker_run --pdf=output.pdf ./input.md
```
## TCG Document Boilerplate
There are several sections that are recommended for use in every TCG Markdown document.
The trickiest section is the YAML front matter at the very top of the Markdown file.
It looks like this:
```md
---
title: "TCG Markdown User's Guide"
type: GUIDANCE
...
```
This section provides metadata to the tools.
### Front Matter Variables {#sec:yaml-frontmatter}
#### title
REQUIRED.
`title` is the title of the document.
#### type
REQUIRED.
`type` should be one of: "SPECIFICATION", "GUIDANCE", or "REFERENCE". It appears on the title page on the left-hand side.
### Backslash Macros
Understanding of LaTeX is not required in order to use TCG Markdown tools. However, a few special macros can be used from Markdown to fully specify a TCG document.
#### Table of Contents {#sec:toc}
After the boilerplate sections, most TCG documents should set up the tables of contents, and lists of tables and figures.
```
\tableofcontents
\listoftables
\listoffigures
```
Almost every document should have a table of contents. Some documents may not need lists of tables or figures.
#### Appendices
At the end of the last "regular" section of the document, use
```
\beginappendices
```
to mark the transition to the "Appendix" portion of the document. Only documents that have appendices
are expected to use this macro.
# Collaboration Model
Users familiar with Git and who prefer to use their own tools may choose to skip this section.
```mermaid {caption="GitHub Collaboration Workflow" #fig:collaboration-workflow}
gitGraph
commit id: "head"
branch proposed-edits-1
commit id: "propose-1"
commit id: "respond-to-feedback-1"
commit id: "respond-to-feedback-2"
checkout main
merge proposed-edits-1
branch proposed-edits-2
commit id: "propose-2"
commit id: "respond-to-feedback-3"
commit id: "respond-to-feedback-4"
checkout main
merge proposed-edits-2
```
As visualized in @fig:collaboration-workflow, proposed changes to a GitHub Markdown repository take the form of
"Pull Requests" (PRs). A *proposer* of a change proposes a PR that changes some files in the repository.
This PR contains an initial *commit*, which is a unit of change to files.
*Reviewers* can provide comments and suggestions on the proposed edits. The *proposer* can respond to
the feedback by adding additional *commits* into their PR. When all parties are satisfied, the PR is
*approved* and *merged* into the main repository.
## Sending a Pull Request {#sec:sending-a-pr}
When you navigate to a GitHub repository containing Markdown, you can view the Markdown files by
clicking on them.
From this view, there is an "Edit" (pencil) button in the upper right-hand corner, pictured in
@fig:edit-file-button:
![GitHub Edit Button](edit_this_file.jpg){#fig:edit-file-button width=30%}
This will take you to a view where you can edit the file. There is a "Preview" button that you can use
to see roughly how the changes will look when viewed from GitHub. Most everyday changes to TCG docs
can be previewed in high enough fidelity with this tool.
When you're satisfied with your changes, use the green "Commit changes..." button. This will bring up
the dialog box pictured in @fig:propose-changes:
![Propose Changes Dialog](propose_changes.jpg){#fig:propose-changes width=60%}
Include a descriptive commit message, extended description, and new branch name for your change,
then click the green "Propose changes" button.
You're almost done! This will take you to a page called "Open a pull request". You can provide some
additional context to reviewers about why you want to make this change. When you're satisfied, click
"Create pull request."
## Reviewing a Pull Request
After a PR has been sent by someone else, you can review the changes with the "Add your review" button
in the upper right-hand corner of the change description page.
This button takes you to a review flow, where you can provide comments on individual lines of the changes.
You can leave a comment on an individual line by mousing over the line and clicking the blue "+" button,
which looks like @fig:plus-button:
![Plus Button](plus_button.jpg){#fig:plus-button}
After you've gone through all the changed files and provided your comments, you can click "Review changes"
to finish the review. This dialog looks like @fig:finish-review:
![Finish Review](finish_review.jpg){#fig:finish-review width=60%}
Here, you can provide summary comments and mark your review as one of:
* Comment (Just providing feedback)
* Approve (Approving the changes)
* Request changes (Explicitly not approving the changes, with specific actionable feedback)
## Releasing the Spec {#sec:running-on-release}
If you have GitHub Actions for rendering the spec for releases (see
@sec:basic-gh-action), here is how you can manage the release cycle of the spec:
1. Navigate to the "Releases" page for the repository ("Releases" on the right
hand side of the main page).
2. Click "Create a new release"
3. Click "Choose a tag", then "Create a new tag"
4. Tag the release according to the [naming conventions](#sec:release-conventions)
supported by the tools.
5. A few minutes later, the PDF and DOCX of the spec will appear on the page
for that release (you can monitor this on the "Actions" page).
::: Note :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
When balloting or sending a document to the TC for review, please create a docx
diff from Microsoft Word, comparing the docx outputs attached between releases
with Word's "Compare Versions" tool.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
# Using Markdown
Markdown is intended to be a lightweight language for authoring documents. Most of the time, it looks
exactly the same as plain text.
## Basic Formatting
The structure of the document is guided by lines that begin with `#`:
```md
# Section Titles
## Subsection Titles
### Sub-subsection Titles
```
and so on.
When you put `*asterisks*` around a word, it renders as *italics*.
When you put `**double asterisks**` around a word, it renders as **boldface**.
When you put ``` `backticks` ``` around a word, it renders as `monospace`.
To force a new page, use `---`. This will appear as a horizontal line in GitHub and a page break in the PDF.
---
When you need to write math, use `$ dollar signs $` for inline math notation, or `$$ double dollar signs $$` for equations. This is explained in more detail in @sec:math.
Numbered and bulleted lists begin with numbers and asterisks:
```md
* Something
* Something else
1. First thing
2. Second thing
```
Becomes:
* Something
* Something else
1. First thing
2. Second thing
Hyperlink syntax for the [TCG Website](https://trustedcomputinggroup.org) looks like: `[TCG Website](https://trustedcomputinggroup.org)`.
Hyperlink syntax for the [Using Markdown](#using-markdown) section looks like:
`[Using Markdown](#using-markdown)`. If you provided a stable cross-referencing link like this
document for [Cross-References](#sec:cross-references), you can use it like:
`[Cross-References](#sec:cross-references)`.
You can use triple backticks like so to create blocks of code:
````md
```
int i = 42;
```
````
The result looks like this:
```
int i = 42;
```
You can tell Markdown what language the code is in, to get syntax highlighting:
````md
```c
// Awesome!
int i = 42;
```
````
The result looks like this:
```c
// Awesome!
int i = 42;
```
## Footnotes {#sec:footnotes}
```md
You can use a footnote[^footnote-example] to provide additional details about something
out of the way, at the bottom of the page.
[^footnote-example]: See @sec:footnotes for more information about footnotes.
```
You can use a footnote[^footnote-example] to provide additional details about something
out of the way, at the bottom of the page. The footnotes will be automatically numbered.[^footnote-numbering]
[^footnote-example]: See @sec:footnotes for more information about footnotes.
[^footnote-numbering]: Like this.
## Cross-References {#sec:cross-references}
In general, sections, tables, figures, and equations can be referenced using the `@` symbol. These cross-references do not show up in the GitHub markdown, but will appear in the final document.
### Sections
When you add `{#sec:section-reference}` at the end of a section title, as in:
```md
## Cross-References {#sec:cross-references}
```
it creates a cross-reference
that you can use with `@sec:section-reference`. For example, `@sec:cross-references` @sec:cross-references.
### Tables
See @sec:tables for more information about cross-references to tables.
### Figures
See @sec:figures for more information about cross-references to figures.
### Equations
See @sec:math for more information about cross-references to equations.
## TCG-Specific Blocks
### Informative Text Blocks
TCG uses a special visual style to demarcate informative non-binding remarks within specifications.
To create an informative note, use the following syntax:
```md
::: Informative ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
This is the only informative text block in this document.
These blocks can contain multiple paragraphs.
These blocks can even contain tables! However, be wary of providing tables that
are too large in an Informative Text block.
| Document Type | Informative Blocks |
| ----------------- | ---------------------- |
| SPECIFICATION | Usually |
| GUIDANCE | Sometimes |
| REFERENCE | Rarely |
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
```
The above Markdown code becomes:
::: Informative ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
This is the only informative text block in this document.
These blocks can contain multiple paragraphs.
These blocks can even contain tables! However, be wary of providing tables that
are too large in an Informative Text block.
| Document Type | Informative Blocks |
| ----------------- | ---------------------- |
| SPECIFICATION | Usually |
| GUIDANCE | Sometimes |
| REFERENCE | Rarely |
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Strictly speaking, only the three colons and the type (e.g., `::: Informative `)
are the minimum required for marking an informative text block. However, it may
make the plaintext version of the doc easier to read to fill the line with
colons.
### Other Informative Blocks
Writers of a document may prefer "informative" blocks with more specific
semantics. In this case, the text is still contained within a "TCG Informative"
gray box, but with a more meaningful header.
::: Note :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
This is a "Note" block.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::: Example ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
This is an "Example" block.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
The behavior of blocks with labels not specified above may change meaningfully in future versions of this toolkit, so use them at your own risk.
### Deprecation Notices
Specifications occasionally need to deprecate features or commands. Use the
"Deprecated" block to create a visually distinctive notice of the deprecation.
Minimal example:
::: Deprecated :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
TDES was deprecated in version 123.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Best practices for deprecation:
1. Explain which version of the document introduced the deprecation.
2. If applicable, explain why the feature was deprecated.
3. Explain what users should use instead.
Better example:
::: Deprecated :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
TDES was deprecated in version 123. It was withdrawn by NIST at the end of 2023:
<https://csrc.nist.gov/News/2023/nist-to-withdraw-sp-800-67-rev-2>
Users are encouraged to use AES instead.
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
# Figures {#sec:figures}
There are two ways to include a figure in a document: as an image file checked into the repository, and as a [Mermaid](http://mermaid.js.org) diagram.
## Images
Upload plain image files into the repository with the "Add file" button.
For compatibility reasons, all image files should be in the root of the repository (main directory). In the future, better support for organizing figures may be added to these tools.
See @sec:sending-a-pr for the flow that needs to be followed for getting your image uploads reviewed. You can add more changes
to the branch for the PR that reference the image, or you can do it in a subsequent PR.
Markdown syntax for including an image looks like `![Figure Title](filename)`. For example:
```md
![Adding an Image](add_plus_button.jpg){#fig:add-plus-button width=60%}
```
becomes:
![Adding an Image](add_plus_button.jpg){#fig:add-plus-button width=60%}
Including a figure title (`Adding an Image` between the `[]` above) causes the image to numbered, included in
the list of figures, and given a caption.
The `{#fig:add-plus-button}` attribute (note there are no spaces between the `)` and the `{`!) allows you to
reference it as @fig:add-plus-button by just typing `@fig:add-plus-button`.
Including `width=60%` here specifies that the image should take up 60% of the page's width.
Without the title and `#fig` attribute,
```md
![](add_plus_button.jpg)
```
looks like:
![](add_plus_button.jpg)
![An SVG Image](stack.svg){#fig:sample-svg width=50%}
Even formats that are not natively supported by Pandoc are now supported, like the SVG in @fig:sample-svg.
Tip: SVG can include text in any font that you choose. If you want to make sure the final PDF looks good,
make sure to use one of the fonts in the list that can be seen from inside the docker containers:
```sh
$ docker run -it --entrypoint /bin/bash ghcr.io/trustedcomputinggroup/pandoc:latest
root@25a780af4a2d:/# convert -list font | grep Font:
```
## Mermaid Charts
[Mermaid](http://mermaid.js.org) is a language for text-based diagrams for inclusion in Markdown documents.
See the Mermaid website for a more exhaustive list of types of diagrams.
### Sequence Diagrams
Mermaid supports swim-lane digrams like @fig:startup with the following notation:
````md
```mermaid {caption="Startup Sequence" #fig:startup}
sequenceDiagram
Host->>TPM: TPM2_Startup
loop Measurements
Host->>TPM: TPM2_PCR_Extend
end
Host->>TPM: TPM2_Quote
TPM->>Host: <quoted PCRs>
```
````
```mermaid {caption="Startup Sequence" #fig:startup}
sequenceDiagram
Host->>TPM: TPM2_Startup
loop Measurements
Host->>TPM: TPM2_PCR_Extend
end
Host->>TPM: TPM2_Quote
TPM->>Host: <quoted PCRs>
```
### Flow Charts
Mermaid supports flow-charts like @fig:flowchart with the following notation:
````md
```mermaid {caption="Flowchart" #fig:flowchart}
graph TD;
A-->B;
A-->C;
B-->D;
C-->D;
```
````
```mermaid {caption="Flowchart" #fig:flowchart}
graph TD;
A-->B;
A-->C;
B-->D;
C-->D;
```
Crossreferences to Mermaid diagrams are supported by providing both `caption`
and `#fig:xxxxx` classes in curly braces.
## DrawIO Diagrams
Some diagrams can't easily be represented in (human-maintained) code.
[Draw.io](https://app.diagrams.net/) is a tool for creating sophisticated
diagrams. There is a Visual Studio Code extension for it.
Check in and add draw.io diagrams to your document like in @fig:sample-drawio:
```md
![Sample DrawIO Diagram](sample.drawio.svg){#fig:sample-drawio width=50%}
```
![Sample DrawIO Diagram](sample.drawio.svg){#fig:sample-drawio width=50%}
# Tables {#sec:tables}
We support several notation styles for tables.
## Markdown Tables
There are several ways to write a table in Markdown.
### GitHub Markdown Tables {#sec:github-markdown-tables}
Small, simple tables like @tbl:shapes are easier to read in raw Markdown form in the following style:
```md
Table: Shapes {#tbl:shapes}
| Shape | Number of sides |
| ------------ | --------------- |
| Pentagon | 5 |
| Square | 4 |
| Triangle | 3 |
| Mobius strip | 1 |
```
Table: Shapes {#tbl:shapes}
| Shape | Number of sides |
| ------------ | --------------- |
| Pentagon | 5 |
| Square | 4 |
| Triangle | 3 |
| Mobius strip | 1 |
Note the table caption and cross-reference in curly braces above the table.
### Simple Markdown Tables {#sec:simple-markdown-tables}
There is an even more minimal syntax for simple tables, as in
@tbl:simple-shapes:
```md
Table: Shapes {#tbl:simple-shapes}
Shape Number of sides
------------ ---------------
Triangle 3
Mobius strip 1
```
Table: Shapes {#tbl:simple-shapes}
Shape Number of sides
------------ ---------------
Triangle 3
Mobius strip 1
### Multiline Markdown Tables {#sec:multiline-markdown-tables}
Sometimes, you may need to write a lot of Markdown content in the cell of a table,
and this content may need multiple lines in your editor.
```md
Table: Table Types {#tbl:table-types}
-------------------------------------------------------------------------------
Table Kind Easy? Recommended? References
--------------- ----------- ------------------- -------------------------------
GitHub Yes When each cell @sec:github-markdown-tables,
Markdown is about one @tbl:shapes
Tables word or so.
Simple Yes When each cell @sec:simple-markdown-tables,
Markdown is about one @tbl:shapes
Tables word or so.
Multiline Yes When you have @sec:multiline-markdown-tables,
Markdown content that's @tbl:table-types
Tables more than a few
words.
Grid Markdown No When you have @sec:grid-tables,
Tables row or column @tbl:fruits-grid
spans and need
full Markdown
support (e.g.,
blocks or
equations).
HTML Yes When you have @sec:html-tables,
Tables row or column @tbl:fruits-html
spans, and
don't need
full Markdown
or don't mind
doing all the
styling in
HTML.
-------------------------------------------------------------------------------
```
Table: Table Types {#tbl:table-types}
-------------------------------------------------------------------------------
Table Kind Easy? Recommended? References
--------------- ----------- ------------------- -------------------------------
Simple Yes When each cell @sec:simple-markdown-tables,
Markdown is about one @tbl:shapes
Tables word or so.
Multiline Yes When you have @sec:multiline-markdown-tables,
Markdown content that's @tbl:table-types
Tables more than a few
words. Supports
inline Markdown
elements (like
cross-references)
but not block
elements (like
informative
blocks).
Grid Markdown No When you have @sec:grid-tables,
Tables row or column @tbl:fruits-grid
spans and need
full Markdown
support (e.g.,
crossrefs or
equations).
HTML Yes When you have @sec:html-tables,
Tables row or column @tbl:fruits-html
spans, and
don't need
full Markdown
or don't mind
doing all the
styling in
HTML.
-------------------------------------------------------------------------------
### Grid Tables {#sec:grid-tables}
You may have some data that needs to be presented in a table that allows you
to make cells span rows or columns. Grid tables like @tbl:fruits-grid can be
used for this. Note that editing these tables requires a bit more typing. It's
recommended to use these only when you need row and column spanning.
Some tools provide assistance for generating tables of this type. If you find
a tool that is handy for editing Markdown grid-style tables, please send a PR
to github.com/trustedcomputinggroup/pandoc!
```md
Table: Fruits (Grid) {#tbl:fruits-grid}
+----------------------+----------------------------+
| Fruit and Color | Mistaken for Vegetable |
+=============+========+============================+
| | Red | No |
| Apple +--------+----------------------------+
| | Green | No |
+-------------+--------+----------------------------+
| Tomato | Red | Yes |
+-------------+--------+----------------------------+
| Banana | Yellow | No |
+-------------+--------+----------------------------+
```
Table: Fruits (Grid) {#tbl:fruits-grid}
+----------------------+----------------------------+
| Fruit and Color | Mistaken for Vegetable |
+=============+========+============================+
| | Red | No |
| Apple +--------+----------------------------+
| | Green | No |
+-------------+--------+----------------------------+
| Tomato | Red | Yes |
+-------------+--------+----------------------------+
| Banana | Yellow | No |
+-------------+--------+----------------------------+
A grid table can be divided into sections using `===` in a full-span row,
as in @tbl:subsections:
```md
Table: Complex Table With Subsections {#tbl:subsections}
+-------------+--------+----------------------------+
| Fruit | Color | Description |
+=============+========+============================+
| =============== Tree Fruits ===================== |
+-------------+--------+----------------------------+
| Apple | Red | Useful for pie. |
+-------------+--------+----------------------------+
| Pear | Green | Useful for pie? |
+-------------+--------+----------------------------+
| ================= Berries ======================= |
+-------------+--------+----------------------------+
| Cherry | Red | Useful for pie. |
+-------------+--------+----------------------------+
| Banana | Yellow | Useful for pie. |
+-------------+--------+----------------------------+
| Tomato | Red | Not useful for pie. |
+-------------+--------+----------------------------+
```
Table: Complex Table With Subsections {#tbl:subsections}
+-------------+--------+----------------------------+
| Fruit | Color | Description |
+=============+========+============================+
| =============== Tree Fruits ===================== |
+-------------+--------+----------------------------+
| Apple | Red | Useful for pie. |
+-------------+--------+----------------------------+
| Pear | Green | Useful for pie? |
+-------------+--------+----------------------------+
| ================= Berries ======================= |
+-------------+--------+----------------------------+
| Cherry | Red | Useful for pie. |
+-------------+--------+----------------------------+
| Banana | Yellow | Useful for pie. |
+-------------+--------+----------------------------+
| Tomato | Red | Not useful for pie. |
+-------------+--------+----------------------------+
* The row must span the entire table
* The row must begin and end with at least three equals signs
* The row must be separated from its equals signs by spaces
Below is a table with full-span rows that do not use this feature:
+-------------+--------+----------------------------+
| Fruit | Color | Description |
+=============+========+============================+
| Tree Fruits |
+-------------+--------+----------------------------+
| Apple | Red | Useful for pie. |
+-------------+--------+----------------------------+
| Pear | Green | Useful for pie? |
+-------------+--------+----------------------------+
| Berries |
+-------------+--------+----------------------------+
| Cherry | Red | Useful for pie. |
+-------------+--------+----------------------------+
| Banana | Yellow | Useful for pie. |
+-------------+--------+----------------------------+
| Tomato | Red | Not useful for pie. |
+-------------+--------+----------------------------+
### Styling Markdown Tables
#### Removing Lines
Tables are drawn with lines around all the cells by default.
Use the `.plain` class to avoid drawing any lines or background shading.
This is useful when you want to present some tabular text without styling it
like "an actual table".
```md
: {.plain}
----- -----
like this
----- -----
```
: {.plain}
----- -----
like this
----- -----
#### Column Alignment
Each type of Markdown table provides different support for alignment. See the
[Pandoc table documentation](https://pandoc.org/chunkedhtml-demo/8.9-tables.html)
for more details.
## HTML Tables {#sec:html-tables}
A rowspan/colspan table like @tbl:fruits-grid can be implemented in HTML like
the below. Note that this is a little easier to type, and a little harder to
read in plain-text form. We recommend preferring [grid tables](#sec:grid-tables)
to HTML tables, but HTML tables can be fine in certain situations (for example,
a gradual migration away from a Word document using Pandoc, which typically
converts Word tables into HTML).
```md
<table id="tbl:fruits-html">
<caption>Fruits (HTML)</caption>
<colgroup>
<col style="width: 12%" />
<col style="width: 13%" />
<col style="width: 45%" />
</colgroup>
<tr>
<th colspan="2">Color and Fruit</th>
<th>Mistaken for Vegetable</th>
</tr>
<tr>
<td rowspan="2">Apple</td>
<td>Red</td>
<td>No</td>
</tr>
<tr>
<td>Green</td>
<td>No</td>
</tr>
<tr>
<td>Tomato</td>
<td>Red</td>
<td>Yes</td>
</tr>