Constructing wxFont using facename

[Eran Ifrah]

Hi,

I have a question regarding fonts:

In my application, I am serializing fonts into a json file using the following structure:

{
    "Flags": 0, // bits for BOLD, ITALIC etc
    "Face": "Iosevka",
    "Size": 12
}

and later in my code I am building wxFont from the above using a code similar to this:

wxFontInfo fontInfo = wxFontInfo(prop.GetPointSize())
                                .Family(wxFONTFAMILY_MODERN)
                                .Italic(prop.GetItalic())
                                .Bold(prop.IsBold())
                                .Underlined(prop.GetUnderlined())
                                .FaceName(face);
wxFont font(fontInfo);

In the above example, `face` is ` Iosevka`

This works. Now, if I choose the font `Iosevka` with style `Semibold` from the wxFontPickerCtrl dialog and I will then serialize the result back into the JSON file, it becomes:

"Face": "Iosevka Semibold" // the output of font.GetFaceName()

Later when I attempt to construct a wxFont with this face name, it does not work (since the face name should be "Iosevka")

in the "Font Picker" dialog, under the list box that says "Font" it only says "Iosevka" and the "Semibold" appears in the "Font style" part. But they are joined together to form the face name when calling event.GetFont().GetFaceName() (where event is of type wxFontPickerEvent)

which either is wrong or I am doing something wrong.

What am I missing here?

Thanks!

--

Eran Ifrah

Author of CodeLite IDE https://codelite.org

[Vadim Zeitlin]

On Tue, 3 May 2022 23:45:31 +0300 Eran Ifrah wrote:

EI> I have a question regarding fonts:
EI> In my application, I am serializing fonts into a json file using the
EI> following structure:
EI>
EI> {
EI> "Flags": 0, // bits for BOLD, ITALIC etc
EI> "Face": "Iosevka",
EI> "Size": 12
EI> }

The only officially supported way to serialize wxFont to a string is by
using "font description", i.e. wxFont::GetNativeFontInfoDesc() and
SetNativeFontInfo() functions. There are helper wx{To,From}String()
functions allowing to convert wxFont to/from string using this form.

EI> Later when I attempt to construct a wxFont with this face name, it does not
EI> work (since the face name should be "Iosevka")
EI> in the "Font Picker" dialog, under the list box that says "Font" it only
EI> says "Iosevka" and the "Semibold" appears in the "Font style" part. But
EI> they are joined together to form the face name when calling
EI> event.GetFont().GetFaceName() (where event is of type
EI> wxFontPickerEvent) which either is wrong or I am doing something wrong.
EI> What am I missing here?

That fonts are complicated and it's difficult to ensure that they can be
decomposed and recomposed back losslessly. The font info string
representation is ugly but it's the only way to represent an arbitrary font
that is provided by wxWidgets.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Eran Ifrah]

Thanks, I will change my to use GetNativeFontInfoDesc() for de/serializing per your advise

Eran

[Eran Ifrah]

Thanks VZ for you advise, I changed my code to use GetNativeFontInfoDesc/SetNativeFontInfoDesc for serialisation purposes,

the results are still the same: I am unable to construct "Iosevka SemiBold" although, it is serialised properly (according to the debug messages I added)

The same code works when using "Iosevka"  (no "SemiBold")

I tried other fonts as well (both with "SemiBold" and without it)

The SemiBold failed regardless of the font (by "fail" I see some default GUI font picked and not the intended font)

Some more background is required:

I am trying to use these fonts with wxStyledTextCtrl.

I added debug messages up until the point I am calling m_stc->StyleSetFont(style_number, font)

For example, a debug message for font that works:

ctrl->StyleSetFont( style= 1 , font=1;12;-16;0;0;0;400;0;0;0;0;3;2;1;49;JetBrains Mono NL )

while this one does not work:

ctrl->StyleSetFont( style=1 , font=1;12;-16;0;0;0;600;0;0;0;0;3;2;1;49;Iosevka Semibold )

Platform: wxMSW

wxVersion: 3.1.6, 64BIT, MinGW GCC 10.3 (self compiled)

Anything I missed?

[Igor Korot]

Eran,

On Thu, May 5, 2022 at 1:04 PM Eran Ifrah <er...@codelite.org> wrote:
>
> Thanks VZ for you advise, I changed my code to use GetNativeFontInfoDesc/SetNativeFontInfoDesc for serialisation purposes,
> the results are still the same: I am unable to construct "Iosevka SemiBold" although, it is serialised properly (according to the debug messages I added)
> The same code works when using "Iosevka" (no "SemiBold")
>
> I tried other fonts as well (both with "SemiBold" and without it)
> The SemiBold failed regardless of the font (by "fail" I see some default GUI font picked and not the intended font)
>
> Some more background is required:
> I am trying to use these fonts with wxStyledTextCtrl.
>
> I added debug messages up until the point I am calling m_stc->StyleSetFont(style_number, font)
> For example, a debug message for font that works:
>
> ctrl->StyleSetFont( style= 1 , font=1;12;-16;0;0;0;400;0;0;0;0;3;2;1;49;JetBrains Mono NL )
>
> while this one does not work:
>
> ctrl->StyleSetFont( style=1 , font=1;12;-16;0;0;0;600;0;0;0;0;3;2;1;49;Iosevka Semibold )
>
> Platform: wxMSW
> wxVersion: 3.1.6, 64BIT, MinGW GCC 10.3 (self compiled)
>
> Anything I missed?

