error rendering on Windows laptop with home directory name in Chinese #8530
Comments
cscheid
added
the
triaged-to
|
Thanks for the report @paciorek ! It seems the codepage use is 936 on this computer. Quarto check does return Can you update to Quarto 1.4 latest stable release and run @dragonstyle do you still have local windows 11 with codepage 936 available ? Otherwise, I'll try to set one up. |
|
Hi, have very similar issue. I updated quarto and it doesn't read my codepage. |
|
@rpbartczuk what is you username here ? |
|
I saw a similar error on a Japanese version of Windows (user name contains multibyte characters). I think they (Pandoc?) are trying to interpret a non-UTF-8 string as UTF-8 and not interpreting the path correctly. |
|
I am able to reproduce an error when I place the path to the It's likely that the code page isn't be displayed because if there is a render exception, we clear the code page from the cache (where it is read). I'm guessing this is causing the cached code page to disappear, and perhaps the check command is using that cached value rather than computing it. |
cderv
removed
the
triaged-to
|
This will reproduce in pure pandoc when the pandoc executable is placed within a unicode character path on a file system with non-english code page: test.lua function Pandoc(doc)
package.path = ""
require("foo")
endtest.md Command C:\Users\ct\你好>pandoc.exe test.md -L test.lua |
|
(cc @tarleb) The issue here is that Lua's Those confuse |
|
@cderv Charles and I are thinking that we should run the Windows test suite on a non-standard code page, even if we only do it once a week or so. The root cause here is that we're not actually seeing the behavior regress on these code pages, and we'd like to prevent it in the future. |
It makes sense, I can add nightly run for that special usage. (We could also run it for each pre-release tag created). Is this just different codepage or also some path tweaking with special character ? We can sync directly and I'll add to the CI updates to do for 1.5. |
We currently don't think we will be able to fully support Quarto installed on a path with non-ascii characters (it's a combination of Lua, Pandoc, and Windows bugs that we simply can't work around in generality right now). But we believe that there might be more bugs lurking if we were to even run the test suite on non-standard code pages, and we would like to support that use case well. So we should start fixing the simpler cases first. |
|
Work in progress here: |
|
The work in progress addresses the most core issues with the following configuration:
|
Bug description
I'm trying to help a student who seems to have the same problem on Windows reported in issue #4103 .
(Let me know if I should reopen that issue instead.)
We've run the commands suggested there at the end the thread by @cderv and here are the results. Any suggestions that I can I try with the student?
Steps to reproduce
Rendering any basic Quarto document causes the problem.
Expected behavior
One should see the rendered doc.
Actual behavior
Your environment
Quarto check output
The text was updated successfully, but these errors were encountered: