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.
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... :)
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.
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).
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?
- Install Noto Emoji. (Make sure your terminal font doesn't already includes emojis. I personally set mine as Fira Mono)
- Reboot Terminology.
- curl https://eosrei.github.io/emojione-color-font/full-demo.html
- Notice the total mess.
If this doesn't repros, I can provide more info about my current environment which could help.
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:
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:
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:
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.
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.
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)
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.
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