Unicode Support

[myogaman]

Hello! I'm trying to do 2 things.

#1 I can't order my character sheet fields without it defaulting to alphabetical
-- I know I can do certain things to help this out (change the first character)

#2 I was thinking I could use Unicode (specificallyl emojis) to help out on this but it doesnt seem to be supported. This is also a bit of an issue as we are playing a modern game set in an international campaign. So without taking a picture of the text, I can't display it in chat.

Will their be unicode support? And will there be a method to manually move character sheet fields?

Thank you!

[Moon Wizard]

There is already UTF-8 support mostly built-in to the system. However, we don't have any plans to support emojis right now.

What characters are you trying to type? Or copy and paste? Can you provide an example?

Regards,
JPG

[myogaman]

Things like Korean (한글 this is the only one I have installed right now), Chinese characters, and Japanese as well. I am mostly just pasting but I tried typing Korean and it didn't work either.

[g0ntzal]

I can't type marked accents directly on FGU but I can paste them with no problems... You can see two lines in the attached screenshot. First one is the result I get typing directly. Second is the result I get if I paste the words from the clipboard.

FGU: Latest version

OS: MacOS 10.15.5
Country code: ES
Keyboard: com.apple.keylayout.Spanish-ISO
Language code: es
Region settings: es_ES

36757

[Moon Wizard]

@myogaman,
I'll have to check with our Carl who built our font system whether Asian characters are supported; and whether the fonts we have support them. It may be either or both.

@g0ntzal,
There's a separate issue where the input string of typed characters provided by Unity does not support certain characters correctly that we are tracking; some of the European character typing issues are most likely related to that.

Regards,
JPG

[pindercarl]

@myogaman,
I'll have to check with our Carl who built our font system whether Asian characters are supported; and whether the fonts we have support them. It may be either or both.

@g0ntzal,
There's a separate issue where the input string of typed characters provided by Unity does not support certain characters correctly that we are tracking; some of the European character typing issues are most likely related to that.

Regards,
JPG

CJK characters are UTF-32 and FGU does not support UTF-32 characters.

[g0ntzal]

CJK characters are UTF-32 and FGU does not support UTF-32 characters.

This is bad news for creating content as GM :(

[pindercarl]

CJK characters are UTF-32 and FGU does not support UTF-32 characters.

John asked me a follow-up about this, so I will clarify. My previous answer was overly simplistic. Our font engine can render any UTF-16 character present in a font. Our default fonts do not include CJK characters. Currently, our text input system only supports Extended ASCII for typing characters. Pasting via the clipboard does not have this limitation.

[LordEntrails]

Enhancement requests can always be added to (or voted on) the Wish List :)
https://fg2app.idea.informer.com/

[tpkurilla]

I'm trying to add the playing card suit symbols (♠♥♦♣) to Fantasy Ground via paste, and it is not working.

Is there something special I need to do? These are UTF-16 codes as far as I'm aware: U+2660, U+2665, U+2666, U+2663

[pindercarl]

I'm trying to add the playing card suit symbols (♠♥♦♣) to Fantasy Ground via paste, and it is not working.

Is there something special I need to do? These are UTF-16 codes as far as I'm aware: U+2660, U+2665, U+2666, U+2663

The font must include those characters. The default font for FGU, NotoSans, does support those characters and I am able to paste them in the chat window and story entries.

[tpkurilla]

The font must include those characters. The default font for FGU, NotoSans, does support those characters and I am able to paste them in the chat window and story entries.

Sadly, I'm not yet using FGU due to some anomalies observed when I was setting up my current DLWW campaign. FGC doesn't seem to support it.

Does anyone know if there is there a way to change a setting to allow it? Or do I just need to wait until I move to FGU?

[pindercarl]

Sadly, I'm not yet using FGU due to some anomalies observed when I was setting up my current DLWW campaign. FGC doesn't seem to support it.

Does anyone know if there is there a way to change a setting to allow it? Or do I just need to wait until I move to FGU?

@tpkurilla, the thread you've found on Unicode support is for FGU, so I thought the question was about that. FGC doesn't support Unicode.

[tpkurilla]

@tpkurilla, the thread you've found on Unicode support is for FGU, so I thought the question was about that. FGC doesn't support Unicode.

Ah, I wanted to make sure I didn't duplicate a thread's question, and didn't notice it was just for FGU.

