Looks great! On Sat, Jul 29, 2017, 5:43 PM Behdad Esfahbod <beh...@behdad.org> wrote:
> Should be fixed. Thanks! > > On Sat, Jul 29, 2017 at 4:45 PM, <iofel...@gmail.com> wrote: > >> Tried to run gnome-characters with Cairo master, switching to noto- >> color-emoji crashes with: >> >> #0 0x00007fd0ecd2868b in raise () at /lib64/libc.so.6 >> #1 0x00007fd0ecd2a417 in abort () at /lib64/libc.so.6 >> #2 0x00007fd0ecd208fa in __assert_fail_base () at /lib64/libc.so.6 >> #3 0x00007fd0ecd20972 in () at /lib64/libc.so.6 >> #4 0x00007fd0f1370b6e in _cairo_error (status=status@entry=3646361312) >> at cairo-error.c:68 >> #5 0x00007fd0f1367802 in _cairo_set_error (cr=0x3dd89ecc00, >> status=3646361312) at cairo.c:400 >> #6 0x00007fd0f13691b1 in cairo_show_text_glyphs (cr=0x3dd89ecc00, >> utf8=0x3dd8a41b40 "😀", utf8_len=4, glyphs=0x7fffada90d60, num_glyphs=1 >> , clusters=0x7fffada91640, num_clusters=1, cluster_flags=(unknown: 0)) >> at cairo.c:3742 >> #7 0x00007fd0f0283f69 in pango_cairo_renderer_show_text_glyphs.isra () >> at /lib64/libpangocairo-1.0.so.0 >> #8 0x00007fd0f0284161 in pango_cairo_renderer_draw_glyph_item () at >> /lib64/libpangocairo-1.0.so.0 >> #9 0x00007fd0f0057e1e in pango_renderer_draw_glyph_item () at >> /lib64/libpango-1.0.so.0 >> #10 0x00007fd0f00588b1 in pango_renderer_draw_layout_line () at >> /lib64/libpango-1.0.so.0 >> #11 0x00007fd0f0058c65 in pango_renderer_draw_layout () at >> /lib64/libpango-1.0.so.0 >> #12 0x00007fd0f028443a in _pango_cairo_do_layout () at >> /lib64/libpangocairo-1.0.so.0 >> #13 0x00007fd0ef560bde in ffi_call_unix64 () at /lib64/libffi.so.6 >> #14 0x00007fd0ef56054f in ffi_call () at /lib64/libffi.so.6 >> #15 0x00007fd0f10ab6f6 in () at /lib64/libgjs.so.0 >> #16 0x00007fd0f10ad066 in () at /lib64/libgjs.so.0 >> #17 0x00007fd0ee3626a8 in js::Invoke(JSContext*, JS::CallArgs, >> js::MaybeConstruct) () at /lib64/libmozjs-38.so >> #18 0x00007fd0ee3584cd in Interpret(JSContext*, js::RunState&) () at >> /lib64/libmozjs-38.so >> #19 0x00007fd0ee362324 in js::RunScript(JSContext*, js::RunState&) () >> at /lib64/libmozjs-38.so >> #20 0x00007fd0ee362614 in js::Invoke(JSContext*, JS::CallArgs, >> js::MaybeConstruct) () at /lib64/libmozjs-38.so >> #21 0x00007fd0ee664f13 in js_fun_apply(JSContext*, unsigned int, >> JS::Value*) () at /lib64/libmozjs-38.so >> #22 0x00007fd0ee3626a8 in js::Invoke(JSContext*, JS::CallArgs, >> js::MaybeConstruct) () at /lib64/libmozjs-38.so >> #23 0x00007fd0ee363243 in js::Invoke(JSContext*, JS::Value const&, >> JS::Value const&, unsigned int, JS::Value const*, >> JS::MutableHandle<JS::Value>) () at /lib64/libmozjs-38.so >> #24 0x00007fd0ee4b5485 in js::jit::DoCallFallback(JSContext*, >> js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, >> JS::Value*, JS::MutableHandle<JS::Value>) () >> at /lib64/libmozjs-38.so >> #25 0x00007fd0f1877510 in () >> #26 0x00007fffada948a0 in () >> #27 0x00007fffada94368 in () >> #28 0x0000000000000000 in () >> >> On Sat, 2017-07-29 at 16:30 +0100, Behdad Esfahbod wrote: >> > On Sat, Jul 29, 2017 at 11:58 AM, Uli Schlachter <psyc...@znc.in> >> > wrote: >> > > Hi Behdad >> > > >> > > I don't think that is my decision to make. When thinking about >> > > "fonts in >> > > cairo", I'm thinking "Behdad". I'm just asking weird questions from >> > > the >> > > sideline. :-) >> > >> > Thanks. :-) Pushed!!!! At least ten people already asked me "what's >> > up with emoji" at GUADEC... >> > >> > > Uli >> > > >> > > P.S.: How relevant and up to date is the CC list here? I always get >> > > a >> > > "your message to gtk-devel-list awaits moderator approval"-mail >> > > when >> > > replying to this thread... >> > > >> > >> > My messages go through, yours probably don't because you are not a >> > member. It's valuable still. >> > >> > Cheers, >> > b >> > >> > > On 28.07.2017 16:38, Behdad Esfahbod wrote: >> > > > Uli, >> > > > >> > > > Can we commit this? I don't think waiting another few years will >> > > result in >> > > > a superior patchset. :) >> > > > >> > > > Cheers, >> > > > >> > > > behdad >> > > > >> > > > On Wed, Jul 19, 2017 at 1:53 AM, Behdad Esfahbod <behdad@behdad.o >> > > rg> wrote: >> > > > >> > > >> Right. In the future we would want to make it show glyphs in >> > > the input >> > > >> order, ie. not separate color vs non-color. That's the order >> > > required by >> > > >> CSS for example. In a show-text-glyphs call with >> > > CAIRO_TEXT_CLUSTER_FLAG_BACKWARD, >> > > >> it might be desirable to show back-to-front. >> > > >> >> > > >> On Tue, Jul 18, 2017 at 1:59 PM, Matthias Clasen < >> > > >> matthias.cla...@gmail.com> wrote: >> > > >> >> > > >>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <psyc...@znc.in >> > > > wrote: >> > > >>> >> > > >>>> On 07.07.2017 15:23, Matthias Clasen wrote: >> > > >>>>> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <psychon@znc.i >> > > n> wrote: >> > > >>>>>> On 30.06.2017 17:29, Behdad Esfahbod wrote: >> > > >>>>>>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mclasen@redhat. >> > > com> >> > > >>>> wrote: >> > > >>>>>>> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote: >> > > >>>>>>>> On 28.06.2017 14:23, Behdad Esfahbod wrote: >> > > >>>>>>>>> All of you have asked me about the status of color fonts >> > > in >> > > >>>>>>>>> cairo. There's >> > > >>>>>>>>> some discussion here: >> > > >>>>>>>> >> > > >>>>>>>> what was the solution to make this fit into cairo's >> > > drawing model? >> > > >>>>>>>> Text >> > > >>>>>>>> / glyphs are used as a mask and a mask does not have >> > > colors. >> > > >>>>>>>> >> > > >>>>>>> >> > > >>>>>>> There is no solution to that. The assumption in cairo's >> > > drawing model >> > > >>>>>>> about glyphs/fonts has simply been invalidated by reality. >> > > >>>>>>> >> > > >>>>>>> >> > > >>>>>>> Correct. >> > > >>>>>> >> > > >>>>>> Okay... so what is the new model? What happens when I draw a >> > > color >> > > >>>> glyph >> > > >>>>>> with operator XOR and a red source? >> > > >>>>> >> > > >>>>> >> > > >>>>> The red source is ignored for color glyphs because they are >> > > used as the >> > > >>>>> source. >> > > >>>> >> > > >>>> Hi again, >> > > >>>> >> > > >>>> I just came up with another question: How are overlapping >> > > glyphs handled? >> > > >>>> >> > > >>>> Let's say I have a red glyph and a blue glyph and I draw them >> > > in such a >> > > >>>> way that they overlap. Let's say this additionally overlaps >> > > with a >> > > >>>> non-colored glyph in the same position and I use a green >> > > source with 50% >> > > >>>> alpha (cairo_set_source_rgba(cr, 0, 1, 0, 0.5)). >> > > >>>> >> > > >>>> What's the visible result? >> > > >>>> >> > > >>>> >> > > >>> Here is what my implementation does: It renders the color >> > > glyphs, in >> > > >>> order, followed by the non-color glyphs. >> > > >>> >> > > >>> In practice, I don't think the case of mixed color and non- >> > > color glyphs >> > > >>> in the same call will be all that common. >> > > >>> Most apps will explicitly set a color font just for the emoji >> > > and they >> > > >>> won't render regular text with an emoji font, >> > > >>> with the result that runs of color glyphs and non-color glyphs >> > > will >> > > >>> typically be in separate calls. >> > > >>> >> > > >> >> > > >> >> > > >> >> > > >> -- >> > > >> behdad >> > > >> http://behdad.org/ >> > > >> >> > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > "Why make things difficult, when it is possible to make them >> > > cryptic >> > > and totally illogical, with just a little bit more effort?" -- A. >> > > P. J. >> > >> > >> > >> > _______________________________________________ >> > gtk-devel-list mailing list >> > gtk-devel-list@gnome.org >> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list >> > > > > -- > behdad > http://behdad.org/ >
_______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
