wierd comma behavior

[KraXen72]

sample:
(try minifying and formatting)

{
	"title": "PF2022",
	"type": "rod",
	"cwd": "[RECACTED][RECACTED][RECACTED][RECACTED][RECACTED]",
	"slug": "[RECACTED][RECACTED][RECACTED][RECACTED][RECACTED][RECACTED]",
	"tourxml": "Rod/PF/PF2022/vtour/tour.xml",
	"root_relative_tourxml": "/Rod/PF/PF2022/vtour/tour.xml",
	"i18n": {
		"sk": {
			"title": "[RECACTED] [RECACTED] A POHODU V ROKU 2022 Vám praje [RECACTED] a [RECACTED]",
			"scene_A": {
				"title": "Medovníkové [RECACTED] v BIBIANE",
				"hsA"  : "Badián"                           ,
				"hsB"  : "Klinček"                           ,
				"hsC"  : "Fenikel"                           ,
				"hsD"  : "Škorica"                           ,
				"hsE"  : "Aníz"                             ,
				"hsF"  : "Muškátový orech"
			},
			"scene_C": {"title": "Dunajské rameno"},
			"scene_D": {"title": "Chopok (2024 m.n.m.)"},
			"scene_J": {"title": "BECKOV a [RECACTED] [RECACTED]"},
			"scene_DD": {"title": "Artikulárny kostol v Hronseku"},
			"scene_B": {
				"title": "Vitráže Vincenta HLOŽNÍKA, výstava návrhov"
			},
			"helpbox": {"author": " "}
		}
	}
}

[j-brooke]

Thanks for reporting this. I've reproduced the behavior in the VSCode version (based on JavaScript). It doesn't happen in the web version (based on .NET). I suspect it's an issue with the fullwidth-character library I'm using.

I won't be able to get to this right away. But as a workaround, if you're using the VSCode version, try changing the setting String Width Policy to CharacterCount.

[j-brooke]

I'm going to try transferring this issue to FracturedJsonVSC since, according to my testing, it only affects the Visual Studio Code version.

[j-brooke]

Here's what's going on:

The Unicode annex that deals with East Asian Width categorizes characters into a few groups to describe their east Asian width characteristics. One of those categories is "ambiguous". Several Latin characters with diacritics are classified as ambiguous, including some of the ones in the bug reproduction text.

The library I'm using in version 3.1.0 is treating those characters as two spaces wide, but in typical western fonts they're renders as one space wide, which is throwing off the justification logic.

The spec says:

Ambiguous characters behave like wide or narrow characters depending on the context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably, they should be treated as narrow characters by default.

My plan is:

• Leave StringWidthPolicy=CharacterCount alone.
• Change StringWidthPolicy=EastAsianFullWidth to treat ambiguous characters as narrow.
• Add a new option - sometime like StringWidthPolicy=EastAsianFullWidthWideAmbiguous - that treats ambiguous characters as wide.

I would leave StringWidthPolicy=EastAsianFullWidth as the default.

My hope is that this provides most users with the desired behavior without needing to adjust the settings, while still allowing people to use the current behavior. I welcome any input on this plan. (It'll probably be a few weeks before I get to implementing it.)

[KraXen72]

sounds good

[j-brooke]

Fixed in version 3.1.1.