Thank you for the help in any case.

I suppose it may be time for me to evaluate the state of FGU again.

[tiagocesar]

Hi! As a Portuguese-speaking person, I find it essential to be able to use accents(á, ó, etc). Is there a prediction as to when this will be supported?

[g0ntzal]

As Spanish I understand your point perfectly. It is very unpleasant to create our own stuff in an external editor instead of in FGU directly.

English spoken users seem to be the main target so we must wait for a while...

As a customer I’m divided about my feelings towards FGU. I think is a good tool but it has some disgusting lack of features as real multilingual support or full screen mode on MacOS...

[tiagocesar]

Yeah, I was surprised to learn that, it's an RPG tool, it's kinda obvious it has to have good support for writing. As it is now I also find it a bad experience that I have to use an external editor...

[Moon Wizard]

I'm not understanding this issue you are mentioning.

I enabled Portuguese keyboard support on Windows; and brought up the on-screen keyboard to type as if using that keyboard. It appears that the characters are being entered correctly in FGU.

Regards,
JPG

[Sulimo]

FGU supports accented characters.

As long as the character is in the ISO-8859-1 set, it can be displayed.

It will depend on how your OS handles the characters.

For instance, on US-EN Windows 10, it sometimes requires the use of the Character Map to copy these characters from there to FGU (or from some other app). This is because the English keyboard does not have these characters, they are created by holding ALT+####, for instance ALT+0250 is ú.


I think the Unity Engine is trapping the ALT key (since it is used for the Hotbar as well), so it cannot be used directly in the FGU interface, but copying into a story entry (or other entry) works just fine.

See here, this is from CoreRPG, so should be the same in any layered ruleset.:
https://i.imgur.com/OdFIs5f.png

[Moon Wizard]

Characters outside of ISO-8859-1 can be displayed on FGU, as long as the fonts contain glyphs for those characters. The default font in CoreRPG uses Noto Sans, which does provide glyphs for every standard character.

I have not tested Alt key entry override; but I would not be surprised if Unity game engine does not support that use case.

Regards,
JPG

[g0ntzal]

Problem arises when you type an accented vocal or another combinations where you need to stroke 2 keys to get a character (for example, camión and vergüenza in Spanish or coração and usuário in Portuguese).

FG Classic accepts those special characters but FG Unity doesn't.

[pindercarl]

Problem arises when you type an accented vocal or another combinations where you need to stroke 2 keys to get a character (for example, camión and vergüenza in Spanish or coração and usuário in Portuguese).

FG Classic accepts those special characters but FG Unity doesn't.

Can you walk me through the character combinations? We added ALT-Gr support awhile ago, but this seems like something else.

[Moon Wizard]

That seems to work when I used the on-screen keyboard for Portuguese. Does it work for you if you use the on-screen keyboard?

JPG

[tiagocesar]

I'm not understanding this issue you are mentioning.

I enabled Portuguese keyboard support on Windows; and brought up the on-screen keyboard to type as if using that keyboard. It appears that the characters are being entered correctly in FGU.

Regards,
JPG

I'm using English International (also tried Portuguese) on Mac. Oughta be my OS

[g0ntzal]

On-Screen keyboard is not working for me...

https://www.dropbox.com/s/mv1ir46eo7xgckb/screen_fgu.mov?dl=0

[Moon Wizard]

It must be something specific to the Unity game engine on the Mac; because it seems to work for me on Windows.

Regards,
JPG

[g0ntzal]

A fast search into Unity forum reveals the problem happened on MacOS and Linux for non ASCII characters. They say the issue was solved in 5.1 but I don’t know if it’s true...

[tiagocesar]

A fast search into Unity forum reveals the problem happened on MacOS and Linux for non ASCII characters. They say the issue was solved in 5.1 but I don’t know if it’s true...

Is this something I have to update on my end, or it's part of FGU?

[g0ntzal]

Is this something I have to update on my end, or it's part of FGU?

Não Tiago. Acho que é um problema do Unity mesmo. Vamos ver se já existe uma solução

[Moon Wizard]

We are using Unity 2019.4 LTS version, which is way after v5.1. I've added a ticket to take a deeper look and/or report to Unity after we've had a chance to look after vision/lighting update.

Regards,
JPG

[ShakaSensei]

