search

openlilylib / LO-ly

LibreOffice-LilyPond extension
13 stars 6 forks source link

Special characters in include statements are not handled correctly #27

Closed edgar79 closed 5 years ago

edgar79 commented 5 years ago

Hello,

I tested the include statements on Linux, macOS, and Windows again and found that there is a bug when special characters like german ä are in the path using Windows.

The function WindowsCommand writes a batch file, and i assume the file encoding is UTF-8 but cmd.exe seems to expect codepage 850.

I am searching for a workaround…

Cheers, Hannes E. Schäuble

uliska commented 5 years ago

Are you sure that the problem is not on the side of LilyPond itself? IIRC LilyPond (or rather GhostScript) doesn't like Umlauts in filenames at all.

KlausBlum commented 5 years ago

Hello back,

I've found and tested a workaround: https://www.libe.net/Robocopy-Umlaute Hannes is right: By default, .bat and .cmd files expect OEM 850 encoding. But according to the above website, it is possible to select another character set by adding chcp 1252 at the beginning of the batch file. I've tested that and it worked for me (Windows 10). I will modify the windows command to include that.

KlausBlum commented 5 years ago

Merged. Hannes, thanks for reporting that. I didn't know that there was a problem. Still anything missing before we can close the issue?

edgar79 commented 5 years ago

I was just searching for a general solution (cp 1252 covers only Western European languages). I found TextInputStream has the function setEncoding(). I don't yet know if TextOutputStream has getEncoding or setEncoding - but if it has, we could use BatchFileOutputStream.getEncoding() to get the currently used encoding and set this inside the batch file using chcp. A solution like this would cover more languages.

edgar79 commented 5 years ago

I found no reliable way to get the currently used codepage (using LibreOffice Basic) but in the pull request #28 I used TextOutputStream.setEncoding("utf-8") and then chcp 65001 which should be the corresponding codepage. Additionally I inserted a few Chr(13) to get it working again.

edgar79 commented 5 years ago

Hello @KlausBlum , If you test the pull request and if you merge it - could you publish a fixed release?

KlausBlum commented 5 years ago

Hi Hannes, thanks for your work. Really sounds more reliable than what I've found. To be honest, there's pretty much code from Samuel (the original OLy developer) that I don't entirely understand... ;-) Maybe it will take until tomorrow that I find the time, but I will publish a 0.5.10 release.

Cheers, Klaus

edgar79 commented 5 years ago

Hi Klaus, like written in my mail I thank you for all your positive feedback. I think we can close this issue now.

Cheers, Hannes

KlausBlum commented 5 years ago

Hi Hannes, thanks for all your help. Welcome to 0.5.10 ;-) Now let's hit that "Close" button...