[Geoserver-users] Right to left language (Arabic, Persian) problem in SLD Legend

Hi,
I am new here. I have seen that geoserver can save sld files which includes
Arabic characters as title of each role but it does not create any legends
for it. this is an example of sld file
BaftFarsoode.sld
<http://osgeo-org.1560.x6.nabble.com/file/n5294270/BaftFarsoode.sld&gt;

geoserver can save it and validate it but it does not create any legend for
it. Is there any way to fix it? or if you need more information please let
me know and I'll provide them or oven if you give me some hints how I can
help fixing this problem?
thanks very much for your help

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

This is the log File when I save style with unicode characters. Any
suggestion?

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294386.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

This is the log File when I save style with unicode characters. Any
suggestion?

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294387.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

What is the character encoding used by your GeoServer instance? Is your server using UTF-8?

Text files containing UTF-8 byte sequences that are written to a server that does not support these UTF-8 byte sequences might be corrupted when unsupported characters are replaced with other bytes as placeholders. This could make files valid for the server encoding but invalid UTF-8.

If I open your SLD in Firefox 49, it correctly detects the encoding as UTF-8 but reports the following error:
http://osgeo-org.1560.x6.nabble.com/file/n5294270/BaftFarsoode.sld

XML Parsing Error: not well-formed
Location: http://osgeo-org.1560.x6.nabble.com/file/n5294270/BaftFarsoode.sld
Line Number 14, Column 18: <Title>￿��� ������</Title>
-----------------^

This is consistent with the exception you report (copying from Nabble as I do not see the log in the mailing list email):

INFO | jvm 1 | 2016/11/04 22:49:36 | java.lang.RuntimeException: com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException: Invalid byte 2 of 2-byte UTF-8 sequence.
INFO | jvm 1 | 2016/11/04 22:49:36 | at org.geotools.styling.SLDParser.parseSLD(SLDParser.java:430)

Kind regards,
Ben.

On 05/11/16 08:26, am2222 wrote:

This is the log File when I save style with unicode characters. Any
suggestion?

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

Thanks dear Ben,
Unicode of geoserver is set up Utf-8 on settings,the part that you mentioned is exacly a text which is written in Persian,what do you suggest to fix it?Is there any way to fix it?or sld files does not support Such a languages?
Thanks

···

On Nov 4, 2016 11:40 PM, “Ben Caradoc-Davies-2 [via OSGeo.org]” <[hidden email]> wrote:

What is the character encoding used by your GeoServer instance? Is your
server using UTF-8?

Text files containing UTF-8 byte sequences that are written to a server
that does not support these UTF-8 byte sequences might be corrupted when
unsupported characters are replaced with other bytes as placeholders.
This could make files valid for the server encoding but invalid UTF-8.

If I open your SLD in Firefox 49, it correctly detects the encoding as
UTF-8 but reports the following error:
http://osgeo-org.1560.x6.nabble.com/file/n5294270/BaftFarsoode.sld

XML Parsing Error: not well-formed
Location: http://osgeo-org.1560.x6.nabble.com/file/n5294270/BaftFarsoode.sld
Line Number 14, Column 18: ���� ������
-----------------^

This is consistent with the exception you report (copying from Nabble as
I do not see the log in the mailing list email):

INFO | jvm 1 | 2016/11/04 22:49:36 | java.lang.RuntimeException:
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException:
Invalid byte 2 of 2-byte UTF-8 sequence.
INFO | jvm 1 | 2016/11/04 22:49:36 | at
org.geotools.styling.SLDParser.parseSLD(SLDParser.java:430)

Kind regards,
Ben.

On 05/11/16 08:26, am2222 wrote:

This is the log File when I save style with unicode characters. Any
suggestion?


Ben Caradoc-Davies <[hidden email]>
Director
Transient Software Limited <http://transient.nz/>
New Zealand


Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


Geoserver-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geoserver-users


If you reply to this email, your message will be added to the discussion below:
http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294392.html
To unsubscribe from Right to left language (Arabic,Persian) problem in SLD Legend, click here.
NAML

Hi,
The intresting part is that I opened sld file in notepad++ and change
Encoding to UTF-8-BOM and it worked fine. thanks

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294412.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

GeoServer can always output UTF-8 because Java supports UTF-8. Problems can arise when GeoServer tries to save files such as your SLD on a platform with an encoding that does not support all the characters in the file. This can cause files to be corrupted.

