AttributedText on windows with Chinese Characters not working

General JUCE discussion
1

Sorry for bringing up that topic again. Also one vote from me to make the fallback font work out of the box. Already spent too much time on this.

We try to show Chinese or Japanese filenames in a plugin. The filenames display correctly in the macOS finder and also in the Windows Explorer. Our plugin uses an embedded font that does not contain Chinese or Japanese symbols.

To make this work we replaced g.drawText() with an AttributedText. This worked on macOS. But it shows only an empty space on Windows.

I tried to set JUCE_USE_DIRECTWRITE=1 without any success. Embedding fallback fonts that contain all kinds of characters is no option for us because of their size.

What can we do to make this work?

2

I’m afraid off the top of my head I don’t have an answer for what you can do right now, or why that isn’t working without taking a closer look. We are however currently working on full unicode support for a future release.

You said you can’t embed the fallback fonts due to the size. Have you considered alternative approaches such as downloading the font when required, or compressing the fonts before embedding them?

3

Great to hear that Unicode support is on the way. I’m trying to keep things as simple as possible and avoid any complicated installation process or network access. The font is still 15MB when compressed.

4

If you haven’t already could you try using a TextLayout to draw your AttributedString? Thanks.

5

To be clear, to do this you probably just need some code like this…

TextLayout layout;
layout.createLayout (attributedString, bounds.getWidth());
layout.draw (g, bounds);
6

AttributedString::draw does this FWIW

7

I think it only does that if drawTextLayout fails in the context. However looking deeper on Windows that’s only implemented in Direct2DLowLevelGraphicsContext so unless JUCE_DIRECT2D is enabled then you’re right that should already be happening. I had noticed another post that suggested this which is what made me think it might be worth trying.

1 Like
8

Yes, I also tried TextLayout with JUCE_USE_DIRECTWRITE=1 without any result. The same code works in macOS.

9

On Windows I have a special code for this as I don’t set the custom font if I need the fallback working otherwise it doesn’t
The issue happen in juce internal if you don’t have a WindowsDirectWriteTypeface which is the case if you load a font from the HD.


    static bool canBeRepresented(juce::StringRef text)
    {
      for (auto t = text.text; !t.isEmpty();)
      {
        auto c = t.getAndAdvance();

        if (!(c < 0x024f || (c >= 0x2000 && c < 0x20d0))) // latin char and punctuation
          return false;
      }

      return true;
    }
10

Just tried to not set your custom font and you ll see that the fallback is working

1 Like
11

In my case I don’t load the font using createSystemTypefaceFor so this is why… Maybe you do the same

1 Like
12

Ok, I see where this goes… Then I return getDefaultTypefaceForFont() in the LookAndFeel::getTypefaceForFont() method instead of one of my memory fonts in that case… I will try this.

13

Still working on this. I was able to make it work, but the whole thing is super fragile on Windows. I wanted to have a solution where I can have my own default font in MyLookAndFeel::getTypefaceForFont() and still have the fallback. At the moment I have no other idea than setting the font everywhere but not when I want the fallback.

Here are some problems with the Windows Direct Draw fallback when using embedded fonts:

  • It does not work on windows out of the box.
  • Fallback depends on the code in MyLookAndFeel::getTypefaceForFont()
  • It needs the workaround @otristan mentioned above if you also want to use your own embedded fonts
  • getStringWidth() also does not work without the workaround.
  • The most important one: I would expect that it also works without the need for an AttributedText.

Edit: forgot almost the most important problem:

  • TextEditor support for the fallback

@anthony-nicholls please also make this also work out of the box when you work on the Unicode support. I’m ready for testing :slight_smile:

14

Thanks for reporting, I’ll pass the feedback on to the team.

1 Like