Did it work with the previous version of the library?

Thank you.

> --
> Please read https://www.wxwidgets.org/support/mlhowto.htm before posting.
> ---
> You received this message because you are subscribed to the Google Groups "wx-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wx-users+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/CAOpAFwVg2RmgkJSBL%3DFdpxXEnF9fcCyn%2Bvhm%3DhCP0eJv51tqqg%40mail.gmail.com.

[Eran Ifrah]

I downloaded an older version of CodeLite, and it does not work there as well. wxWidgets version used is 3.1.3

To view this discussion on the web visit https://groups.google.com/d/msgid/wx-users/CA%2BFnnTxs9QT0hrCUeR3hw_1L9q5As%3DZkLQPYRNge-vq%2B7AuKTQ%40mail.gmail.com.

[Vadim Zeitlin]

On Thu, 5 May 2022 21:03:53 +0300 Eran Ifrah wrote:

EI> Thanks VZ for you advise, I changed my code to use
EI> GetNativeFontInfoDesc/SetNativeFontInfoDesc
EI> for serialisation purposes,
EI> the results are still the same: I am unable to construct "Iosevka SemiBold"
EI> although, it is serialised properly (according to the debug messages I
EI> added)
EI> The same code works when using "Iosevka" (no "SemiBold")

If an existing font can't be recreated from its serialized representation,
it's a bug, so now "all" we have to do is to fix it :-)

EI> I tried other fonts as well (both with "SemiBold" and without it)
EI> The SemiBold failed regardless of the font (by "fail" I see some default
EI> GUI font picked and not the intended font)

Does it also fail for you with the standard fonts, e.g. "Segoe UI"?

EI> Some more background is required:
EI> I am trying to use these fonts with wxStyledTextCtrl.

But this isn't specific to it, right?

EI> For example, a debug message for font that works:
EI>
EI> ctrl->StyleSetFont( style= 1 ,
EI> font=1;12;-16;0;0;0;400;0;0;0;0;3;2;1;49;JetBrains Mono NL )
EI>
EI> while this one does not work:
EI>
EI> ctrl->StyleSetFont( style=1 , font=1;12;-16;0;0;0;600;0;0;0;0;3;2;1;49;Iosevka
EI> Semibold )
EI>
EI> Platform: wxMSW
EI> wxVersion: 3.1.6, 64BIT, MinGW GCC 10.3 (self compiled)
EI>
EI> Anything I missed?

No, it really looks like a bug, "semibold" is correctly serialized as
"weight=600", i.e. in the middle between normal (400) and bold (900), but
apparently it shouldn't be part of the font name. I don't know why is it
added to it, but if you can confirm that this also happens with a font I
have (such as Segoe UI), I'll try to debug it.

[Eran Ifrah]

Thanks Vadim.

On Thu, May 5, 2022 at 9:41 PM Vadim Zeitlin <va...@wxwidgets.org> wrote:

On Thu, 5 May 2022 21:03:53 +0300 Eran Ifrah wrote:

EI> Thanks VZ for you advise, I changed my code to use
EI> GetNativeFontInfoDesc/SetNativeFontInfoDesc
EI> for serialisation purposes,
EI> the results are still the same: I am unable to construct "Iosevka SemiBold"
EI> although, it is serialised properly (according to the debug messages I
EI> added)
EI> The same code works when using "Iosevka"  (no "SemiBold")

 If an existing font can't be recreated from its serialized representation,
it's a bug, so now "all" we have to do is to fix it :-)

EI> I tried other fonts as well (both with "SemiBold" and without it)
EI> The SemiBold failed regardless of the font (by "fail" I see some default
EI> GUI font picked and not the intended font)

 Does it also fail for you with the standard fonts, e.g. "Segoe UI"?

Hard to from the look of editor, but it seems so (easier when the fallback font is not a monospaced one vs monospaced)

 

EI> Some more background is required:
EI> I am trying to use these fonts with wxStyledTextCtrl.

 But this isn't specific to it, right?

No. Things that I think are irrelevant  to the issue (from my understanding) might be relevant to others :)

 

EI> For example, a debug message for font that works:
EI>
EI> ctrl->StyleSetFont( style= 1 ,
EI> font=1;12;-16;0;0;0;400;0;0;0;0;3;2;1;49;JetBrains Mono NL )
EI>
EI> while this one does not work:
EI>
EI> ctrl->StyleSetFont( style=1 , font=1;12;-16;0;0;0;600;0;0;0;0;3;2;1;49;Iosevka
EI> Semibold )
EI>
EI> Platform: wxMSW
EI> wxVersion: 3.1.6, 64BIT, MinGW GCC 10.3 (self compiled)
EI>
EI> Anything I missed?

 No, it really looks like a bug, "semibold" is correctly serialized as
