ID |
Date |
Icon |
Author |
Author Email |
Category |
OS |
ELOG Version |
Subject |
68756
|
Tue Mar 6 16:09:05 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" |
This tag does not change the behaviour, but I have noticed that I only have the problem in Chrome and Firefox but not in Internet explorer.
Matej
Stefan Ritt wrote: |
In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put
allow html = 1
into your config file.
Stefan
|
|
Draft
|
Wed Mar 7 15:15:27 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" |
So this is the result in the log file:
Opis: Test č Č
Attachment:
Encoding: HTML
========================================
<p>Test č Č body</p>
This is displayed as
Opis: Test č Č
Test č Č body
Stefan Ritt wrote: |
In the attribe filed, HTML code is not allowed for security reasons. If you want to bypass this (on your own risk), put
allow html = 1
into your config file.
Stefan
Matej Sedej wrote: |
Hello Stefan,
thank you for the reply. The explanation does not solve my problem though.
1) Could you elaborate, why the body text field CORRECTLY writes the character while the attribute fields write and display the HTML code?
2) If I understand you correctly the problem also contradicts your statement: "When an existing elog entry gets shown by the browser, the code is translated back to the character." and is visible in this very post. The subject field writes and displays it incorrectly, while the body text writes and displays it perfectly OK. See: Č č ?
3) We do not use any scripts. If we were to use a script to replace the HTML code with the actual character, the attribute fields would still display È instead of Č. Also, I have no idea how to write such a script. :)
Thanks,
Matej
Stefan Ritt wrote: |
Actually unicode characters are converted by your browser into HTML code (such as Č) where 268 decimal = 10C hex. elog just writes to file what it gets from the browser. When an existing elog entry gets shown by the browser, the code is translated back to the character. Why do you care what is written to the log file? If you use scripts or so to parse your log files, you have to adapt them to correctly decode HTML encoded characters. This is necessary since log files are ASCII and thus encode one charecter in one byte. Your Slovenian characters require two bytes in unicode, so some kind of "special" encoding is necessary.
Stefan
|
|
|
|
68762
|
Thu Mar 15 09:39:20 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" |
To conclude this topic, we sadly can't use the characters č and Č propperly in the application. I have marked the problems in the screenshots below:
red square - the user name is changed immediately after saving. It is also written into the log file in the attribute "Lovec" preset as $long_name. This cannot be displayed correctly even when using HTML and the text tag.
orange sqare - This appears in translated menus and in the attribute "Prea" where the options are listed. The character is written correctly in the translation and the log file, but is displayed incorrectly as È and è.
pink square - After using the script on this attribute "Opis" to insert the html text tag the field correctly displays the characters. The minor problem remains when exporting this to a csv file where the html text tag remains.
I have no idea what effort it would take to change the ANSI background of the application to UNICODE and I can't really expect you to do this. On the other hand most modern applications go through this step eventually, mostly because of the Chinese and the Russian markets.
Thanks again for the otherwise great product, I guess we'll have to start using letters c and C instead. Best reagards,
Matej |
Attachment 1: elog.png
|
|
Attachment 2: logfile.png
|
|
68763
|
Fri Mar 16 12:46:09 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" |
I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.
Matej Sedej wrote: |
To conclude this topic, we sadly can't use the characters č and Č propperly in the application. I have marked the problems in the screenshots below:
red square - the user name is changed immediately after saving. It is also written into the log file in the attribute "Lovec" preset as $long_name. This cannot be displayed correctly even when using HTML and the text tag.
orange sqare - This appears in translated menus and in the attribute "Prea" where the options are listed. The character is written correctly in the translation and the log file, but is displayed incorrectly as È and è.
pink square - After using the script on this attribute "Opis" to insert the html text tag the field correctly displays the characters. The minor problem remains when exporting this to a csv file where the html text tag remains.
I have no idea what effort it would take to change the ANSI background of the application to UNICODE and I can't really expect you to do this. On the other hand most modern applications go through this step eventually, mostly because of the Chinese and the Russian markets.
Thanks again for the otherwise great product, I guess we'll have to start using letters c and C instead. Best reagards,
Matej
|
|
Attachment 1: Screen_Shot_2018-03-16_at_13.00.25_.png
|
|
68764
|
Fri Mar 16 14:12:04 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" |
Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current POC log resides.
Stefan Ritt wrote: |
I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.
|
|
68765
|
Fri Mar 16 14:35:05 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" |
Easiest is to install the Cywgin environment (www.cygwin.com) and there select the C compiler package which installs also "make".
Matej Sedej wrote: |
Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current POC log resides.
Stefan Ritt wrote: |
I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.
|
|
|
68766
|
Fri Mar 16 15:39:17 2018 |
| Matej Sedej | matej.sedej@gmail.com | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" |
Phew, made it, sort of. Had to copy the contents of the mxml folder from an older version, the folder was empty in this git. I also had to change the SSL to 0 and then it compiled without errors plus I had to copy the cygwin1.dll to the folder to make the service run.
So yes, I can confirm that manually inputting the Č in the attribute field now works correctly. Excellent! This solves the pink problem then. Any similar solutions for the red and orange ones?
Thanks,
Matej
Stefan Ritt wrote: |
Easiest is to install the Cywgin environment (www.cygwin.com) and there select the C compiler package which installs also "make".
Matej Sedej wrote: |
Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current POC log resides.
Stefan Ritt wrote: |
I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.
|
|
|
|
68767
|
Fri Mar 16 17:51:30 2018 |
| Stefan Ritt | stefan.ritt@psi.ch | Bug report | Windows | ELOG V3.1.3-fd7 | Re: Problem with special character "č" |
Pink problem: Yes the CSV export preserves the html tags, but what to do. CSV files are plain text with 8 bit characters. Unicode characgers have to be represented with more than one byte. So either HTML encoding or some special escape sequence encoding. If you like the second better than the first, I'm sure you find some conversion program on the internet.
Orange problem: No clue how C is converted to E. Maybe depends on the encoding of your browser? There is a elog option "charset = xxx" with which you can play.
Matej Sedej wrote: |
Phew, made it, sort of. Had to copy the contents of the mxml folder from an older version, the folder was empty in this git. I also had to change the SSL to 0 and then it compiled without errors plus I had to copy the cygwin1.dll to the folder to make the service run.
So yes, I can confirm that manually inputting the Č in the attribute field now works correctly. Excellent! This solves the pink problem then. Any similar solutions for the red and orange ones?
Thanks,
Matej
Stefan Ritt wrote: |
Easiest is to install the Cywgin environment (www.cygwin.com) and there select the C compiler package which installs also "make".
Matej Sedej wrote: |
Great news Stefan! Please pardon my ignorance, but I was not able to "make" it. I have no idea how to run this on Windows where the current POC log resides.
Stefan Ritt wrote: |
I had time to look at the problem in detail. I found that a &#xxx; sequence is not correctly identified as HTML code, and thus displayed in plain when used in an attribute. I fixed it in the current git revision and now it looks find in attribute (see attachment). Can you give it a try? Please note that you need "Allow HTML = 1" in your config file.
|
|
|
|
|