We are in October and Mac users have the same problem yet. As Spanish Gm I need put unicode characters in words as corazón, así, sí...

[g0ntzal]

We are in October and Mac users have the same problem yet. As Spanish Gm I need put unicode characters in words as corazón, así, sí...

My experience as an FG user tells me that English-speaking customers are more important to SmiteWorks than those who speak another language. It's understandable but painful...

[ShakaSensei]

My experience as an FG user tells me that English-speaking customers are more important to SmiteWorks than those who speak another language. It's understandable but painful...
Very painful 😓

[g0ntzal]

Whenever I'm preparing a game using FGU on my iMac, I press Command + Spacebar in order to write correctly in Spanish. Then I select the text and I paste it on the FGU Story or whatever. It makes the trick but I hate to work so...

[Zacchaeus]

My experience as an FG user tells me that English-speaking customers are more important to SmiteWorks than those who speak another language. It's understandable but painful...

That's pretty harsh. Smitewoks isn't a multi-million dollar company with a staff of a couple of hundred. It's a small company with finite resources and it must focus on more general things than benefit every user rather than divert resources to (possibly) solve a problem that a tiny number of users are experiencing. Whilst I'm sure that the majority of users are English speaking it's completely unfair to say that they are more important than any other language speaking users.

[g0ntzal]

First of all, no offense intended, Zacchaeus.

I wrote "(...) it's understandable (...)" because of I can understand what kind of business is SmiteWorks (small company focused on D&D with a majority of English-speaking customers). That's the reality. As a non-English speaking CUSTOMER I know that my needs won't be addressed by SmiteWorks in the same way like those of English-speaking customers. And that, from a personal perspective, is certainly painful.

[ShakaSensei]

That's pretty harsh. Smitewoks isn't a multi-million dollar company with a staff of a couple of hundred. It's a small company with finite resources and it must focus on more general things than benefit every user rather than divert resources to (possibly) solve a problem that a tiny number of users are experiencing. Whilst I'm sure that the majority of users are English speaking it's completely unfair to say that they are more important than any other language speaking users.
200 workers and nobody can’t fix this problem? It’s just unicode letters man!In spanish language, is very important.

[Zacchaeus]

200 workers and nobody can’t fix this problem? It’s just unicode letters man!In spanish language, is very important.

I said it isn't a company with a staff of 200. I imagine if this was something that was easy to do, and the resources to do it were available, it would be done.

[Moon Wizard]

Unfortunately, it's not something we can address directly ourselves.

