Color fonts

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Color fonts

Behdad Esfahbod-3
Hello,

All of you have asked me about the status of color fonts in cairo.  There's some discussion here:
The remaining part is indeed the cairo patchset.  Matthias had a reworked version, which Chris Wilson objected to.  I agree with parts of his objection.  In particular, I don't think we should need to touch every compositor.

IMO, this is how it should work:

  - Extend glyph cache to also hold a color-glyph object possibly,

  - Early on, perhals in _cairo_surface_show_text_glyphs(), ask scaled_font to see if it has color.  If it does, call a special function that iterates over the glyphs, for each, load it and see if it has color.  Show the color ones using image ops, show the rest using text ops. Or just show all as image ops, that's feasible too.

With the above, we wouldn't need to touch any compositor whatsoever.

Unfortunately I'm too busy / lazy to do this any time soon.  However, I just bought my ticket to GUADEC, so working on it together there definitely is an option.


Cheers,
--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Color fonts

Matthias Clasen-2
On Wed, Jun 28, 2017 at 8:23 AM, Behdad Esfahbod <[hidden email]> wrote:
Hello,

All of you have asked me about the status of color fonts in cairo.  There's some discussion here:
The remaining part is indeed the cairo patchset.  Matthias had a reworked version, which Chris Wilson objected to.  I agree with parts of his objection.  In particular, I don't think we should need to touch every compositor.

IMO, this is how it should work:

  - Extend glyph cache to also hold a color-glyph object possibly,

  - Early on, perhals in _cairo_surface_show_text_glyphs(), ask scaled_font to see if it has color.  If it does, call a special function that iterates over the glyphs, for each, load it and see if it has color.  Show the color ones using image ops, show the rest using text ops. Or just show all as image ops, that's feasible too.

With the above, we wouldn't need to touch any compositor whatsoever.

Unfortunately I'm too busy / lazy to do this any time soon.  However, I just bought my ticket to GUADEC, so working on it together there definitely is an option.


Thanks for the guidance on fixing up the cairo patchset. And yay for coming to GUADEC!

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Color fonts

Matthias Clasen-2

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Color fonts

Bastien Nocera
On Thu, 2017-06-29 at 23:18 -0400, Matthias Clasen wrote:
> I had another go at this here:  https://github.com/matthiasclasen/cairo/tree/emoji-again

I rebased your old branch on top of 1.14.10 (the current stable):
https://fedorapeople.org/~hadess/emoji/cairo-emoji-5-rebased-on-1.14.10.patch
for posterity more than anything.

I've also updated the COPR. Installing both packages in there should
get you colored emojis in Characters and other GTK+ 3.x apps.

https://copr.fedorainfracloud.org/coprs/hadess/emoji/
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Matthias Clasen
In reply to this post by Behdad Esfahbod-3
On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:

> Hi,
>
> 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.
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Behdad Esfahbod-3
On Jun 30, 2017 7:51 PM, "Matthias Clasen" <[hidden email]> wrote:
On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
> Hi,
>
> 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.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Color fonts

Matthias Clasen-2
In reply to this post by Matthias Clasen-2
On Thu, Jun 29, 2017 at 11:18 PM, Matthias Clasen <[hidden email]> wrote:
I've spent some more time on this branch. It now uses paint only for clusters that consists
purely of color glyphs, rewriting the inputs to remove handled clusters, and then falls through
the show_glyphs code paths.

It seems to work ok, at least as far as gedit / pango let me test easily. I'm less confident that
the CAIRO_TEXT_CLUSTER_FLAG_BACKWARD case is entirely correct, that is hard for me
to judge.

An unrelated observation: pango treats the gap between an emoji modifier base and a variant selector
as a cursor position. That looks like a bug.
 

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Matthias Clasen-2
In reply to this post by Behdad Esfahbod-3
On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]> wrote:
On 30.06.2017 17:29, Behdad Esfahbod wrote:
> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <[hidden email]> wrote:
>
> On Fri, 2017-06-30 at 17:02 +0200, Uli Schlachter wrote:
>> Hi,
>>
>> 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.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Matthias Clasen-2
It would be great to know if this approach, following Behdad's recommendation, will be acceptable.
Review of the changes in https://github.com/matthiasclasen/cairo/tree/emoji-again would appreciated as well.
I admit that I haven't thought about necessary documentation updates yet.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Behdad Esfahbod-3
On Fri, Jul 7, 2017 at 5:55 PM, Matthias Clasen <[hidden email]> wrote:
It would be great to know if this approach, following Behdad's recommendation, will be acceptable.

Thanks for the quick implementation.  I quite like your changes and think this is the right way to do it.
 
Review of the changes in https://github.com/matthiasclasen/cairo/tree/emoji-again would appreciated as well.

I like it after your simplification.  I'll try to review the tricky part you requested.
 
I admit that I haven't thought about necessary documentation updates yet.



--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Behdad Esfahbod-3
In reply to this post by Matthias Clasen-2
On Fri, Jul 7, 2017 at 5:53 PM, Matthias Clasen <[hidden email]> wrote:
On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]> wrote:

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.

Note that while with Google's (CBDT/CBLC) and Apple's (sbix) color font formats the red source will be ignored, with the Microsoft (COLR/CPAL) and Adobe's (SVG/CPAL) the font can have color imaging as well as using the current foreground color.  So, the glyph image won't be just a source either.  It will be a mix of source and mask...  Right now those two formats are not implemented in FreeType though.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Matthias Clasen-2
In reply to this post by Matthias Clasen-2
On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <[hidden email]> wrote:
On 07.07.2017 15:23, Matthias Clasen wrote:
> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]> wrote:
>> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <[hidden email]> 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.

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Behdad Esfahbod-3
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 <[hidden email]> wrote:
On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <[hidden email]> wrote:
On 07.07.2017 15:23, Matthias Clasen wrote:
> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]> wrote:
>> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <[hidden email]> 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.



--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Behdad Esfahbod-3
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 <[hidden email]> 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 <[hidden email]> wrote:
On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <[hidden email]> wrote:
On 07.07.2017 15:23, Matthias Clasen wrote:
> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]> wrote:
>> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <[hidden email]> 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.



--



--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Behdad Esfahbod-3
On Fri, Jul 28, 2017 at 6:00 PM, Bill Spitzak <[hidden email]> wrote:
I think the stacking order of glyphs can remain undefined for
cairo_show_glyphs. This seems more like something pango would be in
charge of.

We are talking about order of glyphs drawn in one cairo_show_glyphs(), so I don't see how this is pango's job.
 

On Fri, Jul 28, 2017 at 7:38 AM, Behdad Esfahbod <[hidden email]> 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 <[hidden email]> 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
>> <[hidden email]> wrote:
>>>
>>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <[hidden email]> wrote:
>>>>
>>>> On 07.07.2017 15:23, Matthias Clasen wrote:
>>>> > On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]> wrote:
>>>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>>>> >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <[hidden email]>
>>>> >>> 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/
>
>
>
>
> --
> behdad
> http://behdad.org/
>
> --
> cairo mailing list
> [hidden email]
> https://lists.cairographics.org/mailman/listinfo/cairo



--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Behdad Esfahbod-3
In reply to this post by Behdad Esfahbod-3
On Sat, Jul 29, 2017 at 11:58 AM, Uli Schlachter <[hidden email]> 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 <[hidden email]> 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 <
>> [hidden email]> wrote:
>>
>>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <[hidden email]> wrote:
>>>
>>>> On 07.07.2017 15:23, Matthias Clasen wrote:
>>>>> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]> wrote:
>>>>>> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>>>>>>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <[hidden email]>
>>>> 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
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Ben Iofel
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 <[hidden email]>
> 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 <[hidden email]
> > 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 <
> > >> [hidden email]> wrote:
> > >>
> > >>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <[hidden email]
> > > wrote:
> > >>>
> > >>>> On 07.07.2017 15:23, Matthias Clasen wrote:
> > >>>>> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]
> > 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
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Behdad Esfahbod-3
Should be fixed.  Thanks!

On Sat, Jul 29, 2017 at 4:45 PM, <[hidden email]> 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=<a href="tel:3646361312" value="+13646361312">3646361312)
at cairo-error.c:68
#5  0x00007fd0f1367802 in _cairo_set_error (cr=0x3dd89ecc00,
status=<a href="tel:3646361312" value="+13646361312">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 <[hidden email]>
> 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 <[hidden email]
> > 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 <
> > >> [hidden email]> wrote:
> > >>
> > >>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <[hidden email]
> > > wrote:
> > >>>
> > >>>> On 07.07.2017 15:23, Matthias Clasen wrote:
> > >>>>> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]
> > 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
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list



--

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Ben Iofel

Looks great!


