The W3C Internationalization Working Group has just discussed it:
We discussed this in today’s i18n WG meeting, and the consensus was that it’s not likely to cause ambiguity in the context of this document, so we decided to close the issue. Thank you.
—xfq, 2025-08-14
I have a feeling that they are all or mostly Chinese, which can explain why they don’t see the ambiguity, while two non-Chinese persons here do find it that way. And “in the context of this document” means that you have to read enough of it or wholly for ambiguity to go away. That’s not how it supposed to work, IMO.
That’s true for clreq meetings, but this issue was submitted to the i18n WG (Internationalization Working Group). This team is more international.
Typography Gap Misunderstanding Discussion
The team discussed concerns about the term “gap” in typography-related documents potentially being misunderstood. Addison and xfq agreed that the context was likely clear.
—the meeting summary
I believe the Addison here is Addison Phillips, the chair of the i18n WG. He lives in USA.
I’m pretty sure they are all biased into knowing more stuff than regular people (in different senses and fields), hence less likely to agree on the matter.
Just as I’m biased into thinking that Typst language and scripting are very easy, yet a lot of general people with little to no knowledge/context will disagree. Well, if it’s their first non-natural language, then they are biased to say it’s hard, probably even if it were to be Python.
Yeah, knowledge bias definitely exists.
To be honest, I have no idea how big this ambiguity is (for English speakers), but if you want to change it, stronger evidence is required.
(For example, analyzing the proportions in a corpus?)
layout gap:
Sorry, there are no matching records. You may wish to do one of the following:
gap analysis:
ALL FORMS 88
FREQ 88
ENTRIES: 36 TEXTS
So it’s clear that Chinese Layout Gap Analysis means Chinese Layout [Gap Analysis] rather than Chinese [Layout Gap] Analysis?
The new landing page also uses the word gap in an abstract sense.
Indirectly related: How to dynamically label headers in outlines with a counter - #2 by Andrew. The https://typst-doc-cn.github.io/guide/FAQ/heading-numbering-space.html#方法-2-给他-show-成-none hack doesn’t work on outline.entry’s h(0.5em) spacing. But converting to absolute units does trigger the show rule. I don’t know why the way the spacing is defined in Rust changes the fact that one of them is auto-converted to pt and the other is still in em. I just thought that one or the other approach might break. But I guess probably not.
I also wonder if I should create an issue about this. At least the check for caption should be added, so that this wide space is not present right before the fill dots.
No magic here.
h element is created literally.0.5em is resolved and then combined with hanging indent before putting in an h element.