We use the Unity 3D engine to provide cross-platform support for FGU to run on multiple platforms. I did actually look into this about 3 months ago, and found that this is a Mac-specific issue and that the Unity engine does not pass the correct characters to our application. Since I do not have a native keyboard for every language, I used the on-screen keyboards for both Mac and Windows. It works fine on Windows, though the on-screen keyboard does not seem to work on Mac (and I'm not sure if native keyboards exhibit same issue but assume it does). We even updated to the latest LTS version of Unity engine over the summer hoping to capture any fixes for Linux and Mac support that had been added by Unity. The Unity game engine provides all information on keyboard/mouse input, so we can only use what we're given there.

To be clear, our development team is currently 4 people (1.5 client, 1.5 ruleset, 1 server); so we are definitely constrained in what we can accomplish across the vast variety of configurations in the world, which is why we are using the Unity engine to provide cross-platform support.

If you have a Windows machine, it appears to work without issues on that platform.

Regards,
JPG

[CannedMan]

I am having a similar, but different issue, as per my conversation with Zacchaeus on Discord earlier today; I was directed to this thread to see if there were any answers to be found here. I will, for simplicity quote the original message:


I have a question about font and character support. The text in the image on the left is Roboto Medium in LibreOffice Writer and the text to the right is a screenshot showing the same text using the builder and the extension ‘Roboto (Revised) Font Extension’ v. 1.0.

I use a lot of typographically sound typesetting (if you will) when I enter text. For example, as evidenced above, I always set proper fractions (if the font supports it), and I use both no-break space (U+a0) and narrow no-break space (U+202f) when needed. One place where using U+202f is very useful, is when setting fractions: If there is no access to setting specific character styles (as with HTML/CSS or a word processor), then when using the fraction slash (fraction slash at U+2044, not the solidus at U+2f), a space is needed between the whole number and the numerator, otherwise the numerator will be superscripted as well; therefore U+202f (or U+feff: zero width no-break space) should be used, so as to not split the number shown.

As can be seen above, the font Roboto should support proper fractions (though I will be the first to admit it doesn’t look very nice in that font), and of course the various spaces are supported as well, as evidenced by the second screenshot (U+feff is problematic, though). Why then is it, that when I add characters like U+202f (which I have to copy-paste) and fraction slashes (likewise), they are not rendered correctly?

P. S.: I recommend opening the images to see them properly.

58948
Image showing the same text displayed in my word processor and in FGU.

58949
Image listing all the different spaces, their code points, and their rendering.



Using the default font causes the same issue:


Using the standard font yields the same problems (see screenshot). Further, it proved problematic to use it across different rendering sizes (I use 1440p, some players 1080p and one player 4k).
Here is the screenshot.

58950

The vertical line in front of the fraction is my cursor.


Given that the rendering doesn’t work as it should regardless of font choice (I have also tested with Noto in LibreOffice Writer; it works fine), I suspect this is an underlying issue. This is suggested not only be the above things, but also by things such as hard space (Alt+255) being replaced by a soft space.

[LordEntrails]

Is the font and all the characters you are looking to use compliant with ISO 8859-1?
FG does not support all Unicode characters, only a small subset of them. It is more detailed than just 8859-1, but I could not find where Moon details exactly what the encoding requirements are. If I find them after looking some more, I'll come back and post.

[LordEntrails]

So here are looks to a bit more info on the supported fonts in FGU. Note that the rest of the posts in the threads I link below are NOT relevant, as in general they are talking about issues related to the FGC to FGU update. But the posts I'm linking themselves have two details that might be related to your issue
1) as mentioned is ISO 8859-1 and 2) the other is about UTF-8 encoding impacting 8859-1.

https://www.fantasygrounds.com/forums/showthread.php?54871-Font-Character-issues-in-FGU&p=485371&viewfull=1#post485371
https://www.fantasygrounds.com/forums/showthread.php?65770-Special-character-showing-strangely-in-FGU-Calendar&p=576791&viewfull=1#post576791

[CannedMan]

