Multiple Definition of property in strict mode

[mediamacros]

IE/Edge currently throws an error when using the library due to this declaration...
var formatEscapes = {
"�": "\--",
"�": "\---",
" ": "~",
"\t": "\qquad{}",
"\r\n": "\newline{}",
"\n": "\newline{}"
};

In theory the second one would not even be used on browsers that do allow it but this stops all other JS from working properly after it fires off with this error...

Multiple definitions of a property not allowed in strict mode

This is present in the current version and was discovered in a system using 5.1.1.

[josdejong]

Thanks for reporting @mediamacros . How can I reproduce this issue?

[mediamacros]

I've done a bit more digging. I think this is coming from an encoding issue. Since the characters are being inserted as plain text, if the web server or IDE sets encoding to UTF-8, then those 2 characters resolve as the same. If it is ISO-8859-1 encoded it seems to play far better.

BTW, converting format from UTF-8 to ISO-8859-1 gets this...
"Ð": "\--",
"Ñ": "\---",
Which I assume is also incorrect. Basically if it flips it breaks even worse.

Adding the keys another way (encoding from numeric values?) might be preferable rather than inline non-roman characters, but that seems to be the source of the explosion here. Any minifiers, server oddities, IDEs, etc could potentially create this in the current form if they are writing out to a different encoding.

Thanks.

[josdejong]

I guess we can solve it by replacing the characters with escaped unicode characters.

@dangmai can you get this fixed in the escape-latex library? Would be great!

@mediamacros I still don't know I can reproduce your issue, and hence how to prevent any regression here. Any ideas? We somehow have to check that the code only has valid UTF8 characters or something.

[mediamacros]

I think this may have happened either by the IDE changing the encoding or one of my devs copying and pasting the source from one file to another (with the destination file being UTF-8).

I agree it is somewhat of a special case, but in project work flow not completely out of the question.

[dangmai]

Oh man this is a new one. Yes I think I can fix it in escape-latex by using the code point of the characters instead of relying on the encoding of the file.

[dangmai]

I've published escape-latex 1.2.0 that should fix this issue.

[harrysarson]

PR at #1297.

[josdejong]

Thanks for your fast response @dangmai , looks good 👍

[gwhitney]

I think this is complete, and if so, it should be closed.

[josdejong]

👍