Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible bug in line break trie data #29

Open
toptensoftware opened this issue Aug 20, 2020 · 0 comments
Open

Possible bug in line break trie data #29

toptensoftware opened this issue Aug 20, 2020 · 0 comments

Comments

@toptensoftware
Copy link

I was just going through cleaning up my version of this code that I ported to C# and noticed a possible problem with the way the trie data is generated for the line break data.

See this line of code

if ((type != null) && (rangeType !== type)) {

Seems this code is trying to coalesce consecutive ranges with the same class into a single trie.setRange call. The problem is that it's checking for a change of class, but not that the ranges are consecutive and without gaps.

Shouldn't that line read something like this:

    if (((type != null) && (rangeType !== type)) || parseInt(rangeStart, 16) != parseInt(end, 16) + 1)

Also, it seems the UnicodeTrieBuilder already coalesces runs so this isn't even necessary. I reduced it to this:

  var re = /^([0-9A-F]+)(?:\.\.([0-9A-F]+))?\s*;\s*(.*?)\s*#/gm
  var m;
  while (m = re.exec(data))
  {
    var from = parseInt(m[1], 16);
    var to = m[2] === undefined ? from : parseInt(m[2], 16);
    var prop = m[3];

    lineBreakClassesTrie.setRange(from, to, LineBreakClass[prop], true);
  }

Unfortunately none of this resolves any of those 30 non-passing tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant