Hello,
I have to create my first document with turkish characters and I can´t get it to work.
Even if I create a text box and copy a text with turkish characters into it it will show the “normal” character instead of the turkish one on the document.
Most likely this has to do with the font you’re using, and the encoding of the inserted text.
The font need to support the encoding you need for the special characters.
Please note if you try to copy and paste Unicode text it’s not working at all as Designer 7 does not support Unicode.
PlanetPress Suite is a non-Unicode program and is therefore affected by the system code page, especially when dealing with data in a language other than the display language of the application.
First, please make sure that your system locale is set to Turkish. To change it, you need to navigate to:
Settings:
Time and language:
Region:
Related Settings - Additional date, time and regional settings:
I converted the excel file to a UTF-8 CSV file.
Then converted this file in PlanetPress Production with the Encoding Converted Plugin to ISO 8859-9.
Now to the strange part.
When I load this file in Design and switch the style to ISO 8859-9 everythings working.
When I copy text from the same file into a text box that uses the same style, it is not working.
When using text from an external file, the bytes are read as-is and displayed using the configured encoding.
When copy-pasting text, there is a mismatch between the Unicode clipboard format and the code page of the application, which is probably Windows-1252.
In order to use Turkish text in the user interface, the system code page need to be adjusted accordingly, as mentioned earlier in the thread.
Encodings are confusing, so no worries.
Please see the two attached files. The file turkish-utf8.txt contains Turkish encoded in UTF-8, while the file turkish-1254.txt is encoded using the Windows code page for Turkish, Windows-1254.
Using turkish-utf8.txt…
Characters are displayed correctly in Notepad.
You can’t use it as a data file because PlanetPress doesn’t support UTF-8. Special characters are displayed as three characters.
– Selecting Turkish as the data file encoding will not make it work, because the file isn’t encoded in Turkish.
A data selection doesn’t display correctly because of the encoding mismatch.
Using turkish-1254.txt…
Characters are displayed correctly in Notepad only if the system locale is Turkish, as there is no way for Notepad to know from the file’s data which encoding to use.
Regardless of the system locale, it can be used as a data file, provided that the style’s encoding is set to Turkish and uses a font that supports Turkish characters, because PlanetPress does its own magic. Note that this is cosmetic only; internally, the data is still processed as the system locale.
Copy-pasting text from the file to PlanetPress converts the Unicode-encoded Turkish from the text file to the system code page, meaning that special Turkish characters are lost unless the system code page is Turkish. Note that it may work in the Text object editor, don’t get fooled.
Regardless of the data file…
Keyboard input in Turkish only works in the user interface if the system locale is set to Turkish and PlanetPress is configured to use the system code page rather than the user interface language.
Characters are dislayed correctly on the page if the style is properly set.
To summarize…
The data file needs to be encoded using a encoding that supports the Turkish characters and that PlanetPress supports. For maximum compatibility with the operating system, I suggest to use Windows-1254.
For convenience, the Data encoding in the data selector dialog need to be set to the appropriate encoding.
The style that displays Turkish text need to have the appropriate font and encoding.
At design time, the system locale needs to be set to Turkish and PlanetPress configured to use the system locale in order to be able to type special characters.
At run time (e.g. when using the form in Workflow), the system locale shouldn’t have any impact of the data and styles are properly configured.
As for the copy-paste, I was surprised that the above didn’t fix it. I’m pretty sure that it used to work. This I cannot explain without deeper investigation.