feat: add font list export panel in summary tool

[7sDream]

This PR adds a "Copy" icon to the top right corner of the font list card, in the VSCode extension's summary page:

Clicking it opens a font list export panel, which can export the list of fonts as plain text:

By default, only the paths of external font files are exported.

The options above can control whether to include Typst built-in fonts and whether to add extra information such as font names:

Click the "Copy" button at the bottom to perform the copy.

---

This feature fully from a personal need of mine. Upon discovering that tinymist already had a feature of showing document font lists, I think implement it here may save my coding time(And it's true).

If the author also finds this feature useful, I am more than happy to polish the code based on review comments.

If you feel this feature is not suitable for the tinymist extension, please feel free to close the PR.

[Myriad-Dreamin]

It is fine to add such a feature, but I will suggest that we should provide more programmatical way to make it. We could add a command that expose the entire summary as a json file, which can be read by programs friendly.

[7sDream]

For simple needs (specifically, extract all font files used in the document from my font library), a plain text file with one font per line is actually easier to handle. If summary JSON is the only option, users would have to write code to process it themselves. But not everyone using Typst to write content is a technical person, right?

If the user is tech-savvy and requires information beyond just a list of font files, the JSON format is indeed a better (and more feature-rich) option. I'll see if I can add that functionality along the way.

[Myriad-Dreamin]

For simple needs (specifically, extract all font files used in the document from my font library), a plain text file with one font per line is actually easier to handle. If summary JSON is the only option, users would have to write code to process it themselves. But not everyone using Typst to write content is a technical person, right?

Let us think of our possible workflow:

1. we finish writing document.
2. we get all used fonts for bundling these fonts along with new release.
3. we update the document.
4. do step 2 again.

The boring work emerges at the step 4. This should mean that we have to open the summary page, and click the button for a list of used fonts, and update the font bundle according to the list. Therefore, it should be better to have some pipeline to make life easier, like that:

// tasks.json
{
  { name: "update-font-bundle", steps: [
    { "command": "shell", args: ["myscript ${input:fontList}"], "inputs": [
    {
      "id": "fontList",
      "type": "command",
      "command": "tinymist.getSummary",
      "args": ["${file}"]
    } },
  ] }
}

I understand you worries, but I still prefer to provide these information without having to perform any action in the UI. If it is hard to use by non-technical people, they can require some specialized commands, e.g. one that outputs a list of used fonts separated by newline.

[7sDream]

Very reasonable.

Given my limited experience in developing VSCode extensions, particularly with the commands aspect, I prefer to avoid hastily writing this feature, which may mess the codebase up.

For now, I can continue using my branch locally, and will eagerly anticipate the landing of this extension command in the future.

[Myriad-Dreamin]

I rethink it a bit, and make a small summary (todo list) from above discussion.

• [ ] Change and improve the internal command Document Metrics to ensure stable interface for users in a separated PR.
  • [ ] Check whether we can use it conveniently by VSCode task or Neovim scripting.
• [ ] Add UI for invoking this command (This PR).

---

This PR can be merged with some minor changes. The current implementation doesn't look bad but I would like to change it a bit.

• [ ] It could be export as either json or csv.
• If it is exported as csv, it is okay to have a builtin filter, like FS Only, but I want to make it more dumb so to ensure consistency with the command used by VSCode task or Neovim scripting:
  • [ ] we can have fixed camelCase csv headers.
  • (Postscript) name
  • font styles, such as style, weight, stretch
  • (Font) location: enumerated, either fileSystem or memory.
  • (File System) path: Empty if the source is memory. It must be absolute.
  • [ ] options to export by csv headers.
  • [ ] delimiter, referring to https://docs.python.org/3/library/csv.html.
  • [ ] with/without csv header.
  • [ ] a list of the headers to export, rendered as <input type="checkbox">.
  • [ ] filter by enumerated field, like location=fileSystem, rendered as <select>/<option>.
• [ ] The editor can remember the choice, similar to the following code. Since it isn't necessary to be done in current PR, we can discuss it in a separated PR. https://github.com/Myriad-Dreamin/tinymist/blob/27fa1beb261669fbb50f1e5141d63b9a9594e8b1/editors/vscode/src/editor-tools.ts#L105-L110

[7sDream]

Wow, thanks for the clear summary list.

I can make these nice changes, but I've been occupied with other daily work things lately.

I'll likely come back to it in a few days!

[7sDream]

Changes:

• Replaced previous (which is not actually CSV format) output code with the csv-stringify library
• CSV header
• More field option for CSV format
• JSON format export
• Export to file directlly
• Export configurations persistence
• Refactored UI code

Screenshot:

---

Things for discussion:

1. The default appearance of select[multiple] is a multi-row box. Even withsize: 1, it seems less aesthetically pleasing when displayed inline. Moreover, it requires holding down Ctrl/Command for multiple selections, which seems somewhat cumbersome. So, I temporarily still display the location filter as several input[type="checkbox"]. Any better options here? Would it be worth implementing a combo box with dropdown checkboxes specially for this?
2. About the export command, do we only need to support JSON format for now? I briefly looked at VSCode's extension command documentation last night, and I think I can add it in this PR, after we finish the GUI part.

[Myriad-Dreamin]

The default appearance of select[multiple] is a multi-row box. Even with size: 1, it seems less aesthetically pleasing when displayed inline. Moreover, it requires holding down Ctrl/Command for multiple selections, which seems somewhat cumbersome. So, I temporarily still display the location filter as several input[type="checkbox"]. Any better options here? Would it be worth implementing a combo box with dropdown checkboxes specially for this?

I think it is already nice. Location with [ ] FS [ ] Memory allows us to select both or neither, which looks more flexible. This will not block merging.

About the export command, do we only need to support JSON format for now? I briefly looked at VSCode's extension command documentation last night, and I think I can add it in this PR, after we finish the GUI part.

I personally think export a csv by command is not quite useful, so we don't have to add a format option to the export command. When one makes some scripting, some input in json format is usually better than one in csv format.

[Myriad-Dreamin]

I tested locally. It looks pretty well.