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.

Sign up for GitHub

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

Jump to bottom

Handle non-ascii characters #177

Closed
jfly opened this issue Oct 2, 2014 · 8 comments
Closed

Handle non-ascii characters #177

jfly opened this issue Oct 2, 2014 · 8 comments

Comments

@jfly
Copy link
Contributor

jfly commented Oct 2, 2014

Sébastien just tried to generate scrmables for "Sébra Open", and the pdf title was "Sébra Open".
@jfly
Copy link
Contributor Author

jfly commented Oct 16, 2014

Olivér just tried to use a password that contains an accented character, and he couldn't open it. I don't know if this is a bug on our side, or (less likely) a bug with his zip program (total commander).

@campos20
Copy link
Member

campos20 commented Dec 7, 2016

I think that if #159 is implemented, it may fix this as well.

@campos20
Copy link
Member

When encoding for Internationalization files were in ISO-8859-1, everything worked fine. Setting to UTF-8, this very same problem happened in FMC translation.

ISO
captura de tela de 2017-11-14 20-27-49

UTF8
captura de tela de 2017-11-14 20-27-55

@jfly
Copy link
Contributor Author

jfly commented Nov 15, 2017

@campos20, yikes! Let's continue this discussion over on #242. This issue is for non-ascii characters in the filename, whereas you're running into trouble with non-ascii characters in the pdfs.

@jfly jfly mentioned this issue Nov 15, 2017
Merged
@campos20
Copy link
Member

campos20 commented Mar 23, 2019 •
edited

I try this from time to time with some new idea, but it's a lot of chained stuff to dig in, but I think I found something perhaps useful. When I open http://localhost:2014 (let's say legacy) and save the .html to my computer, this is what I get

<!DOCTYPE html>
<!-- saved from url=(0188)http://localhost:2014/scramble-legacy/#competitionName=T%C3%A9st&rounds=i('eventID'-'333'_'round'-'1'_'scrambleSetCount'-1_'scrambleCount'-5_'extraScrambleCount'-2_'copies'-1)!&version=1.0 -->
<html slick-uniqueid="3"><head><meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>WCA Scramble Program</title>

There's a charset=windows-1252. I tried to find where this was generated, but I got nothing yet. I believe charset should be set to utf-8.

Edit to include some details that I've tried: I've put System.out.println in some places for debug and it looks like TNoodle's backed already get the distorted version. It's a bit strange how it's not distorted on the downloaded .zip, but's it's distorted if you put a println here.

campos20 added a commit to campos20/tnoodle that referenced this issue Mar 23, 2019
@campos20
windows-1252 to utf-8 for PDFs fix thewca#177
3e0a07e
@campos20 campos20 mentioned this issue Mar 23, 2019
Closed
@campos20
Copy link
Member

This code "fixed" encoding for PDFs, using legacy ui

@gregorbg
Copy link
Member

This is fixed for the PDF library and file encodings now, but interestingly the ZIP filenames can be broken under certain circumstances. Keeping this open to continue investigation

@gregorbg gregorbg mentioned this issue Jan 20, 2020
Closed
@gregorbg
Copy link
Member

Fixed as part of the Kotlin migrations -- strings are handled consistently as UTF-8 there and the translation files were converted accordingly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@jfly @gregorbg @campos20