Maybe this is not shadow (I didn't look carefully first time): I can see shadows also. This is some other kind of trash.

Created attachment 307113 [details]
on linux everything fine

Is that with the same version of fontconfig, freetype and pango ?

Nope, I will try fontconfig, freetype and pango outside GStreamer.

Works fine here using macports: fontconfig 2.11.1, freetype 17.4.11 and pango 1.36.8

What is your command line exactly ?

My freetype version is 2.6 (from brew), pango and fontconfig versions same.
My pipeline isn't created from command line, it's a bit very difficult and created via GStreamer native C API.

Created attachment 307311 [details]
gst-launch-1.0 videotestsrc num-buffers=1 ! te xtoverlay text="grasshoper" font-desc="Sans 72" valignment=4 ! pngenc ! filesink location=1.png

Okay, cause of https://bugzilla.gnome.org/show_bug.cgi?id=752147 and https://bugzilla.gnome.org/show_bug.cgi?id=752146 I can not output this to screen, however, here is the way I have similar glitch with command line:

I wonder if this is a GStreamer bug. Maybe try some pango examples (out of GStreamer) and let me know.

This issue disappears with PANGOCAIRO_BACKEND=fontconfig

To me, this looks like the code to get the vectorial paths from the font is broken with coretext, I believe coretext backen is completly broken. Looks like a bug to report to Pango, not GStreamer (a standalone pango text could be nice).

Could we just change the product field of this bug from GStreamer to Pango ? At least to check if they know the problem. If not then make a standalone app.

From GStreamer side we can still track the problem here https://bugzilla.gnome.org/show_bug.cgi?id=752147
Which has an attached patch. That set the backend to FT.

Let's try.

(In reply to Nicolas Dufresne (stormer) from comment #10)
> To me, this looks like the code to get the vectorial paths from the font is
> broken with coretext, I believe coretext backen is completly broken

What leads you to believe the coretext 'backen' is completely broken? It is actually working well for many GTK+ applications.

A standalone Pango test case that demonstrates the problem would be appreciated.

(In reply to Kristian Rietveld from comment #13)
> (In reply to Nicolas Dufresne (stormer) from comment #10)
> > To me, this looks like the code to get the vectorial paths from the font is
> > broken with coretext, I believe coretext backen is completly broken
> What leads you to believe the coretext 'backen' is completely broken? It is
> actually working well for many GTK+ applications.

That's all according to the screenshot. Text looks like text but has nothing to do with the given description (at least the result has nothing to do with what fontconfig backend endup producing). Shadow, which theoretically is just a simple translation of that path (to the right and bottom by default) endup as a mess. Reporter might have tested wrong, I have no mean to test anything on OSX. Though, same code should give similar result regardless of the backend.

> A standalone Pango test case that demonstrates the problem would be
> appreciated.

Indeed, anyone that owns a Mac to take care of writing a standalone test, and maybe narrow down the scope ?

(In reply to Nicolas Dufresne (stormer) from comment #14)
> > A standalone Pango test case that demonstrates the problem would be
> > appreciated.
> 
> Indeed, anyone that owns a Mac to take care of writing a standalone test,
> and maybe narrow down the scope ?

If somebody can point out what the steps to reproduce are or point me to the related code in GStreamer, I can also try to write the testcase.

That would be really appreciated of course. Here's the line where the shadow is drawn.

http://cgit.freedesktop.org/gstreamer/gst-plugins-base/tree/ext/pango/gstbasetextoverlay.c#n1747

Which is followed by outline and the foreground/text. One interesting part is that there is very little difference between drawing the shadow and drawing the foreground text. The two differences is that the foreground attributes are filtered-out for this rendering, which gives option a) disabling a specific foreground attribute breaks the rendering. The second difference is that we translate the rendering, so option b) would be the something goes terribly wrong (aka overflow) upon translation.

But before stating that, I want to retract the comment about the rest being broken. I just notice that font-desc (the font description) is "Sans", which could match pretty much be any kind font type. So I believe the font rendering part might be fine (except that you'll notice this is a Serif font, not Sans).

A second thought is that this mess could actually be the outline rather then the shadow. Both shadow and foreground uses pango_cairo_show_layout (cr, overlay->layout);, while the outline uses pango_cairo_layout_path(). So it give a likely option c) that pango_cairo_layout_path() is broken with coretext. This is reinforced by the fact that something look like a shadow on the leg of the P.

Created attachment 310979 [details]
Pangon+Cairo+Coretext with newlines

Created attachment 310980 [details]
Few more examples

That was Liberation Sans Mono.

Here other fonts:

Ok, I think these examples makes it very clear that it's the drawing of the outline that fails (which invalidate option a and b). You can confirm this by setting the outline color to 0 (transparent).

Created attachment 311183 [details]
Output of simple GTK+ test program

This is what I get when I put the minimum of the referenced GStreamer code in a GTK+ test program (based on testcairo.c). The outline is rendered in green. It seems to be the outline is rendered correctly in this case (and pango_cairo_layout_path() is used for this, like it is in the GStreamer code). The rendered shadow is visible too.

Now, the GTK+ tester renders to a Cairo context provided by GDK, the GStreamer code renders to an image surface it creates. I wonder whether this makes a difference and that's the next thing to find out.

What I do gather from Kyrylo's images is that the outline is in fact rendered, but it seems at a completely wrong scaling factor.

(In reply to Kyrylo V. Polezhaiev from comment #6)
> My freetype version is 2.6 (from brew), pango and fontconfig versions same.
> My pipeline isn't created from command line, it's a bit very difficult and
> created via GStreamer native C API.

What version of Cairo do you have installed?

1.14.2

Glitch disappears when outline colour's alpha set to 0.

I can reproduce the problem using this example:
http://x11.gp2x.de/personal/google/example2.c

bug appears when you replace

    pango_cairo_show_layout (cr, layout);

with
	
    pango_cairo_update_layout(cr, layout);
    pango_cairo_layout_path(cr, layout);

(In reply to Kyrylo V. Polezhaiev from comment #23)
> Glitch disappears when outline colour's alpha set to 0.

I think that makes sense, because in this case the outline is not visibly drawn at all.



(In reply to Kyrylo V. Polezhaiev from comment #24)
> I can reproduce the problem using this example:
> http://x11.gp2x.de/personal/google/example2.c

To ensure: without modification this code shows you the problem?

I *think* it's a cairo bug, when I downgrade to 1.14.2 from master, the issue appears. Will do a bisect so I can pinpoint the affecting commit for you and see if that commit explains it.

Confirmed that this is a cairo issue. To have it fixed, you need a cairo that includes this commit:

commit 8b798c320f6fd2d87349d0a716304474022bc5ea
Author: Bryce Harrington <bryce@osg.samsung.com>
Date:   Fri Apr 24 18:23:46 2015 -0700

    Fix broken canvas text font size in Inkscape

    An earlier fix to bug 84324 added a regression in the font size of
    canvas text in Inkscape when compiled with the Quartz backend.

    Patch from Andrea Canciani

    Fixes:  https://bugs.freedesktop.org/show_bug.cgi?id=84324
    Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>


However, from what I can gather the last cairo release is 1.14.2, which does *not* include this commit. So you need to fetch cairo from git or wait for the next release.

Do you want to reassign this bug back to gstreamer or should we close it here?

Let's mark as duplicate?

Thanks a lot for going through this, it is really appreciated.

(In reply to Kristian Rietveld from comment #26)
> To ensure: without modification this code shows you the problem?
Yes, and I can switch problem on / off via switching between pango_cairo_show_layout (cr, layout) and pango_cairo_layout_path (cr, layout)

Interesting, there is a workaround without updating pango?

(In reply to Nicolas Dufresne (stormer) from comment #32)
> Interesting, there is a workaround without updating pango?

Again: it is not a bug in Pango, it is a bug in cairo. I am not sure you can workaround it without updating cairo, the problem is a wrong parameter that is passed to a font creation call by cairo. It is probably also not worth investigating a workaround as you can simply use Cairo master or wait for Cairo 1.14.4 which from what I have heard will be released shortly.

Resolving as not GNOME, since this is not a Pango issue.

Moved back to GStreamer to keep it around until we bump cerbero's cairo recipe to 1.14.4: http://cgit.freedesktop.org/gstreamer/cerbero/tree/recipes/cairo.recipe

I prefer a clean bug in fact.

*** This bug has been marked as a duplicate of bug 755423 ***

Fixed by https://bugzilla.gnome.org/show_bug.cgi?id=755423