Page MenuHomePhabricator

Terminology loves emoticons so much, it wants to show them off as HUGE
Closed, ResolvedPublic

Description

Terminology, when asked to print an eomticon, does so in a HUGE size. Attached is an example of this from a recent email I received.

gregkh created this task.Mar 20 2017, 12:48 PM
gregkh added a project: Terminology.

Happens both on 0.8.0 and latest git HEAD right now.

In comparison, here's gnome-terminal:

I guess the font substitution code is not working the same. I think the font you're using does not have that unicode character. The fallback mechanism picks some character way too large.

@jpeg, @raster : any idea?

This has been going on for a while with a patch: D2713

as you may note if you show older comments... exact same thing. it's a fontset based thing. if you have multiple fonts that are searched for font glyphs evas will find the one with your color emoji's. the problem is it doesn't scale them to the right size because bitmap scaling is generally "not allowed". as per that patch above... it should be allowed, but IMHO just for RGBA bitmap for these kinds of color emoji's. :) so it's really an efl thing that's been lurking for a while... :)

jpeg assigned this task to id213sin.Apr 18 2017, 5:48 AM
billiob added a subscriber: OctoNezd.
billiob added a subscriber: OctoNezd.
billiob added a subscriber: OctoNezd.
billiob added a subscriber: OctoNezd.
billiob added a subscriber: OctoNezd.

@jpeg, @id213sin: any update on this?

@jpeg, @billiob
After applying D2713 patch, the issue CAN be solved.
D2713 supports bitmap color glyph (Emoji) scaling according to the given font size.

So, you can see proper Emoji size with "Standard font" in terminology.
But, with "Bitmap font", Emoji still show improper size according to previous font size setting.
To fix this issue in "Bitmap font", terminology needs to set a proper font size for each bitmap fonts.
I'll take a look inside of terminology.

jpeg added a comment.Oct 25 2017, 3:08 AM

Shouldn't the proper size be handled by the textgrid?

well no. when you select a bitmap font - like a .pcf file... the size provided to the font is irrelevant as the bitmap font file itself determines size. so the bounding box/ascent+descent etc. of that file are what determines font sizing. thus emoji's chosen to draw with that font should be scaled to match the bitmap font sizing (not the font size requested in the api).

@raster
As we talked before, scaling font should be handled by font size. It allows to scale font based on font size even if main font or first loaded font is emoji font.
Scaling font based on main font's bounding box sounds like "fit" option in Edje.
How about to adding a new option "fit" in Evas which will scale all fonts to the given line size?

raster added a comment.Nov 1 2017, 1:32 AM

@id213sin well for non-bitmap fonts size does determine things but for bitmap fonts font size is unused because primary font bitmap size determines actual size. using font size when bitmap fonts are used is "wrong".

c added a subscriber: c.
zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:51 AM
zmike edited projects, added efl: rendering; removed Restricted Project.Jun 11 2018, 9:28 AM
herdsman triaged this task as Normal priority.Jun 27 2018, 1:20 PM

If anyone can provide a test scenario for this, please do.
I can't reproduce this.

  1. Install Noto Emoji. (Make sure your terminal font doesn't already includes emojis. I personally set mine as Fira Mono)
  2. Reboot Terminology.
  3. curl https://eosrei.github.io/emojione-color-font/full-demo.html
  4. Notice the total mess.

If this doesn't repros, I can provide more info about my current environment which could help.

@charlesmilette, thanks for the input.
Unfortunately, I am still unable to reproduce.
I have tried "Fire Mono" and the font in terminology, and did the "curl" command. Everything seems to be intact.
Let's try additional steps, if you don't mind.
Much appreciated.

raster added a comment.EditedJun 28 2018, 3:10 AM

i can't reproduce. efl from git. it took me a while to get noto color emoji to be used i had to add the following to my fonts.conf:

<match target="pattern">
 <edit mode="prepend" name="family">
  <string>Noto Color Emoji</string>
 </edit>
</match>

also i have to use a non-bitmap font in terminology. but i end up with:

https://www.enlightenment.org/ss/e-5b34abfc5e0f17.14088269.png

yes - advanced color emoji sequences that vary the color of the skin don't work - that's a terminology issue as it works in elm's entry widget:

https://www.enlightenment.org/ss/e-5b34ac496a0146.51071941.png

both chromium and efl had trouble using all the color emoji until i added the fonts.conf entry above. fc-match had noto color at the end of the list rather than near the top - that's why. so seemingly a fontconfig issue and i assume gtk has some hack/workaround this as it picked up the color emoji without the font.conf mod.

there is an issue with textgrid and bitmap fonts. then for some reason noto color is only used for a few glyphs like:

https://www.enlightenment.org/ss/e-5b34aef72f8450.20520046.png

but i don't see anything really bad rendering-wise. no - efl has no support for SVG fonts so we'll only render color bitmap emoji (like noto color emoji). i believe only firefox has such support.

so ... other than the bitmap font ending up with only some emoji being color i see no real issues.

raster added a comment.EditedJun 28 2018, 3:52 AM

ok - the above issue with bitmap fonts - was partly an issue with an svg color emoji font i had installed ... removed it and partly dejavu that seems to take preference to color emoji thus using bnw emoji from it. remove dejavu and rely on bitsream vera and its perfect with efl. elm entry and terminology.

so since that was a local config/data error and dejavu is a dejavu problem (we could do workarounds specifically for the emoji glyph range to look for color ones first then fall back but its a workaround....)... i dont see any bugs.

@charlesmilette, also I would like to verify that you are testing efl-git and not v1.20.
Thanks.

I was testing with the latest version from the Arch repos. I'll build from master and try to repro.

charlesmilette added a comment.EditedJul 4 2018, 5:51 PM

This issue seems fixed on latest git.

For reference, I've fixed the DejaVu problem (this) by using a custom fontconfig file, which kills DejaVu with fire ensures DejaVu doesn't gets in the way of my font preferences: https://github.com/sylveon/dotfiles/blob/master/fonts.conf (Blobmoji being an old version of Noto Color Emoji, because I'm not a fan of the newer emoji set)

raster added a comment.Jul 5 2018, 9:45 PM

yeah - i played with fontconfig a bit to. rather a pain that this needs fixing though.

but good - so in latest git we're fixed. that's what i thought, so an efl release will mean bug is fixed. very very very good.

ProhtMeyhet closed this task as Resolved.Dec 7 2018, 5:55 PM
ProhtMeyhet added a subscriber: ProhtMeyhet.

Then Linus made a joke about Greg being big and squishing people that may or may not be playful or insulting, without knowing much about the relationship between these guys it's hard to say. Squish is hardly a word you use when you're really angry though.

should be fixed, please see above comments, with efl 1.21. if not please reopen @gregkh