What is the platform on which you are running GeoServer, and what is its character encoding? I guess you are on Windows if you are using Notepad++, but what what version and character encoding? Also, what GeoServer version?

My guess is that the SLD file is being transformed into the platform encoding when saved (best effort), and where characters cannot be represented, they are being replaced with placeholders, corrupting the file. Your Notepad++ findings seem to confirm this. Notepad++ might not transform the file, instead saving it as raw bytes.

You might be able to change the behaviour of GeoServer by starting the JVM with the option:

-Dfile.encoding=UTF8

to force Java to read and write your SLD as UTF-8. Where to put it depends on how you start GeoServer. This may have other side effects if you have files stored in another encoding. My preferred solution is to use UTF-8 everywhere.

I am using Linux (Debian unstable) with locale en_GB.utf8 (that is, UTF-8 as the platform encoding). I tested the GeoServer release data directory (on master (2.11-SNAPSHOT)) by changing the Title of the first Rule of the population style to فارسی (see attached screenshot). Wikipedia tells me that this is Farsi for Farsi. I was able save and load the style, and the USA Population layer preview continued to work as expected. The GeoServer web SLD editor honours right-to-left display for the Farsi text.

I also examined the corresponding popshade.sld file and found that the Title was updated correctly to <Title>فارسی</Title>, both in a text editor that honours right-to-left when displaying text, and at a console that does not (to check raw ordering).

Kind regards,
Ben.

On 05/11/16 11:57, am2222 wrote:

Thanks dear Ben,
Unicode of geoserver is set up Utf-8 on settings,the part that you
mentioned is exacly a text which is written in Persian,what do you suggest
to fix it?Is there any way to fix it?or sld files does not support Such a
languages?
Thanks

On Nov 4, 2016 11:40 PM, "Ben Caradoc-Davies-2 [via OSGeo.org]" <
ml-node+s1560n5294392h97@anonymised.com> wrote:

What is the character encoding used by your GeoServer instance? Is your
server using UTF-8?

Text files containing UTF-8 byte sequences that are written to a server
that does not support these UTF-8 byte sequences might be corrupted when
unsupported characters are replaced with other bytes as placeholders.
This could make files valid for the server encoding but invalid UTF-8.

If I open your SLD in Firefox 49, it correctly detects the encoding as
UTF-8 but reports the following error:
http://osgeo-org.1560.x6.nabble.com/file/n5294270/BaftFarsoode.sld

XML Parsing Error: not well-formed
Location: http://osgeo-org.1560.x6.nabble.com/file/n5294270/
BaftFarsoode.sld
Line Number 14, Column 18: <Title>���� ������</Title>
-----------------^

This is consistent with the exception you report (copying from Nabble as
I do not see the log in the mailing list email):

INFO | jvm 1 | 2016/11/04 22:49:36 | java.lang.RuntimeException:
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException:

Invalid byte 2 of 2-byte UTF-8 sequence.
INFO | jvm 1 | 2016/11/04 22:49:36 | at
org.geotools.styling.SLDParser.parseSLD(SLDParser.java:430)

Kind regards,
Ben.

On 05/11/16 08:26, am2222 wrote:

This is the log File when I save style with unicode characters. Any
suggestion?

--
Ben Caradoc-Davies <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5294392&i=0>>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

------------------------------------------------------------------------------

Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Geoserver-users mailing list
[hidden email] <http:///user/SendEmail.jtp?type=node&node=5294392&i=1>
https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-
problem-in-SLD-Legend-tp5294270p5294392.html
To unsubscribe from Right to left language (Arabic,Persian) problem in SLD
Legend, click here
<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5294270&code=YXNkNTZ5dUB5YWhvby5jb218NTI5NDI3MHwzMzgwOTUyOTA=&gt;
.
NAML
<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html!nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers!nabble%3Aemail.naml-instant_emails!nabble%3Aemail.naml-send_instant_email!nabble%3Aemail.naml&gt;

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294398.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

population-style.png

And in answer to your original question, GetLegendGraphic also seems to work on my UTF-8 system (see attached legend).

Kind regards,
Ben.

On 06/11/16 10:45, Ben Caradoc-Davies wrote:

