Jump to content
You must now use your email address to sign in [click for more info] ×

German capital sharp S is not handled correctly by the "All Caps" option


Recommended Posts

On 8/17/2021 at 12:46 PM, Sean P said:

Hi Christoph,

Unfortunately we don't have access to this font and I'm currently unable to find any others containing a Capital Sharp S Stylistic Set.

Would it be possible for you to attach the font used to our internal Dropbox using the link below please?
https://www.dropbox.com/request/bwL7AQjhyDwYf0qZB2r7

Hi Sean P,

I have uploaded something for you. But please remove it after you have tried it out.

Greetings,
Christoph

Link to comment
Share on other sites

On 8/18/2021 at 9:38 PM, LibreTraining said:

You gave me hope there for a moment, but that appears to do the same thing as LibreOffice - the sharp s is converted to two uppercase S characters - so again the stylistic set replacement fails.

But it is nice to know that Upper Case command does actually convert characters to upper case. :-)

In my opinion, it should not make any difference whether I really convert a text to upper case letters, in which case the stylistic set "German Capital Sharp S" works as expected, or whether I use the "All Caps" button to only display a text in upper case letters.
The result for the display is the same and should behave the same, right?

Or asked the other way round, what reason should there be for it to behave differently?

Link to comment
Share on other sites

2 minutes ago, Christoph Müller said:

Or asked the other way round, what reason should there be for it to behave differently?

Perhaps because the Font is designed to work one way, but not the other? It is important to consider that modern fonts are programs, too, and must support the function you're trying to use.

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.4.1, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.4.1

Link to comment
Share on other sites

On 8/23/2021 at 4:19 AM, Christoph Müller said:

In my opinion, it should not make any difference whether I really convert a text to upper case letters, in which case the stylistic set "German Capital Sharp S" works as expected, or whether I use the "All Caps" button to only display a text in upper case letters.
The result for the display is the same and should behave the same, right?

Or asked the other way round, what reason should there be for it to behave differently?

The problem is a combination of how the font is designed and how AD works.

The AllCaps button fails because it does not actually convert the characters to uppercase, it just displays the uppercase version of the character. In FF DIN the uppercase version is the SS character. If the font instead made the uppercase version the Capital Sharp S, then it would work.

Or the font could make the uppercase glyph change based on which language is selected...hmmm is there a separate language code for Swiss German?...that would be needed for that to work.

The Upper Case command fails because it converts to SS which is two S characters not the correct code point. So again the stylistic set replacement fails. This could work if the proper character was used in the replacement. Affinity would need to fix this.

If the font used ẞ by default the AllCaps would work. The easiest solution for you is to replace that glyph or find another font that does. Lots of DIN clones out there.

Maybe I can help.

Link to comment
Share on other sites

  • 2 weeks later...
On 8/18/2021 at 12:45 PM, Christoph Müller said:

I am not sure. I still think it's a bug in Affinity.

On the unicode.org page there is actually an FAQ article on this topic: https://unicode.org/faq/casemap_charprop.html#11

Briefly, it says that in German it is historically the case that a small sharp S is converted into a double capital S. That's why it's the standard in Unicode. But it also says that there may be the alternative of converting the small sharp S into a real capital sharp S.

In the DIN font, the character "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" is defined as "SS" by default.

Accordingly, converting to uppercase in Affinity Designer from a "U+00DF ß LATIN SMALL LETTER SHARP S" to a "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" works correctly. If I enter "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" directly, "SS" is also displayed. This is also correct.

But now comes where I think the bug is:

Activating the stylistic set "German Capital Sharp S" basically does nothing other than switch an alternative appearance of the character "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" to the real capital sharp S (ẞ).

Thus, whenever a "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" is displayed with the stylistic set "German Capital Sharp S" activated, Affinity Designer should always display a real capital sharp S (ẞ). 
It should not matter whether the "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" was entered manually or was created by a conversion to capital letters.

However, it only works when "U+1E9E ẞ LATIN CAPITAL LETTER SHARP S" is entered directly. When converting a lowercase sharp S to uppercase, "SS" is still displayed.

Accordingly, I think it is a bug that the stylistic set "German Capital Sharp S" is not applied after converting to capital letters. Possibly this also applies to all stylistic sets.

Greetings,
Christoph

Actually, Affinity will apply the stylistic set after converting to capitals. The issue is that the capital conversion does not produce U+1E9E. It produces a pair of S (U+0053) instead. The stylistic set does not affect these.

It's unfortunate that this result is not what you want, but I'm not convinced that Affinity is doing anything wrong. The FAQ you cite confirms that the pair-of-S conversion is still the Unicode default, and other apps also use it. That's probably because so many fonts don't define U+1E9E, and capitalisation is not font-specific.  If you know your font has a good definition of U+1E9E, you need to put it in manually.

 

Link to comment
Share on other sites

On 8/18/2021 at 8:22 PM, LibreTraining said:

Ligatures are an OpenType substitution (for the most part) where it is normal to keep the underlying characters.
But I do not see why AllCaps would do that - the user wants All Caps - that is not an OpenType substitution.
I do see any reason to not replace the characters (to avoid situations like this if nothing else).

Maybe I am just used to apps like LibreOffice and Word where All Caps and Toggle Case actually replace the characters.
Which makes more sense to me.

The reason for converting to capitals at draw time is so it can be switched on or off by text styles. For example, you might want a header style to be in ALL CAPS. Text styles shouldn't change the underlying text. It shouldn't cause any problems because OpenType features are applied to the ALL CAPS representation, and not to the underlying characters. As others have said, if you do want to change the underlying characters you can use the menu options that do that. It makes no difference to the result, because both methods use the same capitals conversion. (Which in this case maps U+00DF to U+0053 U+0053 and not to U+1E9E.)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.