diff --git a/minutes/meeting-20201215-6.md b/minutes/meeting-20201215-6.md
new file mode 100644
index 0000000..b687244
--- /dev/null
+++ b/minutes/meeting-20201215-6.md
@@ -0,0 +1,172 @@
+# Minutes of Meeting 6, 2020-12-15, 20:30-22:00 UTC
+
+- Acting chair: Liang Hai
+- Scribe: Liang Hai, et al.
+- Agenda: https://github.com/w3c/font-text-cg/issues/35
+
+## Resolutions
+
+None
+
+## Actions
+
+- Schedule the Meeting 7 for Tuesday 12 January 2021 (four weeks later), same time at UTC 20:30.
+
+## Attendance
+
+Bob Hallissy, Bobby de Vos,\* Chris Chapman,\* David Corbett,\* David Singer,\* Duncan MacMichael, Erwin Denissen, Greg Hitchcock, Jany Belluz,\* John Hudson,\* Josh Hadley,\* Laurence Penney,\* Liang Hai,\* Makoto Murata, Nate Willis,\* Ned Holbrook,\* Norbert Lindenberg, Peter Constable,\* Renzhi Li, Sairus Patel,\* Simon Cozens,\* Vladimir Levantovsky\*
+\* Formal participants of the FTCG.
+
+The IRC channel recorded the following nicks:
+
+liang, simon, josh_hadley, dscorbett, Bobbyd, BobHallissy, petercon, Vlad, jany_belluz, Chris_Chapman, dsinger, reli_msft
+
+## Minutes
+
+### 3. Self-introduction of new participants
+
+- Jany Belluz, Dalton Maag. Watching what’s going. Open source tooling chain.
+- Bob Hallissy, SIL.
+
+### 5. Plan major agenda items for next meeting and tentatively schedule it
+
+Wanted to see if we could have a more flexible meeting management process, in case we wanted to involve specific experts, which might have TZ difficulties. Might be more helpful to have a default time. Have been either operating on Tuesday or Monday. Any preferences?
+Looking at polls, margin is very narrow; doesn’t hurt too much to have either Monday or Tuesday. JH: Earlier on Monday conflicts with Webfonts WG. If we start dealing with Indic topics, with engagement from people from India, an earlier timeslot would be better. VL: If so then Tuesday would definitely be prefered. LH: Let’s fix next meeting for Tuesday, same day of week same time, UTC 20:30.
+
+### 6: Actionable proposals
+
+Nothing quite active now?
+
+### 7: Stalled/ any other?
+
+Peter Constable: Before Simon’s presentation. How do people understand in the charter where the boundary is for technical deliverables.
+
+Vlad: Discussions are fine.
+
+John H: Hope to discuss technical things and think about where to deal with the problems and identify possible solutions.
+
+Simon: We talk about not wanting technical contributions; right now there’s no projects to contribute to.
+
+David Singer: Discussions. Not contributions. Understanding what’s in the ecosystem.
+
+Vlad: We have many forms and venues/groups to consider.
+
+Liang:
+
+----
+
+Simon:
+
+When you’re justifying text, particularly Latin, space varies. Various techs to make justification systems. Stretching approach: keeping space; stretch shapes.
+
+Now with VF, text can vary, in addition to justification. Two dimensions: how much the text can move and how much the space can move. Does it help with Arabic justification? No. Arabic justification is a lot more than justifying kashidas.
+
+Looking at JSTF. The spec looks great. But no fonts containing JSTF; no layout engine supporting; no font editor supporting.
+
+Manually creating in ttx. But can’t tell shaping engines, eg, HarfBuzz, to turn on justification by ID. Need OTL features to access them. If we need features to access justification substitutions, why bother using JSTF IDs at all? Not worth it.
+
+Arabic experiment. Swashed letter nun.
+
+If we have a font with enough number of contextual alternates, we can do justification like how Gutenberg did.
+
+Interplay between VF, justification, positions, line breaking algorithm, layout engine.
+
+Peter C: Question about how it works.
+
+Simon: This implementation, conceptually, is a text is a sequence of parallel nodes that have different lengths, and the algorithm can decide which one to use.
+
+Renzhi: Penalty as in TeX’s algorithm.
+
+Simon: This is also penalty based. Similar to the TeX algorithm but much simpler.
+
+Renzhi: Paragraph stability and thus performance is preferred in web browsers.
+
+Simon: Esp for VF, there can be so many nodes in a line, and the performance gets bad quickly.
+
+Peter C: Instead of individual nodes, how about ranges?
+
+John H: Any efforts to standardize justification algorithms? Without standardization there’s no point supporting JSTF.
+
+Renzhi: Performance.
+
+Ned H: Some sort of optimal linebreaks isn’t necessarily the goal.
+
+John H: Standardization doesn’t necessarily need to be the one way to do it.
+
+Ned H: We have a mechanism for fonts to provide information for justification. Providing the menu of options and trusting the process. In ACE (DecoType’s Advanced Composition Engine) you choose particular what exactly glyphs you use.
+
+Vlad in Zoom chat: Issue #6 raised as part of the CSS liaison to MPEG OFF is related to justification. I believe that CSS WG does want to look into standardizing the behavior for browsers. https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf
+
+Peter C: Do authors want to have predictable linebreaking in ebook context. In poetry, there are of course hard line breaks.
+
+Murata: I don’t know enough about western typography. In Japan, people care about fidelity, but people can change the font size.
+
+Jany: Regarding what Peter mentioned earlier. GEXT proposal. An Arabic demo with kashida justification. You can lock kashida. https://jmsole.github.io/gext-demos/gext-justification/
+
+Renzhi: After GSUB, insert glues, then additional GSUB, then GPOS.
+
+Liang: Any more questions?
+
+Laurence P: How complicated is the algorithm in TeX?
+
+Renzhi: In TeX there’s only one kind of glue.
+
+Simon: Glue and box are unified in my algorithm.
+
+Vlad: If anyone is interested to standardize justification. CSS WG is after elongation and cursive forms: https://lists.w3.org/Archives/Public/www-archive/2020Feb/att-0005/CSS-SC29-20200113.pdf
+
+---
+
+### 9. Informal liaison report from MPEG-OTSPEC [@vlevantovsky, list archives]
+
+Vlad: Working draft in the work for amendment 2, for COLRv1. Peter working hard on descriptions. Amend 2 doesn’t have to be limited to COLRv1. So also language. Editorial changes not going in amend 2. Editorial postponed until 5th ed.
+
+Peter: OT spec 1.8.4 release. A lot editorial. For OFF, amend is not an appropriate vehicle for editorial changes.
+
+Laurence P: A summary of COLRv1 changes?
+
+Peter: Originally specified in v0. Formed in stacking colored layers. Simple extension for mechanisms already available. Limited color palette. Extend to include gradients. Discussed in 2019. If we’re making significant changes, maybe go further. Especially for gradients, you really want some transformations, eg, making ellipsis from circles. As some point you need glyphs outlines, and you use transformations. Composing glyphs together in COLR is like how we compose outlines in glyphs.
+
+Laurence P: Yes. Higher precision. And more flexible rotation/distortion.
+
+Peter: If you have a transformation of rotation angle, we can do linear variation on rotation.
+
+Laurence P: Main purpose is for emoji. Currently no way to address the rotation values.
+
+Peter: In fact in COLRv1, the rotation values are variable. You just need to add an item variation store.
+
+Laurence P: Black Foundry proposes glyphs components can be variable as an extension to glyf, but it does not make sense to have two mechanisms both in glyf and COLR. Does that stall COLRv1?
+
+Peter: I don’t see a reason why it needs to delay COLRv1.
+
+Renzhi: Outline boolean operations have been missing for a long time. Is COLRv1 an opportunity?
+
+Peter: Some transformation modes don’t make sense for monochrome glyphs, eg blending modes. But others do.
+
+Renzhi: Should OT reflect design or provide efficiency. How should it interact with hinting?
+
+---
+
+Duncan:
+
+[DWriteCore](https://github.com/microsoft/ProjectReunion/issues/112) available in 0.1 prerelease in project Reunion. Porting over all the APIs from DWrite to DWriteCore over the next several Windows releases. Working with Renzhi, getting DWriteCore to work on Android.
+
+---
+
+Liang: The MS position.
+
+John H: Now in the standard compliant. Previously in typography. More stable now.
+
+Greg: Reporting to standard compliant. Embedded in an engineering team (probably in Office), which can change. Best of both worlds.
+
+---
+
+Liang: Next meeting is tentatively scheduled on the same day, same time. Will send out a poll again, in light of a potential conflict with a MPEG meeting.
+
+meeting over
+
+---
+
+Lorp: ttf-cubic - experimental format using cubic curves in TrueType: [[ttf-cubic spec](https://github.com/Lorp/samsa/blob/master/docs/technote-ttf-cubic.md)] (works in Samsa and Fontlab 7.2)
+
+Peter: Explanation of why HOI works in current OT variation formats: [OT_Drafts/UnderstandingNLI.md at master · PeterConstable/OT_Drafts (github.com)](https://github.com/PeterConstable/OT_Drafts/blob/master/NLI/UnderstandingNLI.md)