I am using Linux (Debian unstable) with locale en_GB.utf8 (that is,
UTF-8 as the platform encoding). I tested the GeoServer release data
directory (on master (2.11-SNAPSHOT)) by changing the Title of the first
Rule of the population style to فارسی (see attached screenshot).
Wikipedia tells me that this is Farsi for Farsi. I was able save and
load the style, and the USA Population layer preview continued to work
as expected. The GeoServer web SLD editor honours right-to-left display
for the Farsi text.

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

legend.png

Hi Ben,

You did not perhaps notice the mail telling that the SLD file encoding should be set to UTF-8 with BOM and then it started to work.
I think that it is good to accept BOM but it should not be required.

Jukka Rahkonen


Lähettäjä: Ben Caradoc-Davies
Lähetetty: ‎5.‎11.‎2016 23:52
Vastaanottaja: am2222
Kopio: geoserver-users@lists.sourceforge.net
Aihe: Re: [Geoserver-users] Right to left language (Arabic, Persian) problem in SLD Legend

GeoServer can always output UTF-8 because Java supports UTF-8. Problems
can arise when GeoServer tries to save files such as your SLD on a
platform with an encoding that does not support all the characters in
the file. This can cause files to be corrupted.

What is the platform on which you are running GeoServer, and what is its
character encoding? I guess you are on Windows if you are using
Notepad++, but what what version and character encoding? Also, what
GeoServer version?

My guess is that the SLD file is being transformed into the platform
encoding when saved (best effort), and where characters cannot be
represented, they are being replaced with placeholders, corrupting the
file. Your Notepad++ findings seem to confirm this. Notepad++ might not
transform the file, instead saving it as raw bytes.

You might be able to change the behaviour of GeoServer by starting the
JVM with the option:

-Dfile.encoding=UTF8

to force Java to read and write your SLD as UTF-8. Where to put it
depends on how you start GeoServer. This may have other side effects if
you have files stored in another encoding. My preferred solution is to
use UTF-8 everywhere.

I am using Linux (Debian unstable) with locale en_GB.utf8 (that is,
UTF-8 as the platform encoding). I tested the GeoServer release data
directory (on master (2.11-SNAPSHOT)) by changing the Title of the first
Rule of the population style to فارسی (see attached screenshot).
Wikipedia tells me that this is Farsi for Farsi. I was able save and
load the style, and the USA Population layer preview continued to work
as expected. The GeoServer web SLD editor honours right-to-left display
for the Farsi text.

I also examined the corresponding popshade.sld file and found that the
Title was updated correctly to فارسی, both in a text
editor that honours right-to-left when displaying text, and at a console
that does not (to check raw ordering).

Kind regards,
Ben.

On 05/11/16 11:57, am2222 wrote:

Thanks dear Ben,
Unicode of geoserver is set up Utf-8 on settings,the part that you
mentioned is exacly a text which is written in Persian,what do you suggest
to fix it?Is there any way to fix it?or sld files does not support Such a
languages?
Thanks

On Nov 4, 2016 11:40 PM, “Ben Caradoc-Davies-2 [via OSGeo.org]” <
ml-node+s1560n5294392h97@…4613…> wrote:

What is the character encoding used by your GeoServer instance? Is your
server using UTF-8?

Text files containing UTF-8 byte sequences that are written to a server
that does not support these UTF-8 byte sequences might be corrupted when
unsupported characters are replaced with other bytes as placeholders.
This could make files valid for the server encoding but invalid UTF-8.

If I open your SLD in Firefox 49, it correctly detects the encoding as
UTF-8 but reports the following error:
http://osgeo-org.1560.x6.nabble.com/file/n5294270/BaftFarsoode.sld

XML Parsing Error: not well-formed
Location: http://osgeo-org.1560.x6.nabble.com/file/n5294270/
BaftFarsoode.sld
Line Number 14, Column 18: ���� ������
-----------------^

This is consistent with the exception you report (copying from Nabble as
I do not see the log in the mailing list email):

INFO | jvm 1 | 2016/11/04 22:49:36 | java.lang.RuntimeException:
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException:

Invalid byte 2 of 2-byte UTF-8 sequence.
INFO | jvm 1 | 2016/11/04 22:49:36 | at
org.geotools.styling.SLDParser.parseSLD(SLDParser.java:430)

Kind regards,
Ben.

On 05/11/16 08:26, am2222 wrote:

This is the log File when I save style with unicode characters. Any
suggestion?


Ben Caradoc-Davies <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5294392&i=0>>
Director
Transient Software Limited <http://transient.nz/>
New Zealand


Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