As pointed out in conversation on Discord, this may be relevant: Font Character Issues in FGU (The other thing to consider is that Fantasy Grounds is very set upon an ISO format.
https://www.fantasygrounds.com/forums/showthread.php?54871-Font-Character-issues-in-FGU&p=485371&viewfull=1#post485371).

[Edit:
I just realised that the first post you linked to, is the same as the one I came across. I will read through the second one tomorrow to see if I can learn more. I will post once I have studied it. Thanks!]

[CannedMan]

I believe this may be the key discovery here (your second link):

Never mind. I was able to recreate.

It's actually not the font. It's an interesting problem with encodings that is different between FGC and FGU. With FGC, strings are limited to ISO-8859-1, which is always a single byte per letter; while in FGU, strings are UTF-8, which are variable numbers of bytes depending on letter. Lua doesn't have any special handling for multi-byte letter representation, so when we pull the first two "letters" of the string in Lua, it's only getting the first two bytes. This means that it won't get the right information if any of the characters in the first two letters of the string are multi-byte in the UTF-8 string. I'll have to see if I can detect UTF-8 specific multi-byte characters in this specific case.

Regards,
JPG
So what can be done?

[Trenloe]

So what can be done?
The comments after the post you link mentioned adding a helper function into the ruleset, which was added 3 years ago. But, there's no context to this, what's your specific use case?

[CannedMan]

The comments after the post you link mentioned adding a helper function into the ruleset, which was added 3 years ago. But, there's no context to this, what's your specific use case?

This, as per post #40 (https://www.fantasygrounds.com/forums/showthread.php?58976-Unicode-Support&p=698374&viewfull=1#post698374):


I am having a similar, but different issue, as per my conversation with Zacchaeus on Discord earlier today; I was directed to this thread to see if there were any answers to be found here. I will, for simplicity quote the original message:


I have a question about font and character support. The text in the image on the left is Roboto Medium in LibreOffice Writer and the text to the right is a screenshot showing the same text using the builder and the extension ‘Roboto (Revised) Font Extension’ v. 1.0.

I use a lot of typographically sound typesetting (if you will) when I enter text. For example, as evidenced above, I always set proper fractions (if the font supports it), and I use both no-break space (U+a0) and narrow no-break space (U+202f) when needed. One place where using U+202f is very useful, is when setting fractions: If there is no access to setting specific character styles (as with HTML/CSS or a word processor), then when using the fraction slash (fraction slash at U+2044, not the solidus at U+2f), a space is needed between the whole number and the numerator, otherwise the numerator will be superscripted as well; therefore U+202f (or U+feff: zero width no-break space) should be used, so as to not split the number shown.

As can be seen above, the font Roboto should support proper fractions (though I will be the first to admit it doesn’t look very nice in that font), and of course the various spaces are supported as well, as evidenced by the second screenshot (U+feff is problematic, though). Why then is it, that when I add characters like U+202f (which I have to copy-paste) and fraction slashes (likewise), they are not rendered correctly?

P. S.: I recommend opening the images to see them properly.

58948
Image showing the same text displayed in my word processor and in FGU.

58949
Image listing all the different spaces, their code points, and their rendering.



Using the default font causes the same issue:


Using the standard font yields the same problems (see screenshot). Further, it proved problematic to use it across different rendering sizes (I use 1440p, some players 1080p and one player 4k).
Here is the screenshot.

58950

The vertical line in front of the fraction is my cursor.


Given that the rendering doesn’t work as it should regardless of font choice (I have also tested with Noto in LibreOffice Writer; it works fine), I suspect this is an underlying issue. This is suggested not only be the above things, but also by things such as hard space (Alt+255) being replaced by a soft space.

[LordEntrails]

So if I understand, you have a theme extension that changes the fonts and then you have a module with typographical characters that are not showing properly in FG?

If that is the case, you should upload your extension and module and give us simple steps to reproduce. Or if it's not, just simple steps to reproduce the error. It is not clear to me what it is you are trying to do and how to test it.

[Zacchaeus]

So if I understand, you have a theme extension that changes the fonts and then you have a module with typographical characters that are not showing properly in FG?

If that is the case, you should upload your extension and module and give us simple steps to reproduce. Or if it's not, just simple steps to reproduce the error. It is not clear to me what it is you are trying to do and how to test it.

They're trying to get fractions to show in a number field instead of decimals (at least that's what the convo in Discord was about). Since number fields won't take fractions - no matter what font is used; or what else you do - there isn't a way to do what they are wanting.

[LordEntrails]

They're trying to get fractions to show in a number field instead of decimals (at least that's what the convo in Discord was about). Since number fields won't take fractions - no matter what font is used; or what else you do - there isn't a way to do what they are wanting.
Ah. Yes, fractions are characters, not numbers (at least within a font). So I would not expect them to work in a number field. Thanks for clarifying :)

[CannedMan]

Yes, that was the problem discussed on Discord (this time; I have talked about type there previously), but the original post here was concerning characters that are available in the font, but regardless of this not displaying as they should in FGU. Even having some space characters not displaying as expected (U+205f for example), definitely shows that something wonky is going on. I am having the same issue running the server without the Robot extension (thus using the default Noto family). The two matters are related.

[LordEntrails]

Yes, that was the problem discussed on Discord, but the original post here was concerning characters that are available in the font, but regardless of this not displaying as they should in FGU. Even having some space characters not displaying as expected (U+205f for example), definitely shows that something wonky is going on. I am having the same issue running the server without the Robot extension (thus using the default Noto family). The two matters are related.
I think our inaccurate replies show that you are not clearly communicating in a way we understand exactly what the problem is. Can you provide a concise set of steps we can follow to duplicate the issue? Is there a module or campaign that we would need to do this?

[CannedMan]

I take it from this the the description provided in post 40 and quoted in post 46 did not describe the problem sufficiently, correct? I would have thought the pictures*– if not the text, which does reference specific Unicode code points*– made clear what my problem was.

I have further described this issue in several comments on Discord, for example:

