Announcement

Collapse
No announcement yet.

Cairo 1.15.8 Released With Support For Colored Emoji

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    it should be worth nothing that this does appear to be a stable release, but a development snapshot, ..!

    Comment


    • #22
      Originally posted by linuxgeex View Post
      ugh... I'm sorry but WTF.

      Emoji are an esoteric feature of a handful of applications which use Cairo as a rendering library, not something Cairo should be taking over, any more than Cairo should be taking over colorising text in programmer's editors.

      Do you want every app that loads Cairo to have bitmapped color emoji features? Plymouth needs this bloat? Okay I can see how bibledit-gtk needs emoji, after all there's a lot of LOLz in there, but what about dia (bitmap renderings really don't belong here), gimp (if it forces a color representation of a text emoji Keith Packard is gonna get some colorful emails), or a bazillion others... ardour, awesome, brasero, byzanz, darktable, gcc-snapshot, gcompris, genometools, gexec, ghex, , gnome-power-manager, gnucash, grass-core, guitarix, hexter, i3wm, ibus, indicator-printers, intel-gpu-tools, jwm, ltrsift, lxdm, lysdr, mango-lassi, mricron, mousetweaks, mx44, nvidia-settings, obconf, obsession, optgeo, pcb-gtk, petri-foo, phasex, pqiv, praat, procmeter3, quadrapassel, rasmol, r-base-core, siril, sndfile-tools, snd-gtk-jack, spectools, stoken, tcpflow, tenace, tesseract-ocr, threadscope, uget, vice, viking, vino, v-sim, wavbreaker, wmcliphist, xnec2c, xsensors, xsynth-dssi, yoshimi... that's a handful but there's hundreds of things that link cairo or depend libraries or language bindings that link cairo, that will get no value whatsoever from this.
      of course font libraries should support this. it is not much different from legacy, vintage, monochrome bitmap fonts, only that they can be colored now.
      this does not mean I like to go back to bitmap fonts, or color emoji, but that is the new world we live in, and (new) users expect.

      Comment


      • #23
        Originally posted by rene View Post

        of course font libraries should support this. it is not much different from legacy, vintage, monochrome bitmap fonts, only that they can be colored now.
        this does not mean I like to go back to bitmap fonts, or color emoji, but that is the new world we live in, and (new) users expect.
        Except that these aren't fonts. They're PNGs embedded into a raster font file, raster fonts being something Cairo should be deprecating to begin with, not adding features to.

        Comment


        • #24
          Originally posted by linuxgeex View Post
          Emoji are an esoteric feature of a handful of applications which use Cairo as a rendering library, not something Cairo should be taking over, any more than Cairo should be taking over colorising text in programmer's editors.
          (...)
          there's hundreds of things that link cairo or depend libraries or language bindings that link cairo, that will get no value whatsoever from this.
          Everyone needs more emojis! Imagine Those projects now being able to access colored emojis. gnome-power-manager can give you feedback on how much power you're using via an emoji! Ardour can ... Okay, I'm obviously kidding. Emojis were a mistake in the first place, but putting these pictures into Unicode seems extra stupid. I guess Cairo now has to follow that, but it just makes everyone's life worse.

          purple meh-emoji

          Comment


          • #25
            Originally posted by starshipeleven View Post
            Originally posted by GhostOfFunkS View Post

            Except that GNOME can do the same. Just create a session and install a fuckload of extensions.
            fixed
            Very true! Having a usable DE these days is harder than having a usable Firefox. You install lots of extensions/addons or it sucks a lot (and still sucks, these days WebExtensions transition is done so badly that lots popular addons such as Tab Mix Plus no longer work in Nightly). And after that, that will add bloat too.

            One good thing of Gnome: It crashes less than KDE in my machine. But I hate both KDE and Gnome equally, I don't discriminate them

            About emoji support in Cairo: WTF? I thought they worked in making it suck a lot less, not get even more into feature creep. These days most big projects are progressively switching to other libraries such as Skia.

            The C++ standardization isn't going to save them, it will only be an API others will use.

            Originally posted by DanL View Post

            The emojis or GhostofFunkS' trolling?
            Both?

            I think it's more important:
            - Better optimization in CPU and GPU, surpassing both AGG and Skia.
            - Optimize OpenGL and implement Vulkan support.
            - Better Direct2D or whatever for Microsoft Windows.
            - Metal for MacOS.
            - To have a diverse (Serif and others, fonts suitable for console and programming, etc) set of absolute 100% Unicode 10+ fonts. I'm aware it's a titanic task, but a lot more important than stupid emojis and would simplify lots of things.
            Last edited by timofonic; 08-30-2017, 08:03 PM. Reason: Faster CPU and CPU rendering, 100% Unicode 10+ support is a lot more important

            Comment


            • #26
              Originally posted by phoronix View Post
              Phoronix: Cairo 1.15.8 Released With Support For Colored Emoji
              Colored? Ahem, I believe the term is African American emoji. I dream of the day when GTK users will be judged not by the color of their emoji, but by the content of their character set.

              Comment


              • #27
                Originally posted by linuxgeex View Post

                Except that these aren't fonts. They're PNGs embedded into a raster font file, raster fonts being something Cairo should be deprecating to begin with, not adding features to.
                You write yourself PNGs embedded in raster font file. So yes, they are fonts ;-)

                Comment


                • #28
                  Originally posted by rene View Post

                  You write yourself PNGs embedded in raster font file. So yes, they are fonts ;-)
                  I challenge you to find where in the spec there is support for PNGs in OpenType fonts.

                  You are talking about a hack to stuff PNG data (not fonts) into a font file so that a modified OpenType renderer can use them in the place of standard raster font data, while at the same time ignoring the foreground color that the font is meant to be rendered in. If this support is added, it is going to break standard font handling in many subtle ways. That is the primary reason I think they (the people developing and rooting for this) should...

                  GOSUB HELL;

                  HELL: POP.

                  Or, first they should implement support for all existing filesystems in the linux kernel block layer. It makes equal sense (none - filesystems do not belong in the block layer) but it would be infinitely more useful.

                  https://groups.google.com/forum/#!forum/color-emoji is a closed group. Obviously they're developing an open standard behind closed doors because they're so proud of their work and so open to the many ways in which other developers might react. And they finished this work in 2014, we're only hearing about it now, so I guess I can breathe a sigh of relief that they aren't getting any traction.
                  Last edited by linuxgeex; 09-04-2017, 04:52 AM.

                  Comment


                  • #29
                    Originally posted by linuxgeex View Post

                    I challenge you to find where in the spec there is support for PNGs in OpenType fonts.

                    You are talking about a hack to stuff PNG data (not fonts) into a font file so that a modified OpenType renderer can use them in the place of standard raster font data, while at the same time ignoring the foreground color that the font is meant to be rendered in. If this support is added, it is going to break standard font handling in many subtle ways. That is the primary reason I think they (the people developing and rooting for this) should...

                    GOSUB HELL;

                    HELL: POP.

                    Or, first they should implement support for all existing filesystems in the linux kernel block layer. It makes equal sense (none - filesystems do not belong in the block layer) but it would be infinitely more useful.

                    https://groups.google.com/forum/#!forum/color-emoji is a closed group. Obviously they're developing an open standard behind closed doors because they're so proud of their work and so open to the many ways in which other developers might react. And they finished this work in 2014, we're only hearing about it now, so I guess I can breathe a sigh of relief that they aren't getting any traction.
                    About supporting all file systems: I would want to, even the most exotic or "esoteric" ones. This would make Linux the preferred operating system for digital preservation. I see FUSE isn't a strong project at all and there's lots of abandoned "filesystems" for it too, what about making easier to write filesystems for Linux kernel instead and ALL living in the main code base?

                    Comment


                    • #30
                      Originally posted by linuxgeex View Post

                      I challenge you to find where in the spec there is support for PNGs in OpenType fonts.

                      You are talking about a hack to stuff PNG data (not fonts) into a font file so that a modified OpenType renderer can use them in the place of standard raster font data, while at the same time ignoring the foreground color that the font is meant to be rendered in. If this support is added, it is going to break standard font handling in many subtle ways. That is the primary reason I think they (the people developing and rooting for this) should...

                      GOSUB HELL;

                      HELL: POP.

                      Or, first they should implement support for all existing filesystems in the linux kernel block layer. It makes equal sense (none - filesystems do not belong in the block layer) but it would be infinitely more useful.

                      https://groups.google.com/forum/#!forum/color-emoji is a closed group. Obviously they're developing an open standard behind closed doors because they're so proud of their work and so open to the many ways in which other developers might react. And they finished this work in 2014, we're only hearing about it now, so I guess I can breathe a sigh of relief that they aren't getting any traction.
                      I'm a developer often working on pure text terminals. I could not give much f*ck about this either. Fact is this exist, and users expect emoji, ...

                      If I would be a developer at Apple/Google coming up with this stuff, my first natural choice in this millennium would have been colored vector path fonts. Think a bit like the haiku vector icon spec thing. In this day and age I would obviously not stuffed bitmap PNGs in a font file, ...

                      Comment

                      Working...
                      X