Geoserver-users mailing list
[hidden email] <http:///user/SendEmail.jtp?type=node&node=5294392&i=1>
https://lists.sourceforge.net/lists/listinfo/geoserver-users


If you reply to this email, your message will be added to the discussion
below:
http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-
problem-in-SLD-Legend-tp5294270p5294392.html
To unsubscribe from Right to left language (Arabic,Persian) problem in SLD
Legend, click here
<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5294270&code=YXNkNTZ5dUB5YWhvby5jb218NTI5NDI3MHwzMzgwOTUyOTA=>
.
NAML
<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294398.html
Sent from the GeoServer - User mailing list archive at Nabble.com.


Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users


Ben Caradoc-Davies <ben@…6881…>
Director
Transient Software Limited <http://transient.nz/>
New Zealand

Jukka,

I agree that the BOM should not be required. Looking at the original email provided by the reporter, the SLD appears corrupt, as it contains a malformed UTF-8 byte sequence, confirmed by inspection of the actual byres. Editing this file with Notepad++ likely re-encodes it. I still suspect a platform encoding problem.

Kind regards,
Ben.

On 06/11/16 11:13, Rahkonen Jukka (MML) wrote:

Hi Ben,

You did not perhaps notice the mail telling that the SLD file encoding should be set to UTF-8 with BOM and then it started to work.
I think that it is good to accept BOM but it should not be required.

Jukka Rahkonen
________________________________
Lähettäjä: Ben Caradoc-Davies<mailto:ben@anonymised.com>
Lähetetty: ‎5.‎11.‎2016 23:52
Vastaanottaja: am2222<mailto:asd56yu@anonymised.com>
Kopio: geoserver-users@lists.sourceforge.net<mailto:geoserver-users@lists.sourceforge.net>
Aihe: Re: [Geoserver-users] Right to left language (Arabic, Persian) problem in SLD Legend

GeoServer can always output UTF-8 because Java supports UTF-8. Problems
can arise when GeoServer tries to save files such as your SLD on a
platform with an encoding that does not support all the characters in
the file. This can cause files to be corrupted.

What is the platform on which you are running GeoServer, and what is its
character encoding? I guess you are on Windows if you are using
Notepad++, but what what version and character encoding? Also, what
GeoServer version?

My guess is that the SLD file is being transformed into the platform
encoding when saved (best effort), and where characters cannot be
represented, they are being replaced with placeholders, corrupting the
file. Your Notepad++ findings seem to confirm this. Notepad++ might not
transform the file, instead saving it as raw bytes.

You might be able to change the behaviour of GeoServer by starting the
JVM with the option:

-Dfile.encoding=UTF8

to force Java to read and write your SLD as UTF-8. Where to put it
depends on how you start GeoServer. This may have other side effects if
you have files stored in another encoding. My preferred solution is to
use UTF-8 everywhere.

I am using Linux (Debian unstable) with locale en_GB.utf8 (that is,
UTF-8 as the platform encoding). I tested the GeoServer release data
directory (on master (2.11-SNAPSHOT)) by changing the Title of the first
Rule of the population style to فارسی (see attached screenshot).
Wikipedia tells me that this is Farsi for Farsi. I was able save and
load the style, and the USA Population layer preview continued to work
as expected. The GeoServer web SLD editor honours right-to-left display
for the Farsi text.

I also examined the corresponding popshade.sld file and found that the
Title was updated correctly to <Title>فارسی</Title>, both in a text
editor that honours right-to-left when displaying text, and at a console
that does not (to check raw ordering).

Kind regards,
Ben.

On 05/11/16 11:57, am2222 wrote:

Thanks dear Ben,
Unicode of geoserver is set up Utf-8 on settings,the part that you
mentioned is exacly a text which is written in Persian,what do you suggest
to fix it?Is there any way to fix it?or sld files does not support Such a
languages?
Thanks

On Nov 4, 2016 11:40 PM, "Ben Caradoc-Davies-2 [via OSGeo.org]" <
ml-node+s1560n5294392h97@anonymised.com> wrote:

What is the character encoding used by your GeoServer instance? Is your
server using UTF-8?

Text files containing UTF-8 byte sequences that are written to a server
that does not support these UTF-8 byte sequences might be corrupted when
unsupported characters are replaced with other bytes as placeholders.
This could make files valid for the server encoding but invalid UTF-8.