U+205f: post 1 (https://discord.com/channels/274582899045695488/692116657858150410/995287662585991188), post 2 (https://discord.com/channels/274582899045695488/692116657858150410/1205597022975955025) many months later.
Further elaborating on which characters are directly supported by Windows (https://discord.com/channels/274582899045695488/692116657858150410/1205600361302335498)


Please let me know if the issue*– by referencing the mentioned posts, the linked comments, and last, but not least, the images provided*– is clearly stated. In short: Despite Noto supporting all characters I am trying to type, as evidenced by usage of the same font in LibreOffice, several desired characters are not displaying correctly in FGU. I am trying to figure out why this is and how to solve it. I do believe it is a bug, and as mentioned previously, I do believe the point made in the thread ‘Font Character Issues in FGU’ (https://www.fantasygrounds.com/forums/newreply.php?do=postreply&t=58976) identifies the cause.

[LordEntrails]

I don't get it, and have no idea how to start up FG and replicate the issue*. But, since I'm only a user like you, you have probably already done more than I can do. At this point you may want to open a ticket with tech support and see if they can help.

* What I was hoping for was something like;

Start a new CoreRPG campaign.
Create a story
Type "xyz" and then while holding the right alt key type 205 from the number pad, hit enter
Repeat in Libre Office or MS Word and see that the character show does not match in FG.

[Moon Wizard]

As noted by @LordEntrails, an exact step by step is what is needed to look at this.
If you are looking to add characters via module or script, it will be a different answer; than if you are entering directly.

Regards,
JPG

[CannedMan]

Here is a step by step to produce exactly the undesired result here discussed:

In FGU:

Type the sentence: ‘eller kanskje ein tvipel/-pæl?’.
Replace the hyphen with U+2011 (non-breaking hyphen):

Find the character at amp-what.com (https://www.amp-what.com/unicode/search/u%2B2011).
Copy and paste the character.
Even though I know with absolute certainty that characters are copied sans any formatting when using the click-function on amp-what.com, I still (for the sake of this demo), pasted it into Notepad, then copied it there and pasted it into FGU.


In Notepad

Copy the text from FGU and paste it into Notepad.

In LibreOffice Writer

Set font to Noto Sans.
Copy the text from Notepad and paste it into LibreOffice, twice for the following point:
To demonstrate clearly that the same character has been carried over from FGU via Notepad to Writer, press Alt + X next to the character to display its hex code. If correct, it should display U+2011.



The following image shows the results displaying the same text in all three programmes. Notice that only FGU is unable to display the character. The LibreOffice example clearly demonstrates that it is renderable in Noto Sans, the font used by FGU. The Notepad example further clearly demonstrates that the character is renderable even in a monospaced font, which is to be expected, as U+2011 belongs to the General Punctuation block (U+2000–U+206F). I again refer back to the previously mentioned finding which is the best clue I have been able to find so far to what the cause of the problem is.

60632

If this is not reproducable at your ends, I’m at my wits end at what to do about this and how to solve this. I am no programmer, only a typophilic Dungeon Master wanting my texts to look as best they can with the tools available.

P. S.: In case any Norwegians read this: Yes, I have corrected the typo in the text. ;-)

[Jiminimonka]

Here is a step by step to produce exactly the undesired result here discussed:

In FGU:

Type the sentence: ‘eller kanskje ein tvipel/-pæl?’.
Replace the hyphen with U+2011 (non-breaking hyphen):

Find the character at amp-what.com (https://www.amp-what.com/unicode/search/u%2B2011).
Copy and paste the character.
Even though I know with absolute certainty that characters are copied sans any formatting when using the click-function on amp-what.com, I still (for the sake of this demo), pasted it into Notepad, then copied it there and pasted it into FGU.



In Notepad

Copy the text from FGU and paste it into Notepad.


In LibreOffice Writer

Set font to Noto Sans.
Copy the text from Notepad and paste it into LibreOffice, twice for the following point:
To demonstrate clearly that the same character has been carried over from FGU via Notepad to Writer, press Alt + X next to the character to display its hex code. If correct, it should display U+2011.



The following image shows the results displaying the same text in all three programmes. Notice that only FGU is unable to display the character. The LibreOffice example clearly demonstrates that it is renderable in Noto Sans, the font used by FGU. The Notepad example further clearly demonstrates that the character is renderable even in a monospaced font, which is to be expected, as U+2011 belongs to the General Punctuation block (U+2000–U+206F). I again refer back to the previously mentioned finding which is the best clue I have been able to find so far to what the cause of the problem is.

60632

If this is not reproducable at your ends, I’m at my wits end at what to do about this and how to solve this. I am no programmer, only a typophilic Dungeon Master wanting my texts to look as best they can with the tools available.

P. S.: In case any Norwegians read this: Yes, I have corrected the typo in the text. ;-)

I just pasted that text into FG and it looks OK to me but I might be missing the point - is it the long hyphen you are after?

60635
OK - I see - yeah it draws a little box in FGU.

[damned]

it means that character is not present in the font...

[CannedMan]

For your information, U+2011 is apparently replaced by U+2d here on the forum, so make sure (if you try to replicate it) that you do not copy the text in my post; it does not contain the correct character.

[Jiminimonka]

Continues on Discord (because the forum is being mean to me) https://discord.com/channels/274582899045695488/692116657858150410/1231732925196931072

[pindercarl]

Here is a step by step to produce exactly the undesired result here discussed:

In FGU:

Type the sentence: ‘eller kanskje ein tvipel/-pæl?’.
Replace the hyphen with U+2011 (non-breaking hyphen):

Find the character at amp-what.com (https://www.amp-what.com/unicode/search/u%2B2011).
Copy and paste the character.
Even though I know with absolute certainty that characters are copied sans any formatting when using the click-function on amp-what.com, I still (for the sake of this demo), pasted it into Notepad, then copied it there and pasted it into FGU.


In Notepad

Copy the text from FGU and paste it into Notepad.

In LibreOffice Writer

Set font to Noto Sans.
Copy the text from Notepad and paste it into LibreOffice, twice for the following point:
To demonstrate clearly that the same character has been carried over from FGU via Notepad to Writer, press Alt + X next to the character to display its hex code. If correct, it should display U+2011.



The following image shows the results displaying the same text in all three programmes. Notice that only FGU is unable to display the character. The LibreOffice example clearly demonstrates that it is renderable in Noto Sans, the font used by FGU. The Notepad example further clearly demonstrates that the character is renderable even in a monospaced font, which is to be expected, as U+2011 belongs to the General Punctuation block (U+2000–U+206F). I again refer back to the previously mentioned finding which is the best clue I have been able to find so far to what the cause of the problem is.

60632

If this is not reproducable at your ends, I’m at my wits end at what to do about this and how to solve this. I am no programmer, only a typophilic Dungeon Master wanting my texts to look as best they can with the tools available.

P. S.: In case any Norwegians read this: Yes, I have corrected the typo in the text. ;-)

As it turns out, U+2011 is not supported by Noto Sans. It is supported by Noto Sans Japanese and Korean. Those support much larger character sets which is evident as their files are 14 times larger. LibreOffice and Notepad likely have a fallback font for missing glyphs. FGU has a fallback, but only for missing fonts. Not for individual glyphs. I'd recommend adding this as a feature request: https://www.fantasygrounds.com/featurerequests/featurerequests.php

[CannedMan]

How do I understand this, considering the above discussion?
60888
This is the very same font, but in GIMP (with all its font limitations), though here inserting the fraction slash (U+2044) changes the rendering of the fraction to an actual fraction.

Method:

In FGU, type the number, and insert a proper fraction slash (U+2044) by copy-pasting after the numerator, follow by typing the denominator.
Repeat the same thing over the screenshot in GIMP.


As displayed in the screenshot, the font is Noto Sans Medium, the same one used by FGU (as far as I can tell; it is not the regular font weight used in this window; that was too skinny).

[LordEntrails]

How do I understand this, considering the above discussion?
60888
This is the very same font, but in GIMP (with all its font limitations), though here inserting the fraction slash (U+2044) changes the rendering of the fraction to an actual fraction.

Method:

In FGU, type the number, and insert a proper fraction slash (U+2044) by copy-pasting after the numerator, follow by typing the denominator.
Repeat the same thing over the screenshot in GIMP.


As displayed in the screenshot, the font is Noto Sans Medium, the same one used by FGU (as far as I can tell; it is not the regular font weight used in this window; that was too skinny).
Because Gimp is using a ligature to combine the 3 characters into one (or 3 different characters using super and sub scripts) and FG doesn't have the ability to do that.

Ligature (writing) - Wikipedia (https://en.wikipedia.org/wiki/Ligature_(writing))
Also see 2.1 of Note 28 of the Unicode standard; UTN28-PlainTextMath-v3.pdf (unicode.org) (https://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.pdf)