"weight=600", i.e. in the middle between normal (400) and bold (900), but
apparently it shouldn't be part of the font name. I don't know why is it
added to it, but if you can confirm that this also happens with a font I
have (such as Segoe UI), I'll try to debug it.

This is how Segoe UI Semibold is being serialised:

"1;15;-20;0;0;0;600;0;0;0;0;3;2;1;34;Segoe UI Semibold"

 

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

[utelle]

  No, it really looks like a bug, "semibold" is correctly serialized as
"weight=600", i.e. in the middle between normal (400) and bold (900), but
apparently it shouldn't be part of the font name.

Looking at the actual font files I see

seguisb.ttf:

- Font Family name: Segoe UI Semibold

- Font name: Segoe UI Semibold

- Preferred Family: Segoe UI

- Preferred Subfamily: Semibold

 seguisbi.ttf

- Font Family name: Segoe UI Semibold

- Font name: Segoe UI Semibold Italic

- Preferred Family: Segoe UI

- Preferred Subfamily: Semibold Italic

That is, Microsoft decided to include "Semibold" in the font family name. And that's probably why GetFaceName returns "Segoe UI Semibold". Unfortunately, I have no idea when and how the attributes "Preferred Family" and "Preferred Subfamily" are accessed in the Windows API, but I suspect that the font picker uses them.

Most likely, the situation is the same for the font in question ("Iosevka") - which I don't have on my system.

[Vadim Zeitlin]

On Fri, 6 May 2022 00:25:41 -0700 (PDT) utelle wrote:

u> > No, it really looks like a bug, "semibold" is correctly serialized as
u> >> "weight=600", i.e. in the middle between normal (400) and bold (900), but
u> >> apparently it shouldn't be part of the font name.
u> >
u> Looking at the actual font files I see
u>
u> seguisb.ttf:
u> - Font Family name: Segoe UI Semibold
u> - Font name: Segoe UI Semibold
u> - Preferred Family: Segoe UI
u> - Preferred Subfamily: Semibold
u>
u> seguisbi.ttf
u> - Font Family name: Segoe UI Semibold
u> - Font name: Segoe UI Semibold Italic
u> - Preferred Family: Segoe UI
u> - Preferred Subfamily: Semibold Italic
u>
u> That is, Microsoft decided to include "Semibold" in the font family name.
u> And that's probably why GetFaceName returns "Segoe UI Semibold".

I've finally tested this and it's also the situation on my system. I.e.
"Segoe UI Semibold" is actually a valid font name. And so is "Segoe UI
Light" and, of course, "Segoe UI" itself.

So while it is indeed a bit strange, but at least recreating the font from
its serialized description does work, as can be seen in the font sample if
you do Shift-Ctrl-D ("Font|Set native font description"). Just as Ulrich, I
don't have the "Iosevka" font for which the problem was originally
reported and I'm not sure which file should I get from its download page
(https://github.com/be5invis/Iosevka/releases), but could it be that you're
simply missing some font files?

Of course, it's still possible that we're doing something wrong and that
we need to get this "Preferred Family" from somewhere (but I don't know
from where), but I just don't see any problem in practice with the current
code, so I'm not sure about what exactly would need to be fixed...

[Eran Ifrah]

Thanks for looking into this.

I did some more tests locally and I believe I found the culprit for this.

What made me believe that the font is not built correctly is the fact that it was not the font I expected to see when displayed in wxSTC.

I expected a monospaced font and instead, I found a non-monospaced font, not suitable for coding (at least to me).

So I checked in other places where I am constructing wxFont from the same serialized string.

And to my surprise, it worked. Attached is an example (the tool is using the exact same font as the wxSTC control):

It seems that the culprit is the fact that in wxSTC I am using wxSTC_TECHNOLOGY_DIRECTWRITE

If I change it to: wxSyledTextCtrl::SetTechology(wxSTC_TECHNOLOGY_DEFAULT) the font is rendered correctly, but I lose the ligatures...

Thanks

[Vadim Zeitlin]

On Thu, 12 May 2022 20:11:20 +0300 Eran Ifrah wrote:

EI> I did some more tests locally and I believe I found the culprit for this.
[...]
EI> It seems that the culprit is the fact that in wxSTC I am using
EI> wxSTC_TECHNOLOGY_DIRECTWRITE If I change it to:
EI> wxSyledTextCtrl::SetTechology(wxSTC_TECHNOLOGY_DEFAULT) the font is
EI> rendered correctly, but I lose the ligatures...

Sorry, I don't know this code very well and I have no idea why does this
happen and, unfortunately, unlikely to have time to look at this any time
soon.

Please at least open a bug report about this, ideally with a way to
reproduce this with Segoe UI.

Thanks,