If I open your SLD in Firefox 49, it correctly detects the encoding as
UTF-8 but reports the following error:
http://osgeo-org.1560.x6.nabble.com/file/n5294270/BaftFarsoode.sld

XML Parsing Error: not well-formed
Location: http://osgeo-org.1560.x6.nabble.com/file/n5294270/
BaftFarsoode.sld
Line Number 14, Column 18: <Title>���� ������</Title>
-----------------^

This is consistent with the exception you report (copying from Nabble as
I do not see the log in the mailing list email):

INFO | jvm 1 | 2016/11/04 22:49:36 | java.lang.RuntimeException:
com.sun.org.apache.xerces.internal.impl.io.MalformedByteSequenceException:

Invalid byte 2 of 2-byte UTF-8 sequence.
INFO | jvm 1 | 2016/11/04 22:49:36 | at
org.geotools.styling.SLDParser.parseSLD(SLDParser.java:430)

Kind regards,
Ben.

On 05/11/16 08:26, am2222 wrote:

This is the log File when I save style with unicode characters. Any
suggestion?

--
Ben Caradoc-Davies <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=5294392&i=0>>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

------------------------------------------------------------------------------

Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
_______________________________________________
Geoserver-users mailing list
[hidden email] <http:///user/SendEmail.jtp?type=node&node=5294392&i=1>
https://lists.sourceforge.net/lists/listinfo/geoserver-users

------------------------------
If you reply to this email, your message will be added to the discussion
below:
http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-
problem-in-SLD-Legend-tp5294270p5294392.html
To unsubscribe from Right to left language (Arabic,Persian) problem in SLD
Legend, click here
<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5294270&code=YXNkNTZ5dUB5YWhvby5jb218NTI5NDI3MHwzMzgwOTUyOTA=&gt;
.
NAML
<http://osgeo-org.1560.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html!nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers!nabble%3Aemail.naml-instant_emails!nabble%3Aemail.naml-send_instant_email!nabble%3Aemail.naml&gt;

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294398.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

Dear Ben,
Sorry for my late answer,
Well As you guessed I am on windows, But I have no idea how to find windows
encoding. Can you please let me know how to report it?

I checked the title in geoserver and it is unreadable
<Title>ط¨ط§ظپطھ ظپط±ط³ظˆط¯ظ‡</Title>
in fact it must be
<Title>بافت فرسوده</Title>
But in legend it works and it is readable,

org.png <http://osgeo-org.1560.x6.nabble.com/file/n5294891/org.png&gt;

Well, do you think problem is still because of windows encoding? I can
easily write Persian and Arabic with it. Is there any extra thing which I
must set up?
thanks

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294891.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

This is my new sld, Persian texts are not readable using GeoServers Style
Editor but It creates legend image and texts are readable in image, I can
edit it using notepad++ not Geoservers SLD editor.

BaftFarsoode.sld
<http://osgeo-org.1560.x6.nabble.com/file/n5294892/BaftFarsoode.sld&gt;

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5294892.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

I suspect that your problem is caused by your platform encoding. The evidence that I have is that Farsi works on a UTF-8 platform when written via the web interface, but does not work for you.

This StackExchange post suggests setting the Windows environment variable JAVA_TOOL_OPTIONS to "-Dfile.encoding=UTF8":
http://stackoverflow.com/questions/9842134/setting-java-opts-globally-on-windows

Please try setting this variable and reboot to restart the GeoServer service. This change should affect all Java on your system.

I am not a Windows user, but there are others on this list who are and may be able to provide better advice for your Windows version.

Kind regards,
Ben.

On 09/11/16 10:07, am2222 wrote:

Dear Ben,
Sorry for my late answer,
Well As you guessed I am on windows, But I have no idea how to find windows
encoding. Can you please let me know how to report it?

I checked the title in geoserver and it is unreadable
<Title>ط¨ط§ظپطھ ظپط±ط³ظˆط¯ظ‡</Title>
in fact it must be
<Title>بافت فرسوده</Title>
But in legend it works and it is readable,

org.png <http://osgeo-org.1560.x6.nabble.com/file/n5294891/org.png&gt;

Well, do you think problem is still because of windows encoding? I can
easily write Persian and Arabic with it. Is there any extra thing which I
must set up?
thanks

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

well.It worked as you said. But is there any way to fix this issue using
geoserver's installation?maybe during installation it configures this
parameter?

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5295143.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

On 11/11/16 02:20, am2222 wrote:

