Hi,
it often happens that certain special German characters such as umlauts (ä, ö, ü) in the names of spot colors are displayed with a hyphen in PitStop Inspector.
Such spot color names cannot be renamed to a different spot color name using the ‘Remap spot color’ action. Nothing happens, without an error message.
Why is this the case? And why can't PitStop rename or reassign the spot color name?
However, it works with the ‘Remap Color’ action. Strange.
Here is a an example file:
https://magentacloud.de/s/nCXZEmLJ7sKNknR
Problems with ä, ö, ü in spot color names
Problems with ä, ö, ü in spot color names
- Attachments
-
- Screenshot.png (56.87 KiB) Viewed 494 times
Re: Problems with ä, ö, ü in spot color names
Hi,
I can reproduce. I will investigate internally.
I can reproduce. I will investigate internally.
Loïc Aigon
Enfocus PitStop Product Manager
Enfocus PitStop Product Manager
Re: Problems with ä, ö, ü in spot color names
Hi,
So it appears everything is "fine", let me explain. To be short, names as in spots names are internally converted to Numbers and later decoded to display a glyph. Based on the encoding (Ascii, UTF-8…), the glyph may change as you noticed.
The PDF Spec states that UTF-8 should be used but if the code is not valid in UTF-8, the spec provides no recommendations and that let vendors to decide. Regarding the character code for 0x8A, it will be translated as:
Why is remapping working then? Be cause it uses the correct UTF-8 code when we do:
https://www.compart.com/en/unicode/U+00E4
I am afraid there isn't much we can do here.
So it appears everything is "fine", let me explain. To be short, names as in spots names are internally converted to Numbers and later decoded to display a glyph. Based on the encoding (Ascii, UTF-8…), the glyph may change as you noticed.
The PDF Spec states that UTF-8 should be used but if the code is not valid in UTF-8, the spec provides no recommendations and that let vendors to decide. Regarding the character code for 0x8A, it will be translated as:
- MacRoman encoding says that 0x8A is ä (adieresis).
- WinAnsi encoding says that 0x8A is Š (Scaron)
- PDFDoc encoding says that 0x8A is − (U+2212 minus sign)
Why is remapping working then? Be cause it uses the correct UTF-8 code when we do:
https://www.compart.com/en/unicode/U+00E4
I am afraid there isn't much we can do here.
Loïc Aigon
Enfocus PitStop Product Manager
Enfocus PitStop Product Manager