Take character width into account

[aoyama-val]

Apparently the table aligning does not take character width into account.

const { Formatter, CommentPolicy, FracturedJsonOptions, EolStyle } = require('fracturedjsonjs');

// For examples of the options, see
// https://github.com/j-brooke/FracturedJson/wiki/Options
const options = new FracturedJsonOptions();
options.MaxTotalLineLength = 80;
options.MaxInlineComplexity = 1;
options.JsonEolStyle = EolStyle.Crlf;

const formatter = new Formatter();
formatter.Options = options;

// Use Serialize to go from JavaScript data to JSON text.
const inputObj =
[
  { "name": "漢字", "num": 1 },
  { "name": "a", "num": 2 }
]
;
const textFromObj = formatter.Serialize(inputObj);

console.log(textFromObj);

Current result:

Shoud be:

Could we use wcwidth or similar?
https://www.npmjs.com/package/wcwidth
It would be even better if we could select East Asian Ambiguous Width to 1 or 2, since a lot of CJK environments expect it as 2, but Western environments as 1.
http://www.unicode.org/reports/tr11/#Ambiguous
https://www.npmjs.com/package/meaw

[aoyama-val]

Looked into the source code and found formatter.StringLength.
Setting it towcwidth suffices.

const wcwidth = require("wcwidth");
const formatter = new Formatter();
formatter.StringLengthFunc = (str) => wcwidth(str);

This case can be closed.

[j-brooke]

I'm glad you brought this up. I should probably put more about that option in the documentation.

In version 2, the string length function was handled with an enum, and the wide-character libraries were hard dependencies. For version 3, I removed the dependencies on particular packages so that people could manage their own versions, etc., and to keep the code smaller for people who didn't need that feature.

[aoyama-val]

That makes sense 👍 Closing the discussion.