Update floatreftarget.lua

[cparks-ucla]

Description

Working around using ut8.codepoint in split_longtable_start since that was causing a stack overflow with rather large tables.

Checklist

I have (if applicable):

• referenced the GitHub issue this PR closes
• updated the appropriate changelog in the PR
• ensured the present test suite passes
• added new tests
• created a separate documentation PR in Quarto's website repo and linked it to this PR

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[cscheid]

Thanks for the PR, but we're going to need more information than that to be able to accept it, especially if it's in a performance-sensitive setting.

[cparks-ucla]

When I was rendering a document with some large tables I ran into this error:

Error running filter [sic]/Positron/resources/app/quarto/share/filters/main.lua:
...ams/Positron/resources/app/quarto/share/filters/main.lua:23309: stack overflow (string slice too long)

Enumerating over the codepoints with utf8.codes instead of passing the whole big string to ut8.codepoint seemed like a reasonable workaround. But, I couldn't say if that is worse for performance.

[cscheid]

How big is that table?

[cparks-ucla]

177 x 32. It isn't really readable for other reasons, just didn't expect it to crash the renderer.