German "Umlaute" (ä, ö, ü) are missing in Ruffle's device font

[Amseog]

Describe the bug

First of all: I truly, truly appreciate your work which helps to save a big part of Internet history!

I use several SWFs that are in German language. I noticed that in most of these SWFs, the unique German characters "ä", "ö", "ü" and "ß" are not displayed correctly in Ruffle, which, unfortunately ruins the respective words.

Maybe there is a way that Ruffle can incorporate a different "font" than Noto Sans (which, I think, it currently uses to simulate the "Device Font" option in Flash) -- i.e., a font that includes more non-English characters?

Thank you!

Expected behavior

I expected the German letters to be displayed correctly. :)

Affected platform

Self-hosted version

Operating system

Windows 10

Browser

Google Chrome Browser

Additional information

I use Nightly Ruffle Build 2022-02-03.

[Amseog]

I see that this is covered in #1862 -- but I wanted to reiterate that this would be really appreciated!

[ousia]

@Amseog,

what Ruffle lacks is the ability to display fonts from the OS. The embedded device font is only a workaround.

After having generated some PDF documents over the years (and converting others intto SWF format), I think it is a good practice to embed fonts in the file itself. (This doesn’t mean that the implementation of the feature described in #1862 is a much requested and needed one for non-English SWF files.)

BTW, ß may be a unique Ger,man character, but ä, ö and ü are used in other languages.

[Amseog]

Thank you, @ousia, for your comment and technical clarification. Also, you are right about the "ä, ö, ü" argument; obviously, I called them German Umlaute because that's the context of my own experience. But yes, let's just call them "Umlaute" then.

Regarding your other statement: I am pretty certain that a very large percentage of Ruffle users don't create their own SWF files so that they can simply embed the fonts when working with a .FLA. Many of us employ SWFs that have been created throughout a decade of web creation. So, in all bluntness, I think that telling people to just "embed" fonts in their files is a moot argument.

Correct me if I am wrong, but it should not create such a hassle for the Ruffle backend to just embed a device font that includes more characters? I mean, if you've been using "Noto Sans" so far, just democratically select a different sans-serif font with a moderate set of characters?

Not least as I have noticed that it's been requested in this repository over and over again, I personally wanted to support the relevance of this request. :)

Just my two cents, thank you all very much for your voluntary work in creating this awesome plugin.

[ousia]

@Amseog,

many thanks for your reply.

My comment about font embedding meant a practice. Of course, it makes sense only when generating the file, not when using it. It was just a general comment, which may be simply ignored (sorry, but I saw a decade of work partially going to waste because of a missing font in the final document).

I see your point in adding more characters to the embedded device font. I’m not against that. I would even partially agree with it. But this approach is only a workaround (Ruffle should be able to deploy OS fonts) and it also generates other issues.

Embedding a fake device font with more characters is a compromise, because Ruffle gets bigger (because of the bigger font file size).

After that comes the question of which characters should be added to the fake device font.

1. Only characters with diacritical marks for western European languages?
2. Why not all Latin characters required for European languages?
3. And how about adding Greek and Cyrillic characters?
4. In that case, why shouldn’t we add characters for CJK languages?

There is no trick or pun intended. Even when you add all requested characters before, there may be other scripts missing (such as Indic ones, among many others).

Any character selection to be embedded in the fake device font is a compromise. The fake device font is also temporary, since Ruffle should be able to read with OS fonts.

So, I think that the required code for #1862 would be the way to fix this issue (and more than 20 other ones).

In that sense, this may be a duplicate of #1862.

[Amseog]

Hello ousia,

thank you for a very insightful and interesting comment. Many of the described considerations are understandable! I absolutely agree that reading device fonts will be the ultimate goal to overcome the described issues, while also not inflating Ruffle's size.

At the same time, I am honestly wondering how feasible just telling people to wait for this solution is. I noticed on this GitHub that people have expressed their disappointment about missing characters for over a year. Of course, it is absolutely understandable that Ruffle's development takes time, since it is a non-commerical project...and all of us should just be happy about everything it offers.

Still, I am under the impression that expanding the embedded font to incorporate more characters could be a super-swift solution that creates a much better experience for many users in the short run.

Of course, this would leave us with your very smart and important question as to which characters to include. I agree that this may turn out to become "unfair" to some user groups. Who says that Western European characters are more important than, for instance, adding Japanese Kanji?
Arguably, a democratic solution could arise from considerations of file size. Do you have any concrete numbers? How much would Ruffle's size increase by adding, for instance, your cases (1), (2), and (3)? I can't imagine that this would add more than a few KBs (potentially less), which sounds more than reasonable to me...especially if it means making this great plugin more internationally accessible for dozens of countries. If, however, adding the incomparably larger sets of CJK characters means putting another 50 or 100 KBs on top of it, you might have a very logical reason for not doing so at the current time.

Of course, these are just my two cents, but maybe you find some of my thoughts persuading. Thanks for your time.

[ousia]

Hi @Amseog,

I made a similar proposal at #1862 (comment) (and again, #1862 (comment)).

Similar proposals:

• Implement device font rendering #1862 (comment) by @SamMorrowDrums.
• Implement device font rendering #1862 (comment) by @torokati44.

How about closing the issue and continuing the conversation at #1862?

[kmeisthax]

I think a good short-term solution would be to ship a fully internationalized version of Noto in the extension and desktop versions only. The file size penalty of a properly internationalized fallback font wouldn't matter as much in those contexts. Self-hosted users who need the larger fallback font but can't embed it properly could build with the internationalized font enabled.

[torokati44]

While the discussion between @ousia and @Amseog still retains some unresolved points, and it's not quite what @kmeisthax suggested either, but #6224 resolved this specific issue by including some more accented Latin characters.
There are still other issues that cover the non-Latin characters, those are to be left open still - such as #1616.