On Sat, Jul 29, 2017, 5:43 PM Behdad Esfahbod <[hidden email]> wrote:
Should be fixed.  Thanks!

On Sat, Jul 29, 2017 at 4:45 PM, <[hidden email]> 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=<a href="tel:3646361312" value="+13646361312" target="_blank">3646361312)
at cairo-error.c:68
#5  0x00007fd0f1367802 in _cairo_set_error (cr=0x3dd89ecc00,
status=<a href="tel:3646361312" value="+13646361312" target="_blank">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 <[hidden email]>
> 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 <[hidden email]
> > 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 <
> > >> [hidden email]> wrote:
> > >>
> > >>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <[hidden email]
> > > wrote:
> > >>>
> > >>>> On 07.07.2017 15:23, Matthias Clasen wrote:
> > >>>>> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <[hidden email]
> > 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
> [hidden email]
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list

_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [cairo] Color fonts

Ben Iofel
In reply to this post by Behdad Esfahbod-3
Another crash:

Paste this into gedit:

 👍 👎 👌 👊 ✊ ✌ 👋 ✋ 👐 👆 👇 👉 👈 🙌 🙏 ☝ 👏 💪 💅 ⬇ ⬅ ➡ ↗ ↖ ↘ ↙ ↔
↕ 🔄 ◀ ▶ 🔼 🔽 ↩ ↪ ⏪ ⏩ ⏫ ⏬ ⤵ ⤴ 🔀 🔁 🔂 🔝 🔚 🔙 🔛 🔜 🔃 🔺 🔻 ⬆

and then select it


Pango:ERROR:pango-glyph-item.c:320:pango_glyph_item_iter_next_cluster:
assertion failed: (iter->end_char <= item->num_chars)


#0  0x00007fd51d29a68b in raise () at /lib64/libc.so.6
#1  0x00007fd51d29c417 in abort () at /lib64/libc.so.6
#2  0x00007fd51d8da26d in g_assertion_message () at /lib64/libglib-
2.0.so.0
#3  0x00007fd51d8da2fa in g_assertion_message_expr () at
/lib64/libglib-2.0.so.0
#4  0x00007fd51f178076 in  () at /lib64/libpango-1.0.so.0
#5  0x00007fd51f3b110f in pango_cairo_renderer_draw_glyph_item () at
/lib64/libpangocairo-1.0.so.0
(gdb) bt 300
#0  0x00007fd51d29a68b in raise () at /lib64/libc.so.6
#1  0x00007fd51d29c417 in abort () at /lib64/libc.so.6
#2  0x00007fd51d8da26d in g_assertion_message () at /lib64/libglib-
2.0.so.0
#3  0x00007fd51d8da2fa in g_assertion_message_expr () at
/lib64/libglib-2.0.so.0
#4  0x00007fd51f178076 in  () at /lib64/libpango-1.0.so.0
#5  0x00007fd51f3b110f in pango_cairo_renderer_draw_glyph_item () at
/lib64/libpangocairo-1.0.so.0
#6  0x00007fd51f184e1e in pango_renderer_draw_glyph_item () at
/lib64/libpango-1.0.so.0
#7  0x00007fd51f3b15fd in pango_cairo_show_glyph_item () at
/lib64/libpangocairo-1.0.so.0
#8  0x00007fd51fba7816 in gtk_text_renderer_draw_glyph_item
(renderer=0x39caad6040, text=0x39c9fe7c50 "👍 👎 👌 👊 ✊ ✌ 👋 ✋ 👐 👆
👇 👉 👈 🙌 🙏 ☝ 👏 💪 💅 ⬇ ⬅ ➡ ↗ ↖ ↘ ↙ ↔ ↕ 🔄 ◀ ▶ 🔼 🔽 ↩ ↪ ⏪ ⏩ ⏫ ⏬  
 \265 ⤴ 🔀 🔁 🔂", <incomplete sequence \360\237\224>.
.., glyph_item=0x39ca1cf810, x=932864, y=14336) at gtktextdisplay.c:334
#9  0x00007fd51f184e1e in pango_renderer_draw_glyph_item () at
/lib64/libpango-1.0.so.0
#10 0x00007fd51f1858b1 in pango_renderer_draw_layout_line () at
/lib64/libpango-1.0.so.0
#11 0x00007fd51fba817a in render_para (selection_end_index=-1,
selection_start_index=-1, line_display=<optimized out>,
text_renderer=<optimized out>) at gtktextdisplay.c:705
#12 0x00007fd51fba817a in gtk_text_layout_draw (layout=0x39ca4e5d40, wi
dget=widget@entry=0x39ca5e8610, cr=cr@entry=0x39cab3ab70, widgets=widge
ts@entry=0x0)
    at gtktextdisplay.c:942
