Page MenuHomePhabricator

Font weight styles don't affect a output of string when there aren't font faces according to the styles.
Open, NormalPublic

Description

User could set styles of bold when they use string.
but if there aren't font faces according to the bold styles.
Font weight styles don't work properly.

I just tested it with sample text mentioned below.
and you can also find out the result.

[Output string]

<font=Sans:style=Regular>Sans Regular / </font><font=Sans:style=Bold>Sans Bold / </font><font=Sans:style=ExtraBold>Sans ExtraBold</font>

[Result]

As so far, efl uses a certain Freetype api which embolden a glyph with singular value of "some reasonable strength".
if fontconfig couldn't find the proper font.

I think efl need to change a strength of emboldening by reasonable value when user sets styles of bold,
even if there aren't font faces according to the bold styles.

akanad created this task.Aug 18 2016, 12:30 AM
akanad updated the task description. (Show Details)
akanad renamed this task from Font weight style might not be implemented yet to Font weight styles don't affect a output of string when there aren't font faces according to the styles. .Aug 21 2016, 10:46 PM
akanad updated the task description. (Show Details)
akanad added subscribers: cedric, tasn, herdsman.

Fontconfig doesn't fail to find, but rather suggests fonts that it finds closest to our needs.
Adding further "correcting measures" (e.g. how evas currently emboldens) kinda defeats the purpose of fontconfig, not to mention that we'd probably want to correct all of the failing cases: SemiBold, UltraBold, ExtraBold, Light, UltraLight, ExtraLight etc. At best we could blindly correct those without guarantee to have satisfactory results.

I'm wondering, why don't just install those fonts and let fontconfig find them.
@tasn, thoughts?

tasn added a comment.Aug 22 2016, 7:23 AM

@herdsman, I think you misunderstood the ticket. He's talking about runtime embolden in freetype when the system can't find a bold variant of the chosen font.

@akanad, if your example is correct (haven't tested it), it seems there is an issue. Based on your analysis of the code, it seems to be exactly that. I guess we don't change bold values although we should. It should be an easy fix. Would you like to send a patch, or would you prefer me to have a look? I wonder why I didn't do it in the first place.

In T4385#67310, @tasn wrote:

@herdsman, I think you misunderstood the ticket. He's talking about runtime embolden in freetype when the system can't find a bold variant of the chosen font.

Yes, if you want "Bold" and the system couldn't find a "Bold" face for you, then you embolden its outline (some dilation I guess?) to achieve the look.
Currently, this doesn't work when you ask for "ExtraBold" and fontconfig was only able to come up with a "Bold" face for you.

So, you suggest we need to cover this case?

tasn added a comment.Aug 22 2016, 8:47 AM

Unless I'm misunderstanding something (or just don't remember the code correctly), I don't see how this has anything to do with fontconfig.

You have a font like: "Sans:style=ExtraBold", now there are three options:

  1. Fontconfig returns an extrabold font: you do nothing. - works
  2. Fontconfig returns a bold font: you embolden it a bit. - doesn't work
  3. Fontconfig returns a regular font: you embolden it a lot - doesn't work, we only embolden a little, which is what this ticket is about.

We need to handle cases 2 and 3. I don't see how this has anything to do with fontconfig and faces.

Well, by "face" I just meant that fontconfig chose something like "DejaVuSans Regular" (or even "DejaVuSans Bold") for you, when you had requested an "ExtraBold" style.

But anyway, what good will a conversion from Regular to ExtraBold do? Will it look good? Won't you rather use an ExtraBold style that was actually designed?

OK I just noticed I got the terminology wrong. I meant "font" and not "face".

tasn added a comment.Aug 23 2016, 1:05 AM

Yes, using a good font that was designed this way is best. However, such a font is not always available so we try to do our best in accommodating the programmer's request, so we make fonts bold on runtime. It's a fallback to a missing font.

herdsman added a comment.EditedAug 23 2016, 1:20 AM

OK. So, how many fallbacks do we want to add? There are a lot of cases to cover:
UltraLight->ExtraLight->Light-> ... -> Regular -> ... -> Bold -> ExtraBold -> UltraBold
... and a lot of others.

At best we could blindly correct those without guarantee to have satisfactory results.

This was my main point, though. Even if we cover all those, it probably won't look as good.

I'm actually afraid of what exactly herdsman said. we could embolden a glyph by large amount of strength value.
but It could make the glyph look bad, in certain cases.
but I guess we could probably find the point between "satisfaction of users" and "don't mess up the font".

@tasn if you don't mind, I want to make my entry point of contributions on efl here.

while I'm wrting previous reply, you are commenting too.
if so, we can make a conversation about it later.
I'm going to make some patch about it then comment it here, again.

I am actually leaning to not support more fallbacks, and instead report with an ERR to notify the user, that can later install fonts.

tasn added a comment.Aug 23 2016, 3:19 AM

On the phone/desktop you don't see terminal output when you run an application, you will never see this error as a user of an application. Furthermore, in some cases it can't be done at all (font embedded in the theme, or a specific file). There is no nice graceful way of printing an error from our side. Applications could potentially check and report the lack of fonts, but that's out of scope for us as the GUI toolkit. If you want absolute correct results as an app, deal with it an error, otherwise, we owe it to applications to do the right thing. There is no spec anywhere saying that fonts should come with bold variants, so "runtime embolden" should be considered as a reasonable alternative. More so, it actually is. I doubt fonts will be too screwed.

@akanad, I'd love you to send a patch, so yes, please do! When you create a patch please reference this ticket in the commit message too (and please chase me if I don't review it within two days).

Thanks, Tom.

"that can later install fonts"... you know that's not an option 99% of the time. you get a set of fonts with their bold, italic, etc. versions ... and it's all there. if it's not there is no more font to go install. the problem at the end of the day is the font designer has chosen not to implement every possible style on the planet. when i started with graphics and fonts there was no extrabold or different weightings of a font. there was normal, italic and bold. that was it. you can't expect every font designer to go implement dozens of versions of their font. it's better if they do.. so our choices are as i see it:

  1. be strict and if no font was designed don't go fake something. just fail - fall back to normal or the closest match. that means remove the font emboldening that is in evas. remove it. be consistent.

or

  1. handle extrabold by either taking a real bold version of the font and emboldening it, or if that bold version does not exist, take the normal version and embolden it 2 times.
tasn added a comment.Sep 2 2016, 7:34 AM

Yes, I think we should go with the second option. Option 1 feels wrong. It's not the poor app's fault that the system is broken. We need to help it.

stefan_schmidt triaged this task as Normal priority.Feb 10 2017, 6:56 AM
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:59 AM
q66 edited projects, added efl: rendering; removed Restricted Project.Jun 11 2018, 7:53 AM