well.It worked as you said. But is there any way to fix this issue using
geoserver's installation?maybe during installation it configures this
parameter?

Great! Thank you for reporting back. To confirm, you set the Windows environment variable JAVA_TOOL_OPTIONS to "-Dfile.encoding=UTF8"?

The problem is that the GeoServer installer has no business adjusting global Windows settings. This setting might not be suitable for all users because it will change the behaviour of other Java applications. What we can do is document this fix so that users can find the solution more easily.

Kind regards,

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

Ben,
thinking out loud, would it make sense to add those settings in the startup
scripts of the windows version?

Cheers
Andrea

···

On Thu, Nov 10, 2016 at 8:34 PM, Ben Caradoc-Davies <ben@anonymised.com> wrote:

On 11/11/16 02:20, am2222 wrote:

well.It worked as you said. But is there any way to fix this issue using
geoserver’s installation?maybe during installation it configures this
parameter?

Great! Thank you for reporting back. To confirm, you set the Windows
environment variable JAVA_TOOL_OPTIONS to “-Dfile.encoding=UTF8”?

The problem is that the GeoServer installer has no business adjusting
global Windows settings. This setting might not be suitable for all
users because it will change the behaviour of other Java applications.
What we can do is document this fix so that users can find the solution
more easily.

Kind regards,


Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/>
New Zealand


Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi


Geoserver-users mailing list
Geoserver-users@anonymised.com.382…sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime

@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313

fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

AVVERTENZE AI SENSI DEL D.Lgs. 196/2003

Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.


Andrea,

if you mean adding -Dfile.encoding=UTF8 to the JVM command line, I think that is a good idea, but I would defer to the experience of users of the Windows version. Are there use-cases in which it is desirable to leave the file.encoding property unset? Setting this as the default behaviour would likely improve the experience of users with a non-UTF8 default encoding.

Kind regards,
Ben.

On 11/11/16 09:32, Andrea Aime wrote:

Ben,
thinking out loud, would it make sense to add those settings in the startup
scripts of the windows version?

Cheers
Andrea

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand

Hi,
Yes exactly what I did was setting the Windows
environment variable JAVA_TOOL_OPTIONS to "-Dfile.encoding=UTF8"

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Right-to-left-language-Arabic-Persian-problem-in-SLD-Legend-tp5294270p5295255.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

On Thu, Nov 10, 2016 at 9:41 PM, Ben Caradoc-Davies <ben@anonymised.com>
wrote:

Andrea,

if you mean adding -Dfile.encoding=UTF8 to the JVM command line, I think
that is a good idea, but I would defer to the experience of users of the
Windows version.

That's what I meant, yes. Unfortunately I also don't have Windows
experience to share...

Are there use-cases in which it is desirable to leave the file.encoding
property unset? Setting this as the default behaviour would likely improve
the experience of users with a non-UTF8 default encoding.

Eh, I'm not sure.

Cheers
Andrea

--

GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

*AVVERTENZE AI SENSI DEL D.Lgs. 196/2003*

Le informazioni contenute in questo messaggio di posta elettronica e/o
nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il
loro utilizzo è consentito esclusivamente al destinatario del messaggio,
per le finalità indicate nel messaggio stesso. Qualora riceviate questo
messaggio senza esserne il destinatario, Vi preghiamo cortesemente di
darcene notizia via e-mail e di procedere alla distruzione del messaggio
stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso,
divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od
utilizzarlo per finalità diverse, costituisce comportamento contrario ai
principi dettati dal D.Lgs. 196/2003.

The information in this message and/or attachments, is intended solely for
the attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act
(Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection
Code).Any use not in accord with its purpose, any disclosure, reproduction,
copying, distribution, or either dissemination, either whole or partial, is
strictly forbidden except previous formal approval of the named
addressee(s). If you are not the intended recipient, please contact
immediately the sender by telephone, fax or e-mail and delete the
information in this message that has been received in error. The sender
does not give any warranty or accept liability as the content, accuracy or
completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of
e-mail transmission, viruses, etc.

-------------------------------------------------------

Thanks for the confirmation.

On 11/11/16 19:15, am2222 wrote:

Yes exactly what I did was setting the Windows
environment variable JAVA_TOOL_OPTIONS to "-Dfile.encoding=UTF8"

--
Ben Caradoc-Davies <ben@anonymised.com>
Director
Transient Software Limited <http://transient.nz/&gt;
New Zealand