#13 0x00007fd51fbc6504 in gtk_text_view_paint (cr=0x39cab3ab70,
widget=0x39ca5e8610) at gtktextview.c:5867
#14 0x00007fd51fbc6504 in draw_text (cr=0x39cab3ab70,
user_data=0x39ca5e8610) at gtktextview.c:5908
#15 0x00007fd51fb333f0 in _gtk_pixel_cache_repaint
(user_data=0x39ca5e8610, canvas_rect=0x7ffc9f295740,
view_rect=0x7ffc9f295730, draw=0x7fd51fbc6290 <draw_text>,
window=0x39caae2340, cache=0x39ca5e0d00) at gtkpixelcache.c:357
#16 0x00007fd51fb333f0 in _gtk_pixel_cache_draw (cache=0x39ca5e0d00, cr
=cr@entry=0x39ca4fc8b0, window=window@entry=0x39caae2340, view_rect=vie
w_rect@entry=0x7ffc9f295730, canvas_rect=canvas_rect@entry=0x7ffc9f2957
40, draw=draw@entry=0x7fd51fbc6290 <draw_text>, user_data=0x39ca5e8610)
at gtkpixelcache.c:447
#17 0x00007fd51fbcb970 in gtk_text_view_draw (widget=0x39ca5e8610,
cr=0x39ca4fc8b0) at gtktextview.c:5998
#18 0x00007fd52040db2d in gtk_source_view_draw () at
/lib64/libgtksourceview-3.0.so.1
#19 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca5e8610, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#20 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca32f7f0, child=0x39ca5e8610, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#21 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca32f7f0,
cr=0x39ca4fc8b0) at gtkcontainer.c:3658
#22 0x00007fd51fb6164b in gtk_scrolled_window_render (gadget=<optimized
out>, cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>, data=0x0) at
gtkscrolledwindow.c:2078
#23 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#24 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca4095e0,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#25 0x00007fd51fb5f931 in gtk_scrolled_window_draw (widget=<optimized
out>, cr=<optimized out>) at gtkscrolledwindow.c:2989
#26 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca32f7f0, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#27 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca05c2c0, child=0x39ca32f7f0, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#28 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca05c2c0, cr=c
r@entry=0x39ca4fc8b0) at gtkcontainer.c:3658
#29 0x00007fd51f9c3b14 in gtk_box_draw_contents (gadget=<optimized
out>, cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>, unused=0x0) at
gtkbox.c:448
#30 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#31 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca409660,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#32 0x00007fd51f9c64b1 in gtk_box_draw (widget=<optimized out>,
cr=<optimized out>) at gtkbox.c:457
#33 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca05c2c0, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#34 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca49a3c0, child=0x39ca05c2c0, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#35 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca49a3c0,
cr=0x39ca4fc8b0) at gtkcontainer.c:3658
#36 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca49a3c0, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#37 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca3a9870, child=0x39ca49a3c0, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#38 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca3a9870, cr=c
r@entry=0x39ca4fc8b0) at gtkcontainer.c:3658
#39 0x00007fd51fa93324 in gtk_grid_render (gadget=<optimized out>,
cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>, width=<optimized
out>, height=<optimized out>, data=0x0) at gtkgrid.c:1713
#40 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#41 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca22b260,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#42 0x00007fd51fa94461 in gtk_grid_draw (widget=<optimized out>,
cr=<optimized out>) at gtkgrid.c:1722
#43 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca3a9870, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#44 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca2b9660, child=0x39ca3a9870, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#45 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca2b9660,
cr=0x39ca4fc8b0) at gtkcontainer.c:3658
#46 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca2b9660, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#47 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39c9fcdf10, child=0x39ca2b9660, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#48 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39c9fcdf10, cr=c
r@entry=0x39ca4fc8b0) at gtkcontainer.c:3658
#49 0x00007fd51f9c3b14 in gtk_box_draw_contents (gadget=<optimized
out>, cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>, unused=0x0) at
gtkbox.c:448
#50 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#51 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca22b4e0,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#52 0x00007fd51f9c64b1 in gtk_box_draw (widget=<optimized out>,
cr=<optimized out>) at gtkbox.c:457
#53 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39c9fcdf10, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#54 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca2ba260, child=0x39c9fcdf10, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#55 0x00007fd51fb03bb2 in gtk_notebook_draw_stack (gadget=<optimized
out>, cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>, unused=0x0) at
gtknotebook.c:2515
#56 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#57 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=gadget@entry=0x39
ca1bd7a0, cr=cr@entry=0x39ca4fc8b0) at gtkcssgadget.c:877
#58 0x00007fd51f9c7d08 in gtk_box_gadget_draw (gadget=<optimized out>,
cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>, width=<optimized
out>, height=<optimized out>)
    at gtkboxgadget.c:512
#59 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca258b30, cr=
cr@entry=0x39ca4fc8b0) at gtkcssgadget.c:877
#60 0x00007fd51fb0639c in gtk_notebook_draw (widget=<optimized out>,
cr=0x39ca4fc8b0) at gtknotebook.c:2530
#61 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca2ba260, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#62 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca2b2a40, child=0x39ca2ba260, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#63 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca2b2a40, cr=c
r@entry=0x39ca4fc8b0) at gtkcontainer.c:3658
#64 0x00007fd51fa93324 in gtk_grid_render (gadget=<optimized out>,
cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>, width=<optimized
out>, height=<optimized out>, data=0x0) at gtkgrid.c:1713
#65 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#66 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca1bd620,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#67 0x00007fd51fa94461 in gtk_grid_draw (widget=<optimized out>,
cr=<optimized out>) at gtkgrid.c:1722
#68 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca2b2a40, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#69 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca05bbc0, child=0x39ca2b2a40, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#70 0x00007fd51fb12e50 in gtk_paned_render (gadget=<optimized out>,
cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>, width=<optimized
out>, height=<optimized out>, data=0x0) at gtkpaned.c:1818
#71 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#72 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca1bd1a0,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#73 0x00007fd51fb12c61 in gtk_paned_draw (widget=<optimized out>,
cr=<optimized out>) at gtkpaned.c:1782
#74 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca05bbc0, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#75 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca05cf20, child=0x39ca05bbc0, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#76 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca05cf20, cr=c
r@entry=0x39ca4fc8b0) at gtkcontainer.c:3658
#77 0x00007fd51f9c3b14 in gtk_box_draw_contents (gadget=<optimized
out>, cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>, unused=0x0) at
gtkbox.c:448
#78 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#79 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca236f10,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#80 0x00007fd51f9c64b1 in gtk_box_draw (widget=<optimized out>,
cr=<optimized out>) at gtkbox.c:457
#81 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca05cf20, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#82 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca05b800, child=0x39ca05cf20, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#83 0x00007fd51fb12dc0 in gtk_paned_render (gadget=<optimized out>,
cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>, width=<optimized
out>, height=<optimized out>, data=0x0) at gtkpaned.c:1832
#84 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#85 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca1de400,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#86 0x00007fd51fb12c61 in gtk_paned_draw (widget=<optimized out>,
cr=<optimized out>) at gtkpaned.c:1782
#87 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca05b800, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#88 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca05cb00, child=0x39ca05b800, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#89 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca05cb00, cr=c
r@entry=0x39ca4fc8b0) at gtkcontainer.c:3658
#90 0x00007fd51f9c3b14 in gtk_box_draw_contents (gadget=<optimized
out>, cr=0x39ca4fc8b0, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>, unused=0x0) at
gtkbox.c:448
#91 0x00007fd51fa16b3d in gtk_css_custom_gadget_draw (gadget=<optimized
out>, cr=<optimized out>, x=<optimized out>, y=<optimized out>,
width=<optimized out>, height=<optimized out>) at
gtkcsscustomgadget.c:159
#92 0x00007fd51fa1b8a3 in gtk_css_gadget_draw (gadget=0x39ca1de200,
cr=0x39ca4fc8b0) at gtkcssgadget.c:877
#93 0x00007fd51f9c64b1 in gtk_box_draw (widget=<optimized out>,
cr=<optimized out>) at gtkbox.c:457
#94 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca05cb00, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#95 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca2b1860, child=0x39ca05cb00, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#96 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca2b1860,
cr=0x39ca4fc8b0) at gtkcontainer.c:3658
#97 0x00007fd51fc2d7cb in gtk_widget_draw_internal (widget=widget@entry
=0x39ca2b1860, cr=cr@entry=0x39ca4fc8b0, clip_to_size=clip_to_size@entr
y=1) at gtkwidget.c:7017
#98 0x00007fd51fa11ad8 in gtk_container_propagate_draw (container=conta
iner@entry=0x39ca18d030, child=0x39ca2b1860, cr=cr@entry=0x39ca4fc8b0)
at gtkcontainer.c:3838
#99 0x00007fd51fa11bc2 in gtk_container_draw (widget=0x39ca18d030,
cr=0x39ca4fc8b0) at gtkcontainer.c:3658
#100 0x00007fd51fc3b5b3 in gtk_window_draw (widget=0x39ca18d030,
cr=0x39ca4fc8b0) at gtkwindow.c:10214
#101 0x00007fd51fc2d7cb in gtk_widget_draw_internal
(widget=0x39ca18d030, cr=0x39ca4fc8b0, clip_to_size=<optimized out>) at
gtkwidget.c:7017
#102 0x00007fd51fc36b38 in gtk_widget_render (widget=widget@entry=0x39c
a18d030, window=0x39ca441320, region=<optimized out>) at
gtkwidget.c:17512
#103 0x00007fd51fad7239 in gtk_main_do_event (event=<optimized out>) at
gtkmain.c:1824
#104 0x00007fd51f5eb465 in _gdk_event_emit (event=event@entry=0x7ffc9f2
97450) at gdkevents.c:73
#105 0x00007fd51f5fb7a5 in _gdk_window_process_updates_recurse_helper
(window=0x39ca441320, expose_region=<optimized out>) at
gdkwindow.c:3849
#106 0x00007fd51f5fc9a6 in gdk_window_process_updates_internal
(window=0x39ca441320) at gdkwindow.c:3995
#107 0x00007fd51f5fcba0 in gdk_window_process_updates_with_mode
(window=<optimized out>, recurse_mode=<optimized out>) at
gdkwindow.c:4189
#108 0x00007fd51db8d57d in g_closure_invoke () at /lib64/libgobject-
2.0.so.0
#109 0x00007fd51dba0e4e in signal_emit_unlocked_R () at
/lib64/libgobject-2.0.so.0
#110 0x00007fd51dba9975 in g_signal_emit_valist () at
/lib64/libgobject-2.0.so.0
#111 0x00007fd51dbaa2df in g_signal_emit () at /lib64/libgobject-
2.0.so.0
#112 0x00007fd51f5f428f in _gdk_frame_clock_emit_paint
(frame_clock=<optimized out>) at gdkframeclock.c:640
#113 0x00007fd51f5f49c1 in gdk_frame_clock_paint_idle
(data=0x39ca024270) at gdkframeclockidle.c:430
#114 0x00007fd51f5dfb20 in gdk_threads_dispatch (data=0x39ca169d60) at
gdk.c:743
#115 0x00007fd51d8b3ffd in g_timeout_dispatch () at /lib64/libglib-
2.0.so.0
#116 0x00007fd51d8b3597 in g_main_context_dispatch () at
/lib64/libglib-2.0.so.0
#117 0x00007fd51d8b3938 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#118 0x00007fd51d8b39cc in g_main_context_iteration () at
/lib64/libglib-2.0.so.0
#119 0x00007fd51e3ea89d in g_application_run () at /lib64/libgio-
2.0.so.0
#120 0x00000039c94fddda in main ()


On Sat, 2017-07-29 at 17:43 +0100, Behdad Esfahbod wrote:

> Should be fixed.  Thanks!
>
> On Sat, Jul 29, 2017 at 4:45 PM, <[hidden email]> 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=3646361
> > 312)
> > 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 <[hidden email]>
> > > 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@behd
> > ad.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 <
> > > > >> [hidden email]> wrote:
> > > > >>
> > > > >>> On Sat, Jul 15, 2017 at 4:05 AM, Uli Schlachter <psychon@zn
> > c.in
> > > > > wrote:
> > > > >>>
> > > > >>>> On 07.07.2017 15:23, Matthias Clasen wrote:
> > > > >>>>> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter <psychon@z
> > nc.i
> > > > n> wrote:
> > > > >>>>>> On 30.06.2017 17:29, Behdad Esfahbod wrote:
> > > > >>>>>>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mclasen@red
> > hat.
> > > > 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
> > > [hidden email]
> > > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
_______________________________________________
gtk-devel-list mailing list
[hidden email]
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
12
Loading...