Re: pango vs. libraqm

[Behdad Esfahbod]

Hi Daniel,

On Fri, Jan 11, 2019 at 7:34 PM Daniel G via gtk-i18n-list <
gtk-i18n-list@gnome.org> wrote:

> Hello Pango wizards,
>
> Could someone provide an overview (via a bulleted list, perhaps) of what
> additional functionality Pango provides, over something minimal like
> libraqm?
>

Comparing PangoLayout to libraqm is valid.  As far as I understand, and
Khaled can correct me, raqm does not do font fallback and line breaking
currently, nor does it do font enumeration.  Raqm is designed to add to
applications that otherwise have a very simplistic view of text rendering.
Ie. they use FreeType and a single font to render single-line text (think,
movie subtitles...).  Raqm can very easily add complex text rendering
support to such systems.

I'm asking because I'm trying to understand text layout at a deeper level,
> without having to get my hands too dirty (prematurely) poring over source
> code. But I fully expect that will be necessary before long ...
>
> (On that note, thank you Behdad for "State of Text Rendering" - very
> helpful)
>

Thanks.  Needs update...


>
> cheers,
> -d
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Linking to libstdc++ in HarfBuzz

[Behdad Esfahbod]

Hi,

Just asking, does anybody still object about using C++ standard library
(ie. linking to it) in HarfBuzz?

I know I've been one of the bigger opponents myself.  But I can change too.
:)

-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Emoji with CoreText

[Behdad Esfahbod]

But yeah, one thing is true: when you see "emoji" in the requeste font
family, you should replace it with Apple Color Emoji.

On Tue, May 22, 2018 at 4:28 PM, John Ralls <jra...@ceridwen.fremont.ca.us>
wrote:

>
> Behdad,
>
> OK, thanks.
>
> Regards,
> John Ralls
>
> > On May 22, 2018, at 4:07 PM, Behdad Esfahbod <beh...@behdad.org> wrote:
> >
> > Hi John,
> >
> > I don't know how the CoreText backends in Pango / Cairo work. Cannot
> help I'm afraid :(.
> >
> > On Fri, May 18, 2018 at 12:01 PM, John Ralls <
> jra...@ceridwen.fremont.ca.us> wrote:
> > Behdad,
> >
> > Even with gtk-3.22.30, cairo-1.15.12, and pango 1.40.12 I'm not able to
> get most emoji (and not just the color ones) to display in GtkEntry or even
> in the Gtk emoji picker. I've tried setting font-family: Apple Color Emoji
> in gtk.css. Does the pango CoreText backend need some work to support this?
> How about flipping the font family to Apple Color Emoji to display the
> emoji block of code points if a different family is used for the "regular"
> text?
> >
> > Regards,
> > John Ralls
> >
> >
> >
> >
> > --
> > behdad
> > http://behdad.org/
>
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Emoji with CoreText

[Behdad Esfahbod]

Hi John,

I don't know how the CoreText backends in Pango / Cairo work. Cannot help
I'm afraid :(.

On Fri, May 18, 2018 at 12:01 PM, John Ralls 
wrote:

> Behdad,
>
> Even with gtk-3.22.30, cairo-1.15.12, and pango 1.40.12 I'm not able to
> get most emoji (and not just the color ones) to display in GtkEntry or even
> in the Gtk emoji picker. I've tried setting font-family: Apple Color Emoji
> in gtk.css. Does the pango CoreText backend need some work to support this?
> How about flipping the font family to Apple Color Emoji to display the
> emoji block of code points if a different family is used for the "regular"
> text?
>
> Regards,
> John Ralls
>
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: pango-view --backend=cairo doesn't use fontconfig - why not?

[Behdad Esfahbod]

Try setting env var PANGOCAIRO_BACKEND=fc

On Wed, Apr 25, 2018 at 10:37 PM, <pa...@parvis.nl> wrote:

> On Wed, Apr 25, 2018 at 4:27 PM,  <pa...@parvis.nl> wrote:
>
>>
>> pango-view --backend=cairo doesn't use fontconfig - why not?
>
>
>
> On 2018-04-25, at 22:19, Behdad Esfahbod <beh...@behdad.org> wrote:
>
> What makes you think so?
>
>
> please note: I'm talking about my own installation here.
>
> - the output of mango-view with backend xft or ft2 is the real
> dejavusansmono. backend cairo is helvetica.
> - opensnoop (open/close tracer for mac osx) show open for helvetica and
> not for fc libs.
> - setting FC_DEBUG shows nothing for cairo and everything for the other 2.
>
> my latest hunch is that it has to do with the quartz and x11 options for
> macports compilations. it seems that if i disable quartz and enable x11 it
> works, and i'm now trying to prove that now. on macports one cannot disable
> quartz so this takes a long patch cycle.
>
> paul.
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: pango-view --backend=cairo doesn't use fontconfig - why not?

[Behdad Esfahbod]

On Wed, Apr 25, 2018 at 4:27 PM,  wrote:

>
> pango-view --backend=cairo doesn't use fontconfig - why not?
>

What makes you think so?


> I compiled cairo & pango with fontconfig enabled.
>
> pango-view backends aft and ft2 do use fontconfig, cairo doesn't.
>
> Whant can I do to enable fontconfig in pangocairo?
>
> --
> thanks,
> paul.
>
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: What's the deal with 'pango-bidi-type.c' ?

[Behdad Esfahbod]

On Thu, Mar 8, 2018 at 1:36 AM, John Emmas <j...@creativepost.co.uk> wrote:

> On 07/03/2018 22:05, Behdad Esfahbod wrote:
>
>> Yes. You need the external fribidi library now.
>>
>>
> Okay Behdad, thanks.
>
> I installed fribidi (from (git) and decided to use it as my first foray
> into building with meson.


I haven't used meson, so someone else should jump in.


>   I installed meson and ran this command after reading the "quick start"
> guide:-
>
>  meson builddir && cd builddir
>
> According to the quick guide, meson will produce VC and XCode project
> files.  It did produce a "builddir" subdirectory but the builddir seems to
> be mostly empty.  It's built something called 'sanitycheck.exe' but I'm not
> seeing a built library, nor any project files for building one.  This is my
> first attempt at meson so I'm probably doing something stupid.  Do I need
> to use a different command?
>
>
> John
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: What's the deal with 'pango-bidi-type.c' ?

[Behdad Esfahbod]

Yes. You need the external fribidi library now.

On Wed, Mar 7, 2018, 6:16 PM John Emmas,  wrote:

> I just updated pango from git master and noticed commit #0a71013dfc
> (13th Nov 2017) which reads "Drop now unused mini-fribidi".
>
> Maybe I'm confused about something but pango itself looks like
> "pango-bidi-type.c" is still included in the build.  In fact, it's
> needed for a couple of functions - such as
> 'pango_log2vis_get_embedding_levels()'.  However, 'pango-bidi-type.c'
> #includes  which doesn't exist any more.
>
> Or does mini-fribidi now need to get built as a separate library? Thanks,
>
> John
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Getting different sizes from pango_layout_get_pixel_extents on ubuntu 16.04 vs 17.10?

[Behdad Esfahbod]

FreeType often changes things enough to result in such differences...

On Wed, Jan 31, 2018 at 7:54 AM, Dan Kegel  wrote:

> On Wed, Jan 31, 2018 at 1:30 AM, Alexander Larsson 
> wrote:
> >> It gets a slightly different result depending on operating system.
> >
> > The font file contains most of the layout information, but fontconfig
> > also reads various config snippets from /etc/fonts/conf.d/ that can
> > affect the rendering. For example, there are often configuration
> > options that affect hinting.
>
> Great tip, thanks, but no obvious smoking guns in that directory.
>
> Is there an easy api for retrieving the hinting etc. settings
> that I could add to the example program to test your theory
> towards the end of the sausage-making process?
> Thanks!
> - Dan
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Variable fonts redux

[Behdad Esfahbod]

This branch is now IMO complete and ready to be merged:

https://github.com/behdad/fontconfig/commits/varfonts2

I'll merge tomorrow if there's no comments.

Cheers,
b

On Sat, Sep 16, 2017 at 1:49 PM, Behdad Esfahbod <beh...@behdad.org> wrote:

> Hi,
>
> Previously I have had implemented and merged support for named-instances
> in variable fonts, but the generic variation mechanism was not integrated.
> I've finished the core of what was left of implementing variable fonts in
> fontconfig:
>
>   https://github.com/behdad/fontconfig/commits/varfonts2
>
> High-level changes are:
>
>   - Add FC_FONT_VARIATIONS (string): this one is easy.  The library
> doesn't do anything about it.  It's like FC_FONT_FEATURES. Client sets and
> then retrieves. Primarily useful for non-standard variation axes,
>
>   - Add FC_VARIABLE (bool), which is at the core of varfont support.
>
> All font patterns that were discovered previously will get
> FC_VARIABLE=False When querying fonts with (the new)
> FcFreeTypeQueryFaceAll(), or when face index has top 16 bits (instance
> index) set to 0x8000, then a pattern is created for the variable font as a
> whole.  This pattern is only generated if there's actual variation in at
> least one of weight, width, and optical size axes. This pattern then might
> have ranges for FC_WEIGHT, FC_WIDTH, and FC_SIZE, and has FC_VARIABLE=True.
>
>   - FC_WIDTH and FC_WEIGHT are now typed as ranges instead of double.
>
>   - Fix matching and comparison logic with ranges to behave as we expect.
>
>   - In FcDefaultSubstitute(), set FC_VARIABLE to false if it's unset.
> FC_VARIABLE has very high match priority, so this takes care of backward
> compatibility with clients that do not support variable fonts by pushing
> them to the very back of fallback list.
>
>   - In FcFontRenderPrepare, special-case ranges, such that if eg. request
> is for weight=47, and font has weight=[50,100], then rendered pattern will
> get weight=50.  For size, special case again, such that if request size=47
> and font has size=[50,100], then rendered font will have size=47.
>
>   - For clients that support variable font, eg. pango soon, they have to
> opt-in.  I could have special-cased matcher for FC_VARIABLE, such that if
> FC_VARIABLE=True, then both variable and non-variable fonts will be
> returned, but I didn't like a custom match.  Currently if FC_VARIABLE=True
> is set then variable fonts will dominate the results, even if they are not
> the best match.  To solve that:
>
>   - To solve above problem, I added a new value for FcBool: FcDontCare=2.
> Pango should set FC_VARIABLE=FcDontCare.  I was hoping to allow clients to
> tell fontconfig whether, everything else being equal, they prefer variable
> font or static font, but that needs a very low-priority element, or a hack,
> and I didn't like either, so I gave up on that.  It's not particularly
> useful anyway.
>
> Here's what's left, which I'll do in the next few days.  I just wanted to
> get this out for now.
>
>   - Config compare operations on "dontcare" are not implemented yet,
>
>   - The variable-font pattern currently has FC_STYLE set.  I think I
> should completely leave out FC_STYLE,
>
> With those fixed, I think this can be merged.  At some point I also like
> to:
>
>   - Speed up scanning of varfonts that have many named instances.  Voto
> Serif GX has over 500!  Right now we open the face and do everything from
> scratch for each named instance.  Can be considerably sped up by opening
> once and switching coordinates around...
>
>   - Expose slant & italic standard axes as well, but Fontconfig shoves
> FC_SLANT_ITALIC and FC_SLANT_OBLIQUE in the same element, with these values:
>
> #define FC_SLANT_ROMAN  0
> #define FC_SLANT_ITALIC 100
> #define FC_SLANT_OBLIQUE110
>
> The varfonts axis for italic has a 0..1 range, 1 meaning italic.  And the
> slant axis uses slant angle.  We can:
>
>   - Deprecate FC_SLANT element and add two new ones, eg FC_ITALIC and
> FC_SLANT_ANGLE.  I don't like this particularly,
>
>   - Repurpose FC_SLANT for *italic*, since the 0..1 range maps nicely to
> FC_SLANT_ITALIC=100, and add FC_SLANT_ANGLE for the slant.  I don't
> particularly like to confusing names here either.  So I'm open to
> suggestions.
>
> A point I'll raise before someone asks:
>
>   - Exposing contents of STAT table or non-standard axes is out of scope
> for fontconfig.  The rule of thumb is: if it doesn't participate in font
> selection, it does not belong to fontconfig.  Things that a font dialog
> needs should be fetched directly using FreeType or HarfBuzz.
>
>
> Cheers,
> --
> behdad
> http://behdad.org/
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [cairo] color fonts and CAIRO_OPERATOR_SOURCE

[Behdad Esfahbod]

On Wed, Sep 13, 2017 at 11:07 AM, Bill Spitzak <spit...@gmail.com> wrote:

> On Mon, Sep 11, 2017 at 10:39 PM, Behdad Esfahbod <beh...@behdad.org>
> wrote:
> > It was actually not that complicated:
> > https://bugs.freedesktop.org/show_bug.cgi?id=102661
>
> Yes that sounds just like my second suggestion.
>
> To deal with the double-premultiply, I would just special-case OVER
> (and perhaps a few other bounded operators). They cause the current
> code to be run where it uses the glyph color+alpha as the source. All
> other compositing operators ignore the glyph color, and use the glyph
> alpha as the letter shape.
>
> SOURCE can then be used to fill the glyph shapes with a constant color.
>

I'm not sure how I feel about that.


> >
> > On Mon, Sep 11, 2017 at 1:44 AM, Uli Schlachter <psyc...@znc.in> wrote:
> >>
> >> Hi everyone,
> >>
> >> yesterday I was asked to comment here:
> >>
> >> https://github.com/i3/i3/pull/2925
> >>
> >> The issue seems to be: With operator SOURCE, drawing a color glyph
> >> clears the entire surface. So, while "normal" glyphs are supposed to be
> >> a mask that is then filled, color glyphs seem to be handled as an
> >> unbounded source. This doesn't make a difference for OVER, but for lots
> >> of other operators (at least SOURCE) it obviously matters.
> >>
> >> I didn't investigate this at all. I did not even try to reproduce.
> >> Hence, this ping. Could one of you please look at this, confirm this
> >> really happens, and say what should be done about this? Thanks.
> >>
> >> And yes, in the thread on color fonts, Matthias Clasen answered one of
> >> my questions with:
> >>
> >> >> 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.
> >>
> >> So apparently this behaviour is by design, meaning that glyphs can only
> >> really be used with operator OVER any more (well, and some others). So
> >> let me ask this another why: Is this really a good behaviour?
> >>
> >> Oh and one more thing: Who updates cairo's docs and all the explanations
> >> on the web page? ("glyphs work like this, except when they do not").
> >>
> >> Cheers,
> >> Uli
> >>
> >> P.S.: The list of recipents is copied from the recent thread on color
> >> fonts. I have no overview of how people ended up in this list. Sorry if
> >> $YOU are the wrong recipent.
> >> P.P.S: Yes, I also included Gtk-devel-list. I vaguely remember someone
> >> saying that this stuff is relevant there. Dear moderator, sorry for the
> >> work that this causes you.
> >> --
> >> 99 little bugs in the code
> >> 99 little bugs in the code
> >> Take one down, patch it around
> >> 117 little bugs in the code
> >>   -- @irqed
> >
> >
> >
> >
> > --
> > behdad
> > http://behdad.org/
> >
> > --
> > cairo mailing list
> > ca...@cairographics.org
> > https://lists.cairographics.org/mailman/listinfo/cairo
>



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Variable fonts redux

[Behdad Esfahbod]

Hi,

Previously I have had implemented and merged support for named-instances in
variable fonts, but the generic variation mechanism was not integrated.
I've finished the core of what was left of implementing variable fonts in
fontconfig:

  https://github.com/behdad/fontconfig/commits/varfonts2

High-level changes are:

  - Add FC_FONT_VARIATIONS (string): this one is easy.  The library doesn't
do anything about it.  It's like FC_FONT_FEATURES. Client sets and then
retrieves. Primarily useful for non-standard variation axes,

  - Add FC_VARIABLE (bool), which is at the core of varfont support.

All font patterns that were discovered previously will get
FC_VARIABLE=False When querying fonts with (the new)
FcFreeTypeQueryFaceAll(), or when face index has top 16 bits (instance
index) set to 0x8000, then a pattern is created for the variable font as a
whole.  This pattern is only generated if there's actual variation in at
least one of weight, width, and optical size axes. This pattern then might
have ranges for FC_WEIGHT, FC_WIDTH, and FC_SIZE, and has FC_VARIABLE=True.

  - FC_WIDTH and FC_WEIGHT are now typed as ranges instead of double.

  - Fix matching and comparison logic with ranges to behave as we expect.

  - In FcDefaultSubstitute(), set FC_VARIABLE to false if it's unset.
FC_VARIABLE has very high match priority, so this takes care of backward
compatibility with clients that do not support variable fonts by pushing
them to the very back of fallback list.

  - In FcFontRenderPrepare, special-case ranges, such that if eg. request
is for weight=47, and font has weight=[50,100], then rendered pattern will
get weight=50.  For size, special case again, such that if request size=47
and font has size=[50,100], then rendered font will have size=47.

  - For clients that support variable font, eg. pango soon, they have to
opt-in.  I could have special-cased matcher for FC_VARIABLE, such that if
FC_VARIABLE=True, then both variable and non-variable fonts will be
returned, but I didn't like a custom match.  Currently if FC_VARIABLE=True
is set then variable fonts will dominate the results, even if they are not
the best match.  To solve that:

  - To solve above problem, I added a new value for FcBool: FcDontCare=2.
Pango should set FC_VARIABLE=FcDontCare.  I was hoping to allow clients to
tell fontconfig whether, everything else being equal, they prefer variable
font or static font, but that needs a very low-priority element, or a hack,
and I didn't like either, so I gave up on that.  It's not particularly
useful anyway.

Here's what's left, which I'll do in the next few days.  I just wanted to
get this out for now.

  - Config compare operations on "dontcare" are not implemented yet,

  - The variable-font pattern currently has FC_STYLE set.  I think I should
completely leave out FC_STYLE,

With those fixed, I think this can be merged.  At some point I also like to:

  - Speed up scanning of varfonts that have many named instances.  Voto
Serif GX has over 500!  Right now we open the face and do everything from
scratch for each named instance.  Can be considerably sped up by opening
once and switching coordinates around...

  - Expose slant & italic standard axes as well, but Fontconfig shoves
FC_SLANT_ITALIC and FC_SLANT_OBLIQUE in the same element, with these values:

#define FC_SLANT_ROMAN  0
#define FC_SLANT_ITALIC 100
#define FC_SLANT_OBLIQUE110

The varfonts axis for italic has a 0..1 range, 1 meaning italic.  And the
slant axis uses slant angle.  We can:

  - Deprecate FC_SLANT element and add two new ones, eg FC_ITALIC and
FC_SLANT_ANGLE.  I don't like this particularly,

  - Repurpose FC_SLANT for *italic*, since the 0..1 range maps nicely to
FC_SLANT_ITALIC=100, and add FC_SLANT_ANGLE for the slant.  I don't
particularly like to confusing names here either.  So I'm open to
suggestions.

A point I'll raise before someone asks:

  - Exposing contents of STAT table or non-standard axes is out of scope
for fontconfig.  The rule of thumb is: if it doesn't participate in font
selection, it does not belong to fontconfig.  Things that a font dialog
needs should be fetched directly using FreeType or HarfBuzz.


Cheers,
-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: color fonts and CAIRO_OPERATOR_SOURCE

[Behdad Esfahbod]

It was actually not that complicated:
https://bugs.freedesktop.org/show_bug.cgi?id=102661

On Mon, Sep 11, 2017 at 1:44 AM, Uli Schlachter  wrote:

> Hi everyone,
>
> yesterday I was asked to comment here:
>
> https://github.com/i3/i3/pull/2925
>
> The issue seems to be: With operator SOURCE, drawing a color glyph
> clears the entire surface. So, while "normal" glyphs are supposed to be
> a mask that is then filled, color glyphs seem to be handled as an
> unbounded source. This doesn't make a difference for OVER, but for lots
> of other operators (at least SOURCE) it obviously matters.
>
> I didn't investigate this at all. I did not even try to reproduce.
> Hence, this ping. Could one of you please look at this, confirm this
> really happens, and say what should be done about this? Thanks.
>
> And yes, in the thread on color fonts, Matthias Clasen answered one of
> my questions with:
>
> >> 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.
>
> So apparently this behaviour is by design, meaning that glyphs can only
> really be used with operator OVER any more (well, and some others). So
> let me ask this another why: Is this really a good behaviour?
>
> Oh and one more thing: Who updates cairo's docs and all the explanations
> on the web page? ("glyphs work like this, except when they do not").
>
> Cheers,
> Uli
>
> P.S.: The list of recipents is copied from the recent thread on color
> fonts. I have no overview of how people ended up in this list. Sorry if
> $YOU are the wrong recipent.
> P.P.S: Yes, I also included Gtk-devel-list. I vaguely remember someone
> saying that this stuff is relevant there. Dear moderator, sorry for the
> work that this causes you.
> --
> 99 little bugs in the code
> 99 little bugs in the code
> Take one down, patch it around
> 117 little bugs in the code
>   -- @irqed
>



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Upright glyphs with combining marks in vertical text.

[Behdad Esfahbod]

Care filing a bug please, so we don't lose?

On Sun, Sep 10, 2017 at 4:24 AM, Behdad Esfahbod <beh...@behdad.org> wrote:

> Renders fine with hb-view, but broken with pango-view.
> I'll take a look.
>
> On Thu, Sep 7, 2017 at 1:34 AM, Tavmjong Bah <tavmj...@free.fr> wrote:
>
>> On Wed, 2017-09-06 at 12:24 -0700, Behdad Esfahbod wrote:
>> > Pictures please?
>>
>> Attached.
>>
>> > On Wed, Sep 6, 2017 at 12:07 PM, Tavmjong Bah <tavmj...@free.fr>
>> > wrote:
>> > > Hi,
>> > >
>> > > I've got two questions about rendering characters with combining
>> > > marks
>> > > (as one might have with CSS "writing-mode:vertical;text-
>> > > orientation:upright").
>> > >
>> > > It appears that Pango misplaces the marks as shown by:
>> > >
>> > > pango-view --annotate=2 --dpi=160 --gravity=east --gravity-
>> > > hint=strong
>> > > --rotate=-90 test-combining.txt
>> > >
>> > > where test-combining.txt has the following characters:
>> > >
>> > > G̃g̃X̃x̃
>> > >
>> > > 1. Is this a bug? Or am I doing something wrong?
>> > >
>> > > 2. Shouldn't the width in PangoGlyphGeometry be the vertical height
>> > > when typeset in upright vertical mode (with combining marks having
>> > > a
>> > > vertical height of zero)?
>> > >
>> > > Thanks,
>> > >
>> > > Tav
>>
>
>
>
> --
> behdad
> http://behdad.org/
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Upright glyphs with combining marks in vertical text.

[Behdad Esfahbod]

Renders fine with hb-view, but broken with pango-view.
I'll take a look.

On Thu, Sep 7, 2017 at 1:34 AM, Tavmjong Bah <tavmj...@free.fr> wrote:

> On Wed, 2017-09-06 at 12:24 -0700, Behdad Esfahbod wrote:
> > Pictures please?
>
> Attached.
>
> > On Wed, Sep 6, 2017 at 12:07 PM, Tavmjong Bah <tavmj...@free.fr>
> > wrote:
> > > Hi,
> > >
> > > I've got two questions about rendering characters with combining
> > > marks
> > > (as one might have with CSS "writing-mode:vertical;text-
> > > orientation:upright").
> > >
> > > It appears that Pango misplaces the marks as shown by:
> > >
> > > pango-view --annotate=2 --dpi=160 --gravity=east --gravity-
> > > hint=strong
> > > --rotate=-90 test-combining.txt
> > >
> > > where test-combining.txt has the following characters:
> > >
> > > G̃g̃X̃x̃
> > >
> > > 1. Is this a bug? Or am I doing something wrong?
> > >
> > > 2. Shouldn't the width in PangoGlyphGeometry be the vertical height
> > > when typeset in upright vertical mode (with combining marks having
> > > a
> > > vertical height of zero)?
> > >
> > > Thanks,
> > >
> > > Tav
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Upright glyphs with combining marks in vertical text.

[Behdad Esfahbod]

Pictures please?

On Wed, Sep 6, 2017 at 12:07 PM, Tavmjong Bah  wrote:

>
> Hi,
>
> I've got two questions about rendering characters with combining marks
> (as one might have with CSS "writing-mode:vertical;text-
> orientation:upright").
>
> It appears that Pango misplaces the marks as shown by:
>
> pango-view --annotate=2 --dpi=160 --gravity=east --gravity-hint=strong
> --rotate=-90 test-combining.txt
>
> where test-combining.txt has the following characters:
>
> G̃g̃X̃x̃
>
> 1. Is this a bug? Or am I doing something wrong?
>
> 2. Shouldn't the width in PangoGlyphGeometry be the vertical height
> when typeset in upright vertical mode (with combining marks having a
> vertical height of zero)?
>
> Thanks,
>
> Tav
>
>
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Building the enum-types (with or without pango-ot.h)

[Behdad Esfahbod]

You can ignore pango-ot.h for now.

On Mon, Aug 14, 2017 at 10:02 AM, John Emmas 
wrote:

> When generating the enum-types modules ('pango-enum-types.c' and
> 'pango-enum-types.h') should I be referencing (i.e. including) pango-ot.h
> during the process?  I only realised recently that I hadn't been including
> it.  If I do include it, an extra function gets added to the generated
> files ('pango_ot_table_type_get_type()').  But when I then compile
> pango-enum-types.c, MSVC complains because PANGO_OT_TABLE_GSUB and
> PANGO_OT_TABLE_GPOS are undeclared identifiers.
>
> I can fix that problem by modifying pango.h to add a #include for
> .  Pango itself then builds correctly.
>
> Unfortunately though... adding that extra #include then causes mayhem when
> building pangoft2.
>
> Should I just forget about pango-ot.h (i.e simply not reference it when
> I'm generating the enum-types in the first place?)  Everything seems to
> build fine if I just leave it out...
>
> Thanks, John
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [cairo] Color fonts

[Behdad Esfahbod]

07fd51fa11ad8 in gtk_container_propagate_draw (container=conta
> iner@entry=0x39ca18d030, child=0x39ca2b1860, cr=cr@entry=0x39ca4fc8b0)
> at gtkcontainer.c:3838
> #99 0x7fd51fa11bc2 in gtk_container_draw (widget=0x39ca18d030,
> cr=0x39ca4fc8b0) at gtkcontainer.c:3658
> #100 0x7fd51fc3b5b3 in gtk_window_draw (widget=0x39ca18d030,
> cr=0x39ca4fc8b0) at gtkwindow.c:10214
> #101 0x7fd51fc2d7cb in gtk_widget_draw_internal
> (widget=0x39ca18d030, cr=0x39ca4fc8b0, clip_to_size=) at
> gtkwidget.c:7017
> #102 0x7fd51fc36b38 in gtk_widget_render (widget=widget@entry=0x39c
> a18d030, window=0x39ca441320, region=) at
> gtkwidget.c:17512
> #103 0x7fd51fad7239 in gtk_main_do_event (event=) at
> gtkmain.c:1824
> #104 0x7fd51f5eb465 in _gdk_event_emit (event=event@entry=0x7ffc9f2
> 97450) at gdkevents.c:73
> #105 0x7fd51f5fb7a5 in _gdk_window_process_updates_recurse_helper
> (window=0x39ca441320, expose_region=) at
> gdkwindow.c:3849
> #106 0x7fd51f5fc9a6 in gdk_window_process_updates_internal
> (window=0x39ca441320) at gdkwindow.c:3995
> #107 0x7fd51f5fcba0 in gdk_window_process_updates_with_mode
> (window=, recurse_mode=) at
> gdkwindow.c:4189
> #108 0x7fd51db8d57d in g_closure_invoke () at /lib64/libgobject-
> 2.0.so.0
> #109 0x7fd51dba0e4e in signal_emit_unlocked_R () at
> /lib64/libgobject-2.0.so.0
> #110 0x7fd51dba9975 in g_signal_emit_valist () at
> /lib64/libgobject-2.0.so.0
> #111 0x7fd51dbaa2df in g_signal_emit () at /lib64/libgobject-
> 2.0.so.0
> #112 0x7fd51f5f428f in _gdk_frame_clock_emit_paint
> (frame_clock=) at gdkframeclock.c:640
> #113 0x7fd51f5f49c1 in gdk_frame_clock_paint_idle
> (data=0x39ca024270) at gdkframeclockidle.c:430
> #114 0x7fd51f5dfb20 in gdk_threads_dispatch (data=0x39ca169d60) at
> gdk.c:743
> #115 0x7fd51d8b3ffd in g_timeout_dispatch () at /lib64/libglib-
> 2.0.so.0
> #116 0x7fd51d8b3597 in g_main_context_dispatch () at
> /lib64/libglib-2.0.so.0
> #117 0x7fd51d8b3938 in g_main_context_iterate.isra () at
> /lib64/libglib-2.0.so.0
> #118 0x7fd51d8b39cc in g_main_context_iteration () at
> /lib64/libglib-2.0.so.0
> #119 0x7fd51e3ea89d in g_application_run () at /lib64/libgio-
> 2.0.so.0
> #120 0x0039c94fddda 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, <iofel...@gmail.com> wrote:
> > > Tried to run gnome-characters with Cairo master, switching to noto-
> > > color-emoji crashes with:
> > >
> > > #0  0x7fd0ecd2868b in raise () at /lib64/libc.so.6
> > > #1  0x7fd0ecd2a417 in abort () at /lib64/libc.so.6
> > > #2  0x7fd0ecd208fa in __assert_fail_base () at /lib64/libc.so.6
> > > #3  0x7fd0ecd20972 in  () at /lib64/libc.so.6
> > > #4  0x7fd0f1370b6e in _cairo_error (status=status@entry=3646361
> > > 312)
> > > at cairo-error.c:68
> > > #5  0x7fd0f1367802 in _cairo_set_error (cr=0x3dd89ecc00,
> > > status=3646361312) at cairo.c:400
> > > #6  0x7fd0f13691b1 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  0x7fd0f0283f69 in
> > > pango_cairo_renderer_show_text_glyphs.isra ()
> > > at /lib64/libpangocairo-1.0.so.0
> > > #8  0x7fd0f0284161 in pango_cairo_renderer_draw_glyph_item ()
> > > at
> > > /lib64/libpangocairo-1.0.so.0
> > > #9  0x7fd0f0057e1e in pango_renderer_draw_glyph_item () at
> > > /lib64/libpango-1.0.so.0
> > > #10 0x7fd0f00588b1 in pango_renderer_draw_layout_line () at
> > > /lib64/libpango-1.0.so.0
> > > #11 0x7fd0f0058c65 in pango_renderer_draw_layout () at
> > > /lib64/libpango-1.0.so.0
> > > #12 0x7fd0f028443a in _pango_cairo_do_layout () at
> > > /lib64/libpangocairo-1.0.so.0
> > > #13 0x7fd0ef560bde in ffi_call_unix64 () at /lib64/libffi.so.6
> > > #14 0x7fd0ef56054f in ffi_call () at /lib64/libffi.so.6
> > > #15 0x00007fd0f10ab6f6 in  () at /lib64/libgjs.so.0
> > > #16 0x7fd0f10ad066 in  () at /lib64/libgjs.so.0
> > > #17 0x7fd0ee3626a8 in js::Invoke(JSContext*, JS::CallArgs,
> > > js::MaybeConstruct) () at /lib64/libmozjs-38.so
> > > #18 0x7fd0ee3584cd in Interpret(JSContext*, js::RunState&) ()
> > > at
> > > /lib64/libmozjs-38.so
> > > #19 0x7fd0ee362324 in j

Re: [cairo] Color fonts

[Behdad Esfahbod]

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  0x7fd0ecd2868b in raise () at /lib64/libc.so.6
> #1  0x7fd0ecd2a417 in abort () at /lib64/libc.so.6
> #2  0x7fd0ecd208fa in __assert_fail_base () at /lib64/libc.so.6
> #3  0x7fd0ecd20972 in  () at /lib64/libc.so.6
> #4  0x7fd0f1370b6e in _cairo_error (status=status@entry=3646361312)
> at cairo-error.c:68
> #5  0x7fd0f1367802 in _cairo_set_error (cr=0x3dd89ecc00,
> status=3646361312) at cairo.c:400
> #6  0x7fd0f13691b1 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  0x7fd0f0283f69 in pango_cairo_renderer_show_text_glyphs.isra ()
> at /lib64/libpangocairo-1.0.so.0
> #8  0x7fd0f0284161 in pango_cairo_renderer_draw_glyph_item () at
> /lib64/libpangocairo-1.0.so.0
> #9  0x7fd0f0057e1e in pango_renderer_draw_glyph_item () at
> /lib64/libpango-1.0.so.0
> #10 0x7fd0f00588b1 in pango_renderer_draw_layout_line () at
> /lib64/libpango-1.0.so.0
> #11 0x7fd0f0058c65 in pango_renderer_draw_layout () at
> /lib64/libpango-1.0.so.0
> #12 0x7fd0f028443a in _pango_cairo_do_layout () at
> /lib64/libpangocairo-1.0.so.0
> #13 0x7fd0ef560bde in ffi_call_unix64 () at /lib64/libffi.so.6
> #14 0x7fd0ef56054f in ffi_call () at /lib64/libffi.so.6
> #15 0x7fd0f10ab6f6 in  () at /lib64/libgjs.so.0
> #16 0x7fd0f10ad066 in  () at /lib64/libgjs.so.0
> #17 0x7fd0ee3626a8 in js::Invoke(JSContext*, JS::CallArgs,
> js::MaybeConstruct) () at /lib64/libmozjs-38.so
> #18 0x7fd0ee3584cd in Interpret(JSContext*, js::RunState&) () at
> /lib64/libmozjs-38.so
> #19 0x7fd0ee362324 in js::RunScript(JSContext*, js::RunState&) ()
> at /lib64/libmozjs-38.so
> #20 0x7fd0ee362614 in js::Invoke(JSContext*, JS::CallArgs,
> js::MaybeConstruct) () at /lib64/libmozjs-38.so
> #21 0x7fd0ee664f13 in js_fun_apply(JSContext*, unsigned int,
> JS::Value*) () at /lib64/libmozjs-38.so
> #22 0x7fd0ee3626a8 in js::Invoke(JSContext*, JS::CallArgs,
> js::MaybeConstruct) () at /lib64/libmozjs-38.so
> #23 0x7fd0ee363243 in js::Invoke(JSContext*, JS::Value const&,
> JS::Value const&, unsigned int, JS::Value const*,
> JS::MutableHandle) () at /lib64/libmozjs-38.so
> #24 0x7fd0ee4b5485 in js::jit::DoCallFallback(JSContext*,
> js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int,
> JS::Value*, JS::MutableHandle) ()
> at /lib64/libmozjs-38.so
> #25 0x7fd0f1877510 in  ()
> #26 0x7fffada948a0 in  ()
> #27 0x7fffada94368 in  ()
> #28 0x 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 desirabl

Re: [cairo] Color fonts

[Behdad Esfahbod]

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 <beh...@behdad.org>
> 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 <psyc...@znc.in>
> wrote:
> >>>>>> On 30.06.2017 17:29, Behdad Esfahbod wrote:
> >>>>>>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@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.
>



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Behdad Esfahbod]

On Fri, Jul 28, 2017 at 6:00 PM, Bill Spitzak <spit...@gmail.com> 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 <beh...@behdad.org>
> 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 <beh...@behdad.org>
> 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 <psyc...@znc.in>
> wrote:
> >>>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
> >>>> >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@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/
> >
> >
> >
> >
> > --
> > behdad
> > http://behdad.org/
> >
> > --
> > cairo mailing list
> > ca...@cairographics.org
> > https://lists.cairographics.org/mailman/listinfo/cairo
>



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Behdad Esfahbod]

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 <beh...@behdad.org> 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 <psyc...@znc.in> wrote:
>>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>>> >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@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/
>



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Synthesizing fonts using Cairo/Pango

[Behdad Esfahbod]

On Wed, Jul 19, 2017 at 2:13 AM, Carl Hetherington <li...@carlh.net> wrote:

> Hi Behdad,
>
> [snip]
>
> > Try calling FcInitLoadConfigAndFonts first for example...
>
> Many, many thanks: using FcInitLoadConfig() instead of FcConfigCreate()
> appears to have fixed it!
>

See!  You didn't include the FcConfigCreate() in your snippet; that's why I
found it strange ;).


> All the best,
> Carl
>
>
> >
> >   Thank you,
> >   Carl
> >
> >   On Tue, 18 Jul 2017, Behdad Esfahbod wrote:
> >
> >   > pangocairo is supposed to do that automatically.  Is this on
> Windows / Mac by any chance?
> >   >
> >   > On Mon, Jul 17, 2017 at 3:46 PM, Carl Hetherington <
> li...@carlh.net> wrote:
> >   >   Hi all,
> >   >
> >   >   I am writing text to a Cairo RGB24 ImageSurface using code
> along the lines
> >   >   of
> >   >
> >   >   FcConfigAppFontAddFile (..., "Arial.ttf");
> >   >
> >   >   auto surface = Cairo::ImageSurface::create (...);
> >   >   auto context = Cairo::Context::create (surface);
> >   >   auto layout = Pango::Layout::create (context);
> >   >   Pango::FontDescription font ("Arial");
> >   >   layout->set_font_description (font);
> >   >   layout->set_markup ("Hello
> world");
> >   >   layout->add_to_cairo_context (context);
> >   >
> >   >   Is there any way I can get Pango/Cairo/whoever to
> synthesize italic/bold
> >   >   fonts for me if I only supply a "regular" font file?
> >   >
> >   >   As a complete punt I tried:
> >   >
> >   >   auto ff = context->get_font_face();
> >   >   cairo_ft_font_face_set_synthesize (ff->cobj(),
> CAIRO_FT_SYNTHESIZE_OBLIQUE | CAIRO_FT_SYNTHESIZE_BOLD);
> >   >
> >   >   but no joy.  Any tips?
> >   >
> >   >   Thanks very much,
> >   >   Carl
> >   >   ___
> >   >   gtk-i18n-list mailing list
> >   >   gtk-i18n-list@gnome.org
> >   >   https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
> >   >
> >   >
> >   >
> >   >
> >   > --
> >   > behdad
> >   > http://behdad.org/
> >   >
> >   >
> >
> > ___
> > gtk-i18n-list mailing list
> > gtk-i18n-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
> >
> >
> >
> >
> > --
> > behdad
> > http://behdad.org/
> >
> >
>
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [cairo] Color fonts

[Behdad Esfahbod]

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 <psyc...@znc.in> wrote:
>> >> On 30.06.2017 17:29, Behdad Esfahbod wrote:
>> >>> On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@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/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Synthesizing fonts using Cairo/Pango

[Behdad Esfahbod]

On Tue, Jul 18, 2017 at 1:32 AM, Carl Hetherington <li...@carlh.net> wrote:

> Hi Behdad,
>
> This is on Ubuntu 16.04.  It works fine if I remove the
> FcConfigAppFontAddFile.


Humm . I wouldn't have expected that.



>   I'm happy to build Pango/Cairo from source and
> do any debugging that would help.
>

Read this and see if anything strikes out:

  http://mces.blogspot.ca/2015/05/how-to-use-custom-application-fonts.html

Try calling FcInitLoadConfigAndFonts first for example...


> Thank you,
> Carl
>
> On Tue, 18 Jul 2017, Behdad Esfahbod wrote:
>
> > pangocairo is supposed to do that automatically.  Is this on Windows /
> Mac by any chance?
> >
> > On Mon, Jul 17, 2017 at 3:46 PM, Carl Hetherington <li...@carlh.net>
> wrote:
> >   Hi all,
> >
> >   I am writing text to a Cairo RGB24 ImageSurface using code along
> the lines
> >   of
> >
> >   FcConfigAppFontAddFile (..., "Arial.ttf");
> >
> >   auto surface = Cairo::ImageSurface::create (...);
> >   auto context = Cairo::Context::create (surface);
> >   auto layout = Pango::Layout::create (context);
> >   Pango::FontDescription font ("Arial");
> >   layout->set_font_description (font);
> >   layout->set_markup ("Hello world");
> >   layout->add_to_cairo_context (context);
> >
> >   Is there any way I can get Pango/Cairo/whoever to synthesize
> italic/bold
> >   fonts for me if I only supply a "regular" font file?
> >
> >   As a complete punt I tried:
> >
> >   auto ff = context->get_font_face();
> >   cairo_ft_font_face_set_synthesize (ff->cobj(),
> CAIRO_FT_SYNTHESIZE_OBLIQUE | CAIRO_FT_SYNTHESIZE_BOLD);
> >
> >   but no joy.  Any tips?
> >
> >   Thanks very much,
> >   Carl
> >   ___
> >   gtk-i18n-list mailing list
> >   gtk-i18n-list@gnome.org
> >   https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
> >
> >
> >
> >
> > --
> > behdad
> > http://behdad.org/
> >
> >
>
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Font size wrong on MacOS Retina display

[Behdad Esfahbod]

Will do.  Was on vacation for several weeks... :D

On Tue, Jun 20, 2017 at 10:17 PM, John Ralls <jra...@ceridwen.fremont.ca.us>
wrote:

>
> > On May 22, 2017, at 3:48 PM, Behdad Esfahbod <beh...@behdad.org> wrote:
> >
> > On Mon, May 22, 2017 at 8:24 AM, John Ralls <
> jra...@ceridwen.fremont.ca.us> wrote:
> > Behdad,
> >
> > Could you find a few minutes to review https://bugzilla.gnome.org/
> attachment.cgi?id=351992 on https://bugzilla.gnome.org/
> show_bug.cgi?id=782393?
> >
> > Brings back memories
> >
> > Done:
> > https://bugzilla.gnome.org/review?bug=782393=351992
> >
>
> Bedhad,
>
> My updated patch has been waiting for you... can you find time for another
> look?
>
> Regards,
> John Ralls
>
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [cairo] Color fonts

[Behdad Esfahbod]

On Fri, Jul 7, 2017 at 5:53 PM, Matthias Clasen 
wrote:

> On Sat, Jul 1, 2017 at 2:25 AM, Uli Schlachter  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.

-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Behdad Esfahbod]

On Fri, Jul 7, 2017 at 5:55 PM, Matthias Clasen 
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.
>



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [cairo] Color fonts

[Behdad Esfahbod]

On Jun 30, 2017 7:51 PM, "Matthias Clasen" <mcla...@redhat.com> 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
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Color fonts

[Behdad Esfahbod]

Hello,

All of you have asked me about the status of color fonts in cairo.  There's
some discussion here:

https://github.com/googlei18n/noto-emoji/issues/36

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,
-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Pango pipe stdin and stdout

[Behdad Esfahbod]

Looks like I did all of those in hb-view, but not pango-view... So, no,
it's not currently possible.  Try paps indeed.

On Sat, Jun 3, 2017 at 6:43 AM, Adam Dyson  wrote:

> I’d like to know whether it’s possible to render text using Pango, by
> piping text as input to stdin and then also piping the result to stdout?
>
> Ideally I’m wanting something like below, where an argument such as intent
> defines the output type, because this is normally determined by the output
> file extension.
>
> Outputting to stdout is defined by a dash and so is reading from stdin,
> which is common practice for command line utilities.
>
>
>
> pango-view –q --markup --align=left --margin=0 –intent=svg --output=- -
>
>
>
>
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Font size wrong on MacOS Retina display

[Behdad Esfahbod]

On Mon, May 22, 2017 at 8:24 AM, John Ralls 
wrote:

> Behdad,
>
> Could you find a few minutes to review https://bugzilla.gnome.
> org/attachment.cgi?id=351992 on https://bugzilla.gnome.org/
> show_bug.cgi?id=782393?
>

Brings back memories

Done:
https://bugzilla.gnome.org/review?bug=782393=351992



> Regards,
> John Ralls
>
>
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango: Issues with illegal characters in family names (encoding problems on Windows?)

[Behdad Esfahbod]

On Mon, May 22, 2017 at 3:13 PM, Eduard Braun <eduard.bra...@gmx.de> wrote:

> Am 22.05.2017 um 23:36 schrieb Behdad Esfahbod:
>
> Can you point me to the crash stacktrace?  I couldn't find it browsing
> your links casually.
>
>
> https://bugs.launchpad.net/inkscape/+bug/1495386/+
> attachment/4881592/+files/bt.txt
>

That's not very helpful as it doesn't show which function in glib is
crashing:

#1  0x686238e9 in ?? ()
   from E:\Temp\Inkscape\inkscape\trunk_msys2\build64\inkscape\libglib-2.0-0.dll
#2  0x01dc05ac in
Inkscape::FontLister::new_font_family(Glib::ustring, bool) ()

Someone who can reproduce the issue needs to debug it and report what
exactly is happening before I can recommend anything.  To me, inkscape
shouldn't need to do anything on the family name that would require it
to be valid.  But I'm sure I'm wrong.  I just don't know how.


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango: Issues with illegal characters in family names (encoding problems on Windows?)

[Behdad Esfahbod]

On Sun, May 21, 2017 at 4:02 PM, Eduard Braun <eduard.bra...@gmx.de> wrote:

Am 18.05.2017 um 21:39 schrieb Behdad Esfahbod:
>
> At any rate, I guess the right question you should be asking is, why is
>> Inkscape crashing, and fix that.  Pango, etc, handle invalid UTF-8 just
>> fine for example.
>>
> Well, Inkscape isn't crashing anymore (as I took the radical approach of
> axing any font with illegal UTF8 characters in family name). The crashing
> is not too surprising as Inkscape (especially GTK+ and glib at that)
> usually expect UTF-8 strings to be valid,


Can you point me to the crash stacktrace?  I couldn't find it browsing your
links casually.


> and I think that is a good assumption:


Not necessarily.  I'm of the opinion that our libraries should not crash on
invalid input to the extent possible.



> If a font name includes an invalid UTF-8 character something went wrong at
> some point and I doubt it makes much sense to work around that in Inkscape.
> As it's not a common bug and you both seem positive this is not an issue in
> any of the involved libraries (Windows is often "complicated" when it gets
> to character set conversion, so there are often issues not exposed on *nix)
> I guess there's not much I can (or want) to do about it at this time...
>
>
> Am 20.05.2017 um 08:10 schrieb Werner LEMBERG:
>
>> The one in [5] is a Windows .fon font.  It's possible that there's a
>>> bug in FreeType driver for that format.
>>>
>> As far as I can see, there is no FreeType bug.  According to the FNT
>> specification[1], the family name must be ASCII, which is not true for
>> this font.
>>
> That's useful information! In that case I'd say this can safely be judged
> as a "bug" in the font. While I guess it could be worked around, as already
> stated above I don't think it's the job of any software to work around the
> issues arising from fonts that do not follow the respective format's
> specification.
>
> Best Regards,
> Eduard
>
>


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango: Issues with illegal characters in family names (encoding problems on Windows?)

[Behdad Esfahbod]

Hi Eduard,

It's possible that there are bugs on the fonts.  For the ttf in [6] I
cannot spot any from the output of fc-query.  The one in [5] is a Windows
.fon font.  It's possible that there's a bug in FreeType driver for that
format.

At any rate, I guess the right question you should be asking is, why is
Inkscape crashing, and fix that.  Pango, etc, handle invalid UTF-8 just
fine for example.

b

On Fri, May 12, 2017 at 11:44 AM, Eduard Braun  wrote:

> Hi all,
>
> I'm a developer in the Inkscape project which uses Pango/Fontconfig to
> render (and also query) available fonts on the system.
>
> In the past there were multiple bug reports [2,3] about Inkscape crashing
> due to fonts with illegal characters in their family name (Inkscape queries
> them with "pango_ft2_font_map_new()" and "pango_font_map_list_families()"
> respectively and gets the name with "pango_font_family_get_name()", see
> [3] for details).
>
> I recently pushed a fix [4] which seems to avoid the crashes and proves,
> that they are caused by font family names containing illegal UTF-8
> characters!
>
> The question I'm asking myself is, whether
> a) the font files themselves are invalid and contain characters in some
> broken encoding
> b) fontconfig has issues querying fonts with special characters on
> Windows, or
> c) Pango does something wrong when passing the list to Inkscape
>
> As I have not nearly enough knowledge about Pango/Fontconfig (or font
> formats to start with) I hope that somebody is able to figure out what is
> going wrong and if it can be fixed somehow!
>
> As a start you can find two fonts that caused crashes in the past at [5]
> and [6] and according to user reports the fix in [4] prevents them both
> (while obviously making it impossible to use the font).
>
> Best Regards,
> Eduard Braun
>
>
> [1]https://bugs.launchpad.net/inkscape/+bug/1495386
> [2]https://bugs.launchpad.net/inkscape/+bug/1508928
> [3] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/vie
> w/head:/src/libnrtype/FontFactory.cpp
> [4] http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/rev
> ision/15687
> [5] https://bugs.launchpad.net/inkscape/+bug/1495386/+attachment
> /4875733/+files/AESYSMAT.zip
> [6] https://bugs.launchpad.net/inkscape/+bug/1508928/+attachment
> /4502390/+files/%E9%87%91%E6%A2%85%E6%AF%9B%E8%A1%8C%E6%9B%B8.ttf
>
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>



-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Embedding icons in Pango text, the "right" way?

[Behdad Esfahbod]

See:
https://github.com/GNOME/pango/blob/master/examples/cairoshape.c

On Aug 11, 2016 8:04 AM, "Andy Meneely"  wrote:

> Hi,
>   I maintain a Ruby gem that uses Pango heavily (
> https://github.com/andymeneely/squib/). One of the key features is to be
> able to draw an icon into the text such that it flows just like any other
> word. Carving out the space in the Pango layout has proven to be a
> finicky challenge. (Once we carve out the proper space in the layout, we
> use Cairo to paint the image separately.)
>
> What is the proper way to carve out space for image? We need this space to
> flow like any other word.
>
> The way we currently carve out space is a bit hacky (
> https://github.com/andymeneely/squib/blob/master/lib/squib/
> graphics/text.rb#L98). We (1) replace the key with a control character,
> then (2) change the letter spacing of the middle character to the width we
> need. This fails on some platforms and not others.
>
> If we created a zero-sized regular character (e.g "a"), then stroking path
> will fail because a zero-sized font invalidates the matrix math. Plus, we
> get strange behavior happening when the text is ONLY an embedded icon of a
> zero-sized font (i.e. we get a warning that the font can't be found).
>
> So I've never been happy with the way we implement this and I'm convinced
> Pango provides a better way. I see the AttrShape struct - should I be
> using that? How do I set attributes for just one character? I've been
> scouring the docs and mailing lists archives and I'm not grasping exactly
> how attribute lists work, so that's why I went with markup.
>
> If you have solutions in just C, or in another scripting language, I can
> port it.
>
> Thanks!
>
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>
>
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Gtk+4.0

[Behdad Esfahbod]

On Mon, Jul 11, 2016 at 1:47 PM, Paul Davis <p...@linuxaudiosystems.com> wrote:
> If soname was changed in keeping with the nominal "standard", it wouldn't be
> that much of an issue. The soname would indicated added API, internal fixes,
> and no change to public API/ABI. No?

Humm.  I don't quite follow.  Common practice for "added API, internal fixes,
> and no change to public API/ABI" is to keep the soname.

> On Mon, Jul 11, 2016 at 4:29 PM, Behdad Esfahbod <beh...@behdad.org> wrote:
>>
>> I also think bumping soname every six months would be disaster.  It
>> was painful enough when libstdc++, libpng, libssl, etc changed soname
>> every few years.
>>
>> On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
>> <poch...@gmail.com> wrote:
>> > Hi,
>> >
>> > On 21/06/16 16:26, Peter Weber wrote:
>> >> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying
>> >> to
>> >> write about my thoughts, in a careful way. In the first moment, I
>> >> thought
>> >> this is a good idea and just the numbering is misleading. Stability is
>> >> what
>> >> developers want, we need it, we love it. With a few days distance,
>> >> numbering is just a small issue, I see this now entirely different and
>> >> three major issues:
>> >
>> > Here are some thoughts I have about all this, from a downstream
>> > maintainer POV.
>> >
>> > My concern with this new scheme is that GTK+ libraries will have to bump
>> > the
>> > soname every 6 months (if they want to support the latest GTK+). That
>> > can be
>> > manageable for say vte or gnome-desktop, although it may be bad if some
>> > third
>> > party apps pick a dependency on the vte for GTK+ 4.2 but don't update it
>> > for
>> > GTK+ 4.4, as then distros would need to ship an increasing number of
>> > versions
>> > that are unlikely to get any support upstream.
>> >
>> > But do you expect WebKitGTK+ to bump the ABI every 6 months?
>> >
>> > I feel like the X.[024] releases are just snapshots of a development
>> > branch,
>> > with X.6 being the stable release, and I wonder if X.[024] shouldn't
>> > clearly be
>> > labelled as that, regardless of what version number is chosen (be it
>> > 4.0,
>> > 3.99.0, 4.0beta1 or whatever).
>> >
>> > Cheers,
>> > Emilio
>> > ___
>> > 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
>
>



-- 
behdad
http://behdad.org/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Behdad Esfahbod]

I also think bumping soname every six months would be disaster.  It
was painful enough when libstdc++, libpng, libssl, etc changed soname
every few years.

On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
 wrote:
> Hi,
>
> On 21/06/16 16:26, Peter Weber wrote:
>> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
>> write about my thoughts, in a careful way. In the first moment, I thought
>> this is a good idea and just the numbering is misleading. Stability is what
>> developers want, we need it, we love it. With a few days distance,
>> numbering is just a small issue, I see this now entirely different and
>> three major issues:
>
> Here are some thoughts I have about all this, from a downstream maintainer 
> POV.
>
> My concern with this new scheme is that GTK+ libraries will have to bump the
> soname every 6 months (if they want to support the latest GTK+). That can be
> manageable for say vte or gnome-desktop, although it may be bad if some third
> party apps pick a dependency on the vte for GTK+ 4.2 but don't update it for
> GTK+ 4.4, as then distros would need to ship an increasing number of versions
> that are unlikely to get any support upstream.
>
> But do you expect WebKitGTK+ to bump the ABI every 6 months?
>
> I feel like the X.[024] releases are just snapshots of a development branch,
> with X.6 being the stable release, and I wonder if X.[024] shouldn't clearly 
> be
> labelled as that, regardless of what version number is chosen (be it 4.0,
> 3.99.0, 4.0beta1 or whatever).
>
> Cheers,
> Emilio
> ___
> 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

Re: G_UTF8String: Boxed Type Proposal

[Behdad Esfahbod]

On Mon, Mar 21, 2016 at 3:30 PM, Randall Sawyer 
wrote:

> Frankly, the use of the term "character" when referring to a "UTF-8
> encoded Unicode code point" was for me a source of confusion


A character means a "Unicode character".  That's independent of encoding,
so, no, it does NOT mean "UTF-8 encoded Unicode code point".


> when I leapt to the conclusion of the unmet need of a UTF-8-length-aware
> wrapped string type - be it called "G_UTF8String" or "GUString".
>
> I recommend that all Glib documentation be rewritten such that throughout
> all descriptions of g_utf8_*() functions, the parlance "character" be
> replaced with "UTF-8 code point sequence" or equivalent terminology.
>
> Thank you.
>
>
>
> ___
> 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

Re: G_UTF8String: Boxed Type Proposal

[Behdad Esfahbod]

I like to voice my opinion as well:

  - Bundling data and its length in a boxed type is useful, but that's
gblob,

  - Bundling number-of-Unicode-character is rarely useful indeed,

  - A string API that would require any changes to the string content to go
through editing function calls is painful and will remain unused,

I also have a piece of a more personal opinion:  Many processes that simply
*reject* invalid Unicode text are useless in many situations.  For example,
gedit used to refuse to open a file if it had even a single
invalidly-encoded byte.  I find that annoyingly limited.  Same thing about
Pango.  Fortunately, both have been fixed for many years now.


behdad

On Mon, Mar 21, 2016 at 6:32 AM, Matthias Clasen 
wrote:

> On Fri, Mar 18, 2016 at 9:57 AM, Randall Sawyer
>  wrote:
>
>
> > 2) If the former is true - which it is - then the developer will need to
> > call g_utf8_strlen() to determine if there are multi-byte sequences to
> > navigate - and if there are - g_utf8_offset_to_pointer() to locate the
> array
> > index. Doesn't this increase processing demand?
>
> It does. But whether that is a problem (in general, or for your
> particular use case) can only be answered by  profiling. My theory is
> that you won't be able to notice this on the profile at all, unless
> all your application does is constantly operating on large amounts of
> text. In which case, you really shouldn't be using GString to begin
> with...
>
> > 3) Wouldn't it be helpful to keep track of how many code points
> > ("characters")are stored in the GString - a number which may be less than
> > the value of GString.len - without needing to call g_utf8_strlen() each
> time
> > to find out?
> > 4) Would my efforts be better spent editing patches of "gstring.h" and
> > "gstring.c" - or - to proceed as I am to introduce a parallel
> alternative?
>
> I think we haven't gotten past the 'what is the problem you are trying
> to solve - and is it a problem in the first place ?' part yet.
> ___
> 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

Re: GTK+ hackfest 2016

[Behdad Esfahbod]

Hi Matthias,

Any idea why the page says Immutable to me?

  https://wiki.gnome.org/Hackfests/GTK2016

I remember having seen this before but don't remember what the resolution
was.

Cheers,
behdad

On Tue, Mar 8, 2016 at 5:02 AM, Matthias Clasen 
wrote:

> Hi,
>
> we've discussed the idea of doing a GTK+ hackfest this year. I've
> started a wiki page with the current plan:
>
> https://wiki.gnome.org/Hackfests/GTK2016
>
> If you are interested in attending, please add your name to the list.
> If you want to see topics added to the agenda, please suggest them on
> this page, too.
>
> Hope to see some of you in Toronto!
>
> Matthias
> ___
> 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

Re: Error due to #including FT_ERRORS_H

[Behdad Esfahbod]

Thanks John. That is indeed a FreeType issue.  I replied to your post on the
FreeType mailing list.

On 16-01-20 02:16 PM, John Emmas wrote:
> Is this the right list for reporting pango development issues? Assuming it 
> is...
> 
> I updated freetype2 a few days ago (i.e. I pulled the latest source code from
> git) and I've just realised that pango fails to build now (with MSVC).  The
> problem is at these lines, round about line 540 of 'pango/pangoft2.c':-
> 
>   static const ft_error_description ft_errors[] =
> #include FT_ERRORS_H
> 
> #undef FT_ERRORDEF
> #undef FT_ERROR_START_LIST
> #undef FT_ERROR_END_LIST
> 
>   ft_error_description *found = /* <-- ERROR HERE !!! */
> bsearch (, ft_errors, G_N_ELEMENTS (ft_errors),
>  sizeof (ft_errors[0]), ft_error_compare);
> 
> MSVC gives me:-  'error C2275: 'ft_error_description' : illegal use of this
> type as an expression'.  To be honest, I suspect that the actual error might
> be a few lines earlier - i.e.
> 
>   static const ft_error_description ft_errors[] =
> #include FT_ERRORS_H
> 
> My best guess is that something got changed somewhere in
> 'freetype/fterrors.h'.  It does look like something got done (about a week
> ago) to remove underscores from some macro names but I'm not sure why that
> would cause this problem.  Can anyone hazard a guess at what might be wrong? 
> Thanks,
> 
> John
> ___
> gtk-i18n-list mailing list
> gtk-i18n-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
> 
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Unicode normalization and text display differences

[Behdad Esfahbod]

On 16-01-06 03:07 PM, Benjamin Kiessling wrote:
> On 01/06, Behdad Esfahbod wrote:
>> On 16-01-06 02:55 PM, Benjamin Kiessling wrote:
>>> On 01/06, Behdad Esfahbod wrote:
>>>> Hi Ben,
>>>>
>>>> You at least need to tell us on what platform you are testing this and with
>>>> what fonts.
>>>
>>> Sorry, I'm running on Debian testing (libpango-1.0 package version
>>> 1.36.8-3) and using it through GObject introspection from python
>>> (although that's probably not the issue here). Apart from setting up the
>>> whole CairoSurface and Layout shebang the code boils down to
>>> set_font_description/set_text/show_layout.
>>>
>>> The font family used is GFS Philostratos, although the issue persists
>>> only with GFS fonts as I'm realizing just now. Using DejaVu Sans output
>>> is independent of normalization form. Is this to be expected? The
>>> documentation is mute about such points (and in general about how it's
>>> supposed to be used).
>>
>> It's probably the case that the GFS fonts don't support the combining marks,
>> and as such Pango picks them from a different font, which then breaks 
>> shaping.
> 
> Makes sense. Is there a way to detect fallback, except disabling it
> completely using pango_attr_fallback_new() or instantiating a new
> fontconfig environment for a particular font?

If you care to walk the layout info using a layout iterator, you can check the
font used for each run of text, and under fallback, more than one font is used.
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango and Android

[Behdad Esfahbod]

On 15-12-18 11:39 PM, Pere Pujal i Carabantes wrote:
> Hi Behdad, Thanks for replying
> 
> El dv 18 de 12 de 2015 a les 16:34 +0000, en/na Behdad Esfahbod va
> escriure:
>> On 15-12-15 10:44 PM, Pere Pujal i Carabantes wrote:
>>> Any hints to debug this?
>>
>> Humm.  Not really.
>>
>> When you say "messed up", care to explain how?
> 
> I think better attach a screenshot, note that it is scaled by SDL then
> zoomed by Android accessibility, the text inside the buttons should be
> Pinta Estampa-> Paint Stamp
> Línies Formes-> Lines Shapes

Humm; hard to tell what's going on.

> I've noticed that when applying the workaround mentioned in the
> previous mail, then the font used to render the text changes from what
> looks like a sans font to a serif one.

Is it possible that the SDL layer assumes that the text is all shaped using
the same (primary) font?  That's obviously not how Pango works...

b
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango and Android

[Behdad Esfahbod]

On 15-12-15 10:44 PM, Pere Pujal i Carabantes wrote:
> Any hints to debug this?

Humm.  Not really.

When you say "messed up", care to explain how?

behdad
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango modules Hebrew heurisics

[Behdad Esfahbod]

Hi Dov,

Yes, I removed those.  There *is* fallback positioning in HarfBuzz for fonts
that don't have GPOS, so theoretically you can contribute improvements to
that.  But I'd really be cautious about taking any changes in this day and 
age...

Here's the code:

https://github.com/behdad/harfbuzz/blob/master/src/hb-ot-shape-fallback.cc

b

On 15-08-29 09:34 PM, Dov Grobgeld wrote:
 While playing around with pango rendering did I notice a regression in the
 placement of Hebrew diacritics marks for fonts that lack a GPOS table. In my
 old Hebrew pango module, I had added some heuristics for how to do such
 placement, and the result was quite acceptable for most fonts. From what I
 understand from the logs the language specific modules were discarded when
 Harfbuzz was introduced as a pango dependency (in 2012), and with it my 
 placement heuristics.
 
 The question is if this was intentional, and whether you consider this is a
 font problem and not something that the pango should deal with?
 
 Regards,
 Dov
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Font settings via XSETTINGS vs fontconfig

[Behdad Esfahbod]

Benjamin,

At the typography BoF at GUADEC you asked why the GNOME font settings where
routed through XSETTINGS and not by writing to an XML fontconfig config file.
I said there's probably no reason for that and that's just the way Owen or
whoever did the work did it.

But then I thought about it more and I'm confident that it's because up until
about 2007 / 2008 we didn't have file monitoring in glib, and as such Gtk+
couldn't pickup fontconfig changes (including config changes) on the fly.  So
apps had to be restarted for font settings to take effect, which is a
non-starter.  Thought, it's still possible to write a config file, send a
XSETTINGS signal, then on the client side reload fontconfig config, which is
actually how we do it now, but gnome-settings-daemon detects config changes,
so there's no need for a tweak tool to send any signal, it can just write a
config file and it will be picked up in a second or two...


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: New version of paps with cairo backend

[Behdad Esfahbod]

Thanks Dov!

How is this different from pango-view?  Does it support pagination?

Cheers,

b

On 15-08-18 06:55 AM, Dov Grobgeld wrote:
 After more than a decade I have finally converted my text to postscript
 converter paps, to use cairo for its postscript rendering. In addition I have
 added a pdf and svg output option.
 
 Please check out the new version and let me know of any problems. The new
 version is available at:
 
 http://github.com/dov/paps
 
 Regards,
 Dov
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Alpha in Pango Color

[Behdad Esfahbod]

Hi William,

Currently Pango doesn't support alpha in colors.  At this point, it might make
sense to add a separate PANGO_ATTR_ALPHA, instead of an RGBA type.

I'd take a patch.  Matthias, is this something you can possibly implement?
Shouldn't take long to implement and test...

b

On 15-08-08 01:10 AM, William Kappler wrote:
 Hello,
 
 I am seeking a way to encode the alpha channel of color into text, so that it
 can vary within a Pango layout like color. As far as I can tell, this is not
 supported directly by Pango. If I set an alpha via *cairo_set_source_rgba()*
 there is no way to later change it: the markup only offers 3-component hex
 colors.
 
 I took a brief look at the source and it seems a non-trivial matter to add
 such functionality. I was unable to trace down where exactly the color
 attribute ends up affecting the text color. As I said, though, this was a
 brief look.
 
 Ideally, *foreground* and *background* would take both three-component and
 four-component colors (#NN or #), but an additional alpha tag
 would be an option as well.
 
 I ask because I am currently attempting to apply Pango-Cairo as the text
 rendering engine in an open source game engine I am working on. I figure alpha
 has little impact on most of Pango's applications - but in the context of 3D,
 it is quite important.
 
 Does anyone have any thoughts or advice on this topic? I would be willing to
 write a patch to this effect if that is of interest.
 
 :-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
 William E. Kappler II
 LinkedIn https://www.linkedin.com/in/williamkappler · Blog
 http://williamkappler.blogspot.com/ · Project Website
 https://github.com/WilliamKappler/onathacar/wiki
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Width for bounding box of highly tilted characters

[Behdad Esfahbod]

On 15-05-20 11:38 AM, mathog wrote:
 how does one retrieve from Pango the width (bounding box xmax - xmin) of the
 glyph?

pango_font_get_glyph_extents()
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [Fontconfig] Application fonts with Pango+fontconfig

[Behdad Esfahbod]

On 15-05-13 06:17 AM, Khaled Hosny wrote:
 On Tue, May 12, 2015 at 03:34:59PM -0700, Behdad Esfahbod wrote:
 On 15-05-10 12:10 PM, Khaled Hosny wrote:

 This seems to be a general Pango issue, if I modify a font while
 an application is using it, I get similar issues. 

 This sounds like caching inside cairo messing things up.  I'll think about 
 it.
  Not sure how to best address it...
 
 What is cached by cairo and how is that different from drawing the glyph
 on cairo directly rather than through pango-cairo?

In your old code you create FT_Face and pass it to cairo.  pangocairo however,
passes a FcPattern to cairo and let cairo create the FT_Face.  Cairo caches
FT_Face based on filename and face index, which obviously is broken here...

I have other issues with the cairo FT_Face handling to fix.  I might end up
considerably revamp cairo-ft internals (very tricky and time-consuming), or in
the mean time fix pangocairo to create its own FT_Face and pass to cairo.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [Fontconfig] Application fonts with Pango+fontconfig

[Behdad Esfahbod]

On 15-05-10 12:10 PM, Khaled Hosny wrote:
 On Fri, May 01, 2015 at 07:19:11PM -0400, Behdad Esfahbod wrote:
 Hi all,

 I am at the Libre Graphics Meeting in Toronto this week, which meant that I
 got to talk to GIMP and Inkscape developers after many years, and was 
 reminded
 that Pango still doesn't make it easy to use custom (aka application fonts),
 and it still does not allow one to turn OpenType features on or off.  So I
 ended up doing a complete review of the stack, fixed small stuff, filed many
 bugs, and documented it all.  Details here:

 http://mces.blogspot.ca/2015/05/how-to-use-custom-application-fonts.html

 Hopefully we can make the next release of the stack much better, and work 
 with
 app developers to integrate these.
 
 I gave it a try[1] and it seems to work for my use case (I don’t even
 need to select a Pango font, since might is the only one Pango seems to
 just pick it), with one glitch: If the font gets changed while the
 viewer is open (e.g. adding or removing glyphs), Pango will start
 drawing garbage glyphs (seems to be using the old glyph indices) even
 though I recreate the config, fontmap, layout and everything. This is
 specially important for this application as I use it to test fonts while
 I’m working on them, not sure if it is that relevant for common use
 cases.

That's so weird.  How do you test this?

I just ran it, and if I copy a new font on top of the filename, the app
instantly picks it up (I'm not sure how!), but there doesn't seem to any issue
with glyph numbers.  I tested copying NotoNastaliq and IranNastaliq on top of
each other and it works just fine.

 
 This seems to be a general Pango issue, if I modify a font while
 an application is using it, I get similar issues. 
 
 Regards,
 Khaled
 
 1. https://github.com/khaledhosny/fontview/commit/0353750
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Module-less pango vs pangox-compat

[Behdad Esfahbod]

On 15-04-27 01:01 PM, Matthias Clasen wrote:
 On Fri, 2015-04-24 at 14:31 -0700, Behdad Esfahbod wrote:
 Hi Matthias,

 Just a quick note that with the module-less pango, the pangox-compat 
 lib won't
 work anymore.  Not that *anyone* cares...

 
 Thanks for the update. I do have customers who care about pangox
 -compat, but it'll be a while before module-less pango hits RHEL.

Ok.  I actually went ahead and pushed an update to pangox-compat that might
make it work:


https://git.gnome.org/browse/pangox-compat/commit/?id=edb9e0904d04d1da02bba7b78601a2aba05aaa47

If you have a way to test pangox-compat, please test, and feel free to make a
release.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Module-less pango vs pangox-compat

[Behdad Esfahbod]

On 15-04-24 04:01 PM, Alexandre Rostovtsev wrote:
 On Fri, 2015-04-24 at 14:31 -0700, Behdad Esfahbod wrote:
 Hi Matthias,
 
 Just a quick note that with the module-less pango, the pangox-compat
 lib won't work anymore.  Not that *anyone* cares...
 
 Some distros care. In Gentoo, I see seven remaining packages that have a 
 direct dependency on pangox-compat:
 
 * acroread (for opening some pdf files with filled-in forms) * atokx3 *
 gtkglext * gtkmathview * proprietary nvidia-drivers (legacy versions,
 needed for Geforce 9 and older gpus) * sawfish * vmware-workstation
 
 Of course, anything that depends on gtkglext or gtkmathview then also 
 pulls in pangox-compat into its depgraph.

That was exactly the case in August 2012, when I developed the pangox-compat
package.  The fact that those packages link to it doesn't mean that they
actually use it.  The package continues to build and link, it just won't
perform any text rendering.  If anyone is actually relying on it rendering
text, then they'll be disappointed.

I suggest you ignore this and let the bug report(no s) come in eventually.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Module-less pango vs pangox-compat

[Behdad Esfahbod]

Hi Matthias,

Just a quick note that with the module-less pango, the pangox-compat lib won't
work anymore.  Not that *anyone* cares...

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango indent marks

[Behdad Esfahbod]

On 15-02-13 10:13 AM, Detlef Reichl wrote:
 Hi,
 
 I already send the following to gtk+ list, but it seems that no one
 there was able to help. So I hope that I have more luck here :-)
 
 
 Is Pango able to render indent marks like dots for spaces and arrows for
 tabs? I found nothing like this in the docs. If not, what is the best
 way to do it my self? Is the only way, to render it with cairo on my own?

I believe so.  There are examples in the gedit plugins that do that.

 Cheers, detlef
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Glyph width vs advance width

[Behdad Esfahbod]

Also, 'f' in many italic fonts for example.  Many glyphs in most script-style
fonts.

On 15-02-25 06:45 AM, Dave Crossland wrote:
 hi
 
 the w can often be a little wider in glyph width than advance width, to avoid
 distasteful gaps with other vertical letters like in www
 
 also many fonts for Indian scripts with a head line like Devanagari have a
 similar slightly extending headline
 
 cheers
 dave
 
 On Feb 25, 2015 2:56 AM, Pranay Samanta pranay.samanta.w...@gmail.com
 mailto:pranay.samanta.w...@gmail.com wrote:
 
 Hello
 
 I have a query regarding the glyph's width and the glyph's advance width.
 
 Can glyph width be greater than adnvance width?
 
 And if yes, can you please explain one scenario when and why will it be
 required?
 
 Thanks and regards
 Pranay Samanta
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org mailto:gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Need help understanding how things fit together

[Behdad Esfahbod]

On 15-01-20 11:40 PM, Mindaugas Jaunius wrote:
 Behdad, maybe your presentation using these slides were ever recorded and the
 video is available somewhere?

Unfortunately the IUC conference is not recorded :(.  I've voiced my opinion
to the organizers.


 Also what is the status of harbfbuzz/pango
 integration to android? I saw you mentioned it in slides.

HarfBuzz has been integrated in the Android platform for many years now, as
part of the platform.  Native apps can ship with their own bundled HarfBuzz
and even Pango.  There are a few example bundlings on github.

I can answer more specific questions more specifically :).

behdad

 2015-01-20 21:20 GMT+02:00 Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org:
 
 On 15-01-20 11:10 AM, Anthony Kraft wrote:
  FT has a function FT_Get_Char_Index to get a glyph index from a unicode 
 char
  code. Therefore, it seems you can feed Unicode + font file to FT 
 directly and
  rasterize. What is the benefit of using HarfBuzz to do the unicode to 
 glyph
  mapping instead of using FT directly?
 
 HarfBuzz does what's called complex shaping.  Ie, if you use
 FT_Get_Char_Index, you won't get the correct shapes for Arabic, Indic
 languages, Thai, etc.  You won't get things like ligatures, mark 
 positioning,
 etc either.
 
 See images here:
 
   http://goo.gl/2wSRu
 
 
 --
 behdad
 http://behdad.org/
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org mailto:gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [ft-devel] [PATCHSET] Multithread-safe FreeType

[Behdad Esfahbod]

On 15-01-03 09:16 PM, Behdad Esfahbod wrote:
 On 14-12-30 10:25 PM, Werner LEMBERG wrote:
  
  The patchset mainly removes use of singleton buffers in favor of
  stack or per-face allocated ones.  In all cases this has no down
  side.  [...]
  
  Thanks!  I'll have a look next year :-)
 I've now pushed many more commits out, that fix a couple of invalid memory
 accesses, as well as fixing up allocations such that there is no performance
 hit whatsoever caused by this branch.  If anything, it should speed things up
 a bit.

I'm wondering: did anyone got the chance to try this branch out?

Cheers,
-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [ft-devel] [PATCHSET] Multithread-safe FreeType

[Behdad Esfahbod]

On 14-12-30 10:25 PM, Werner LEMBERG wrote:
 
 The patchset mainly removes use of singleton buffers in favor of
 stack or per-face allocated ones.  In all cases this has no down
 side.  [...]
 
 Thanks!  I'll have a look next year :-)

I've now pushed many more commits out, that fix a couple of invalid memory
accesses, as well as fixing up allocations such that there is no performance
hit whatsoever caused by this branch.  If anything, it should speed things up
a bit.


 Just wondering: How much does
 your patch increase FreeType's memory footprint?

In all cases it should make FreeType allocate and hold onto *less* memory.
The stack consumption has gone up about 20kb (about FT_RENDER_POOL_SIZE +
2kb).  There's one exception, which is the bytecode execution context.  We now
allocate one of that per face on demand.  It's 1kb only.


  What's the behaviour in tight memory situations?

Should be improved.  Instead of relying on allocated memory, many places now
use stack memory.


  In particular, there are still a lot of
 programs that don't need thread safety at all, and for such systems I
 would like to avoid any bloated memory consumptions.

The whole thing streamlines a lot of memory allocations, resulting in fewer
allocations in all cases.


 Werner
 
 
 PS: In general, I would like to test FreeType in situations where the
 available memory is largely reduced so that I intentionally get
 many allocation errors.  Is there a GNU/Linux tool to restrict the
 available memory of a process or program?

I know both dbus and cairo had tools to do this, but can't find either.


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

[PATCHSET] Multithread-safe FreeType

[Behdad Esfahbod]

Hi,

Over the past couple of days I developed a tool for testing FreeType in
multi-threaded environments:

  https://github.com/behdad/ftthread

and a patchset to go with it:

  https://github.com/behdad/freetype/commits/ftthread

With the patchset the test has been running happily for hours, using tens of
threads...

The patchset mainly removes use of singleton buffers in favor of stack or
per-face allocated ones.  In all cases this has no down side.  The exception
is the patch that affects the autohinter, which results in significant (~20%)
slowdown.  I plan to track that down and fix, but believe that the patchset
should be integrated before that.

Some dead code is removed as well.

Here's what https://github.com/behdad/ftthread/blob/master/README currently 
says:


ftthread


This is a test tool to use FreeType2 in a multi-threaded environment.

FreeType2 is not thread-safe, and the original author(s) of FreeType
suggest that one FT_Library per thread should be used.  Unfortunately
this is too inflexible to be really useful.

However, there are ways to use it safely in a multi-threaded environment
with simple modifications to FreeType.  I have now produced a complete
patchset to that effect and tested it using this utility.  The patchset
is available here:

  https://github.com/behdad/freetype/commits/ftthread

and I hope it to be integrated into upstream FreeType very soon.  In
the mean time, here's the new threadsafety model, which needs to be
integrated into FreeType documentation.  Note that cairo graphics
library already uses FreeType in this way and as such the entire GNOME
desktop has been relying on this model, to huge disappointment as seen
in the following bug reports, each of which have many duplicates:

  https://bugzilla.redhat.com/show_bug.cgi?id=678397
  https://bugzilla.redhat.com/show_bug.cgi?id=1004315
  https://bugzilla.redhat.com/show_bug.cgi?id=1164941
  https://bugzilla.redhat.com/show_bug.cgi?id=1165471
  https://bugs.freedesktop.org/show_bug.cgi?id=69034


Threadsafety model
==

  - A FT_Face object can only be safely used from one thread at a time.

  - A FT_Library object can be used without modification from multiple
threads at the same time.

  - FT_Face creation / destruction with the same FT_Library object can
only be done from one thread at a time.


Discussion
==

In this model, one can use a single FT_Library object across threads as
long as a mutex lock is used around FT_New_Face / FT_Done_Face.  Any calls
to FT_Load_Glyph and similar API are safe and do not need the lock to be
held as long as the same FT_Face is not used from multiple threads at the
same time.

Note that this goes almost all the way to making FreeType API useful from
multiple threads.  The only remaining bit is the unfortunately API that is
FT_Library_SetLcdFilter (and to less extent FT_Library_SetLcdFilterWeights).

I will try to work out a solution for replacing FT_Library_SetLcdFilter
using new FT_LOAD_* values.  There seem to be quite a few bits available in
that space, so that work should happen soon.


Running
===

To run this test, give it a font file, and optionally:

  - Number of threads
  - Number of iterations per thread
  - Pixels per EM
  - Load flags in hexadecimal

The tool then will create one FT_Library, spawn many threads, and within
each thread create an FT_Face (after proper locking) and load glyphs from
the font for specified number of iterations and then destruct the face and
return.  The test also destructs and reconstructs the face every 1000
iterations.

Run with no arguments to get usage info.  Quoting here:

usage: ftthread fontfile.ttf [numthreads] [numiters] [ppem] [loadflags-hex]

numthreads, numiters, and ppem default to 100.

loadflags defaults to 0.  Values are in hex.
Useful flags to logically or:
NO_HINTING=2
RENDER=4
FORCE_AUTOHINT=20
MONOCHROME=1000
NO_AUTOHINT=8000
COLOR=10


In particular, I've found the following load_flags values to be useful:

  0 Use native hinting (bytecode / CFF), no rasterization
  2 No hinting whatsoever
  20Use autohinter
  4 Rasterize using smooth rasterizer
  1004  Rasterize using monochrome rasterizer

Remember to test with both TrueType and CFF fonts.  I have done both.
I have not tested bitmap (color or not) fonts, but don't know of any
outstanding issues there.

For example, here's how I test rasterizing glyphs in Roboto-Regular.ttf
using 40 threads, 1 iterations per thread, at 150ppm, and repeat
that until it fails:

$ time while ./ftthread Roboto-Regular.ttf 40 1 150 4; do echo -n '.'; done

Make sure you run ulimit -c unlimited in your shell first such that
you get a core dump when the test fails.

Please report any failures you discover if it happens with a FreeType
including the patchset.


Thanks!

Behdad Esfahbod
30 December 2014
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org

Re: [PATCHSET] Multithread-safe FreeType

[Behdad Esfahbod]

On 14-12-30 04:06 PM, Behdad Esfahbod wrote:
 The patchset mainly removes use of singleton buffers in favor of stack or
 per-face allocated ones.  In all cases this has no down side.  The exception
 is the patch that affects the autohinter, which results in significant (~20%)
 slowdown.  I plan to track that down and fix, but believe that the patchset
 should be integrated before that.

The slowdown was more like 60%.  I've already found the root cause and am
working on a fix.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango, Cairo, Scale, and Ink Rectangles

[Behdad Esfahbod]

On 14-11-24 07:13 PM, Yclept Nemo wrote:
 On Mon, Nov 24, 2014 at 5:12 PM, Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org wrote:
 
 On 14-11-23 11:15 AM, Yclept Nemo wrote:
  This seems impossible if the glyph width/height ratios vary with 
 scale/dpi.
 
 Turn hinting off.  Like this:
 
   https://git.gnome.org/browse/pango/tree/examples/cairotwisted.c#n477
 
 
 Thanks,
 
 It is a necessary suggestion, but unfortunately the glyph width/height ratios
 continue to vary.

Continue to vary in the exact same way?  Or varies, but much much closer to
eachother? Please attach full C test code as well as a pointer to the font,
with actual and expected output.


 I'm pretty sure I've followed the example correctly:
 
 Using Pango resolution:
 cairo_fontoptions = cairo.FontOptions()
 cairo_fontoptions.set_hint_metrics(cairo.HINT_METRICS_OFF)
 cairo_fontoptions.set_hint_style(cairo.HINT_STYLE_NONE)
 ctx.set_font_options(cairo_fontoptions)
 ctx.identity_matrix()
 pango_context = PangoCairo.create_context(ctx)
 PangoCairo.context_set_resolution(pango_context, dpi)
 l1 = Pango.Layout(pango_context)
 l1.set_font_description(font_description)
 l1.set_text(8,1)
 e1 = l1.get_extents()[0]
 print(e1.x / Pango.SCALE, ...)
 
 Using Cairo transformations:
 cairo_fontoptions = cairo.FontOptions()
 cairo_fontoptions.set_hint_metrics(cairo.HINT_METRICS_OFF)
 cairo_fontoptions.set_hint_style(cairo.HINT_STYLE_NONE)
 ctx.set_font_options(cairo_fontoptions)
 ctx.identity_matrix()
 ctx.scale(*(scale,)*2)
 layout = PangoCairo.create_layout(ctx)
 layout.set_font_description(font_description)
 layout.set_text(8,1)
 e1 = layout.get_extents()[0]
 print(e1.x / Pango.SCALE, ...)
 
 Sincerely,

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango with OpenGL on Android (and desktop linux)

[Behdad Esfahbod]

Thanks Ralph for sharing.  I've taken a note of the project.

On 14-10-01 09:27 PM, Ralph Thomas wrote:
 Hi Pango people,
 
 I made a game for Android[1] with a friend this summer -- I wrote a minimal UI
 toolkit that draws with OpenGL directly. I struggled for a while on text
 (Android doesn't give you access to the shaped glyphs and offsets) before
 building Pango and its dependencies for Android and writing a new renderer
 that emits geometry and a glyph cache suitable for use with OpenGL.
 
 My code (as well as a script to build pango et al with NDK) is available here:
 
   https://github.com/iamralpht/letterplex
 
 I don't have any examples of usage in there yet, but I'm happy to add some if
 there's any interest. It uses the freetype backend, so doesn't depend on
 Cairo. It supports colored text, but doesn't yet implement rect drawing (so no
 backgrounds, underlines or strikethroughs).
 
 I was incredibly grateful to be able to get nice looking text without too much
 work. My library links against a regular build of pango (that's what the
 Makefile does) so if there's interest in making a traditionally packaged
 library out of it, or integrating it into pango proper then I'd like to help
 facilitate that.
 
 Thanks!
 Ralph
 
 [1]:
 https://play.google.com/store/apps/details?id=com.infinite_imagination.letterplex
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Kerning: OTF + Pango

[Behdad Esfahbod]

Feel free to send me the font offlist.  It should work.

On 14-10-09 04:15 PM, Anthony O'Brien wrote:
 I can't seem to get kerning features of the OpenType fonts I'm using to show
 up in rendered SVGs when using pango/cairo.
 
 Specifically, I am using the python bindings to pango/cairo/pangocairo that
 are installed as part of the pygtk2 package. I'm laying out text with pango
 and rendering it to an SVG via cairo. The fonts I am using are custom fonts
 that have kerning features applied via features file in RoboFont.
 
 I'd appreciate any suggestions or pointers in the right direction for getting
 kerning to display when using the python bindings.
 
 Thanks,
 Anthony
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango without FreeType (or fontconfig)

[Behdad Esfahbod]

On 14-09-03 07:43 PM, Lóránt Pintér wrote:
 Hi Behdad,
 
 On Wednesday, Sep 3, 2014 at 4:01 pm, Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org, wrote:
 
  I’m not sure what the glib dependency means for us. Can you explain why 
 it
  would be a problem?
 
 It's just one more library you need to cross-compile. And glib comes with
 lots of things that Pango doesn't need and I suppose you wouldn't need, so
 there's some work trimming it down there.
 @behdad.org
 
 I see. Is there any work planned to do this trimming?

There's nothing to do on the upstream side.  It's only about how much of glib
you want to get in your javascript.  On most other platforms compiling the
whole library is not a big deal.


 Do you plan to remove this dependency?

No.  That's not really feasible, given that Pango is a core part of GNOME.
That said, there's a need for a layout engine implementation that is more
flexible than Pango for using in other projects.  So that's something I've
been thinking about in the back of my head.  Nothing concrete right now.


 Does emscripten or the rest of your toolchain already know how to remove
 unused library code?
 @behdad.org
 
 Emscripten, being based on LLVM, has some level of dead code elimination, but
 I haven’t yet looked into it in more depth. As far as I know, it’s supposed to
 be pretty clever.Obviously, the best for us would be if Pango didn’t depend
 on GLib at all. :)

 
  Current versions of pango use a convoluted module system to choose 
 shapers. I
  have a branch that removes most of that:
  
  https://github.com/behdad/pango/tree/kill-modules
  
  Cool. Is there a plan to merge this into the main line?
 
 Yes. It's very close to being mergable. I just need to do the same (ie
 hardcode) language modules the same way I did for shaper modules. I'm away
 for vacation and conferences for multiple weeks though, but expect this to
 definitely land later this year.
 @behdad.org
 
 
 That sounds good. So we can basically start working with this branch, and
 start using master when you merge back.

Sounds good.


  After that, you need to implement a set of PangoFontMap / 
 PangoFontFamily /
  PangoFontFace / PangoFont subclasses since you don't want to use 
 PangoFc.
  This is rather straightforward, if you don't want much font 
 fallback.
  
  Sounds workable. We already have similar classes in our own 
 implementation
  that I want to replace with Pango.
  
  For the shaper part, modify pangofc-shape.c. You just need access 
 to the
  hb_face and you can do the rest from there.
  
  I’m looking for a solution where (eventually) I won't need to keep a 
 separate
  branch of Pango. Would it be possible to do this without modifying 
 existing code?
 
 You don't need to modify anything. libpangofc itself uses libpango's 
 public
 API only. You will be doing the same. Right now that involves copying
 pangofc-shape.c and modifying it. Some time in the future I'll hardcode
 HarfBuzz as the only shaper Pango supports, and at that time the logic in
 pangofc-shape.c will be shared across all backends and you can remove your
 copy.
 @behdad.org
 
 
 That sounds promising. Do you know when this “some time in the future” would
 happen?

I'm hoping for later this year or early next year.


 Let me know if you have any other questions. I'm really curious to see 
 this
 in action.
 @behdad.org
 
 
 Great. :) I’d be very excited to see it myself as well. That said, this is
 going to be a side-project for me. I’m not too experienced with C++ either, so
 I might need to recruit someone to help me with the details, too. But if it is
 at all possible, I’d like to get it working before the end of the year. With
 your help it seems doable.

Given what you have already done with HarfBuzz before, I think you are in a
great position to get this working.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango without FreeType (or fontconfig)

[Behdad Esfahbod]

Hi Lóránt,

On 14-08-28 09:26 PM, Lóránt Pintér wrote:
 Hi,
 
 I’m currently using HarfBuzz compiled to JavaScript via Emscripten with a
 custom (primitive) layout engine. I’d like to replace the custom layout engine
 with Pango (also compiled to JS) if possible. To do this, I’d need to be able
 to compile Pango with our custom JS font loading (which already works with
 HarfBuzz). Is this possible? If so, where should I start digging?

So, you are OK with the glib dependency?

Current versions of pango use a convoluted module system to choose shapers.  I
have a branch that removes most of that:

  https://github.com/behdad/pango/tree/kill-modules

After that, you need to implement a set of PangoFontMap / PangoFontFamily /
PangoFontFace / PangoFont subclasses since you don't want to use PangoFc.
This is rather straightforward, if you don't want much font fallback.

For the shaper part, modify pangofc-shape.c.  You just need access to the
hb_face and you can do the rest from there.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango without FreeType (or fontconfig)

[Behdad Esfahbod]

On 14-09-03 02:57 PM, Lóránt Pintér wrote:
 Hey, thanks for replying. Comments inline.
 
 On Wednesday, Sep 3, 2014 at 12:58 pm, Behdad Esfahbod 
 beh...@behdad.org mailto:beh...@behdad.org
, wrote:
 
 So, you are OK with the glib dependency?
 
 I’m not sure what the glib dependency means for us. Can you explain why it
 would be a problem?

It's just one more library you need to cross-compile.  And glib comes with
lots of things that Pango doesn't need and I suppose you wouldn't need, so
there's some work trimming it down there.

Does emscripten or the rest of your toolchain already know how to remove
unused library code?


 Current versions of pango use a convoluted module system to choose 
 shapers. I
 have a branch that removes most of that:
 
 https://github.com/behdad/pango/tree/kill-modules
 
 Cool. Is there a plan to merge this into the main line?

Yes.  It's very close to being mergable.  I just need to do the same (ie
hardcode) language modules the same way I did for shaper modules.  I'm away
for vacation and conferences for multiple weeks though, but expect this to
definitely land later this year.


 After that, you need to implement a set of PangoFontMap / PangoFontFamily 
 /
 PangoFontFace / PangoFont subclasses since you don't want to use PangoFc.
 This is rather straightforward, if you don't want much font fallback.
 
 Sounds workable. We already have similar classes in our own implementation
 that I want to replace with Pango.
 
 For the shaper part, modify pangofc-shape.c. You just need access to the
 hb_face and you can do the rest from there.
 
 I’m looking for a solution where (eventually) I won't need to keep a separate
 branch of Pango. Would it be possible to do this without modifying existing 
 code?

You don't need to modify anything.  libpangofc itself uses libpango's public
API only.  You will be doing the same.  Right now that involves copying
pangofc-shape.c and modifying it.  Some time in the future I'll hardcode
HarfBuzz as the only shaper Pango supports, and at that time the logic in
pangofc-shape.c will be shared across all backends and you can remove your copy.


 Thanks,
 Lorant

Let me know if you have any other questions.  I'm really curious to see this
in action.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango manual rendering

[Behdad Esfahbod]

On 14-08-01 05:53 PM, Edu García wrote:
 Thank you for your response.
 
 That's how I'm using the geometry right now, but I don't seem to get things
 like alignment work. Even after setting a width on my layout, with right
 alignment I get the exact same result as with left alignment (I assumed the
 first glyph will get a very big X offset, to set the line start position, but
 it's not happening)

I don't remember the details.  Check pango-renderer.c.  Perhaps a better
option is to subclass PangoRenderer for your application.


 As for ligatures, is there any way of getting the underlying Harfbuzz handle
 and do it there, even with some sort of hack?

Not right now.  If you want to disable them so badly and don't mind getting
yourself comfortable with gobject, then you can subclass PangoCairoFcFontMap
and override the fontset_key_substitute(), and in there set
PANGO_FC_FONT_FEATURES on the pattern...  You might need rather recent pango
and fontconfig for this to work.


 Again, thank you for your responses!
 
 On Aug 2, 2014 6:51 AM, Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org wrote:
 
 On 14-08-01 11:04 AM, Edu García wrote:
  Hi,
 
  I want to use Pango for layout, but not for rendering. I have a proof of
  concept that works, but I think it's not the right way of doing things 
 :)
 
  I create a PangoLayout with my text, then get a PangoLayoutIter, then I
 start
  calling next_line() on it until it returns FALSE. On every iteration, I
 get a
  run (that returns a PangoGlyphItem) and iterate over the contained
  PangoGlyphString.
 
  This works but, as I said, I think it's the wrong thing to do, I'm not
 sure if
  depending on next_line() is a good idea, I'm not sure if there is a
  correlation between that call and the call to get_run().
 
 I think that's how you are supposed to call it.
 
 
  The second problem is that for every glyph, I get the
 PangoGlyphGeometry, but
  the X and Y offsets are always 0. This might be just because the font's 
 I've
  tried work like that, but I just want to make sure.
 
 Keep accumulating the advance.  Just add X / Y offsets to the sum of 
 advances
 of previous glyphs on the line, to get the position of current glyph.
 
 
  Another unrelated question is, how can I disable ligatures using Pango?
 
 Currently you can't.
 
 
  Sorry if this is a bit confusing, but there is little to no information
 about
  what I'm trying to do.
 
 
 --
 behdad
 http://behdad.org/
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango manual rendering

[Behdad Esfahbod]

On 14-08-02 03:20 PM, Behdad Esfahbod wrote:
 Not right now.  If you want to disable them so badly and don't mind getting
 yourself comfortable with gobject, then you can subclass PangoCairoFcFontMap
 and override the fontset_key_substitute(), and in there set
 PANGO_FC_FONT_FEATURES on the pattern...  You might need rather recent pango
 and fontconfig for this to work.

Umm.  Actually looks like even using that you can only enable features, not
disable.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango manual rendering

[Behdad Esfahbod]

On 14-08-01 11:04 AM, Edu García wrote:
 Hi,
 
 I want to use Pango for layout, but not for rendering. I have a proof of
 concept that works, but I think it's not the right way of doing things :)
 
 I create a PangoLayout with my text, then get a PangoLayoutIter, then I start
 calling next_line() on it until it returns FALSE. On every iteration, I get a
 run (that returns a PangoGlyphItem) and iterate over the contained
 PangoGlyphString.
 
 This works but, as I said, I think it's the wrong thing to do, I'm not sure if
 depending on next_line() is a good idea, I'm not sure if there is a
 correlation between that call and the call to get_run().

I think that's how you are supposed to call it.


 The second problem is that for every glyph, I get the PangoGlyphGeometry, but
 the X and Y offsets are always 0. This might be just because the font's I've
 tried work like that, but I just want to make sure.

Keep accumulating the advance.  Just add X / Y offsets to the sum of advances
of previous glyphs on the line, to get the position of current glyph.


 Another unrelated question is, how can I disable ligatures using Pango?

Currently you can't.


 Sorry if this is a bit confusing, but there is little to no information about
 what I'm trying to do.


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Using Pango for text rendering on Android

[Behdad Esfahbod]

On 14-07-09 08:29 AM, György Kövesdi wrote:
 Hi,
 
 I have a multi-platform project which needs software rendering of
 graphical primitives (lines, circles, etc) and international text into
 memory pixmaps.
 Pango seems to be a good choice for this purpose, and it works perfectly
 for me on some different Linux platforms, including embedded devices.
 Recently I ported it to Android (based on
 http://dev.laptop.org/git/users/cscott/android-libs ) and it works fine,
 except that the initialization time is 2 minutes (!) on my fastest
 device (1.7 GHz CPU). According to debug results, the fontconfig
 initialization is guilty. It makes the application completely unusable,
 however, the rendering speed is perfect (after the initialization has
 been completed).

 Any ideas would be appreciated to resolve this problem.

Try fontconfig from master.  It should be significantly faster.  I also have
an experimental patch that is not good enough for merging, but should be good
enough for you to use.  Please report your findings.  Patch attached here:

  https://bugs.freedesktop.org/show_bug.cgi?id=64766#c31

Also, if you can configure fontconfig to cache the fonts on the device, that
should make it fast to start up subsequently.

 My questions are:
 
 - Is it possible to use the Android built-in Java-based font rendering?
 IMHO it would be the better solution. I found some articles about it on
 the net, but could not find real solution.

Using Android text rendering from an Android app?  Yes, I'm sure it's possible
:).  From a native app?  I don't know.


 - Can I use other font-render backends for Pango?

You can't use CoreText and Win32, so you are left with fontconfig one, unless
you are willing to write a new one.


 - Is there any similar solution other than Pango?

There's no other full solution that I know of.


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Using Pango for text rendering on Android

[Behdad Esfahbod]

Alternatively, check this:

  https://github.com/anoek/ex-sdl-cairo-freetype-harfbuzz

It's nowhere near what Pango does, but might be good enough for you.

On 14-07-10 03:51 PM, Behdad Esfahbod wrote:
 On 14-07-09 08:29 AM, György Kövesdi wrote:
 Hi,

 I have a multi-platform project which needs software rendering of
 graphical primitives (lines, circles, etc) and international text into
 memory pixmaps.
 Pango seems to be a good choice for this purpose, and it works perfectly
 for me on some different Linux platforms, including embedded devices.
 Recently I ported it to Android (based on
 http://dev.laptop.org/git/users/cscott/android-libs ) and it works fine,
 except that the initialization time is 2 minutes (!) on my fastest
 device (1.7 GHz CPU). According to debug results, the fontconfig
 initialization is guilty. It makes the application completely unusable,
 however, the rendering speed is perfect (after the initialization has
 been completed).

 Any ideas would be appreciated to resolve this problem.
 
 Try fontconfig from master.  It should be significantly faster.  I also have
 an experimental patch that is not good enough for merging, but should be good
 enough for you to use.  Please report your findings.  Patch attached here:
 
   https://bugs.freedesktop.org/show_bug.cgi?id=64766#c31
 
 Also, if you can configure fontconfig to cache the fonts on the device, that
 should make it fast to start up subsequently.
 
 My questions are:

 - Is it possible to use the Android built-in Java-based font rendering?
 IMHO it would be the better solution. I found some articles about it on
 the net, but could not find real solution.
 
 Using Android text rendering from an Android app?  Yes, I'm sure it's possible
 :).  From a native app?  I don't know.
 
 
 - Can I use other font-render backends for Pango?
 
 You can't use CoreText and Win32, so you are left with fontconfig one, unless
 you are willing to write a new one.
 
 
 - Is there any similar solution other than Pango?
 
 There's no other full solution that I know of.
 
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango default font

[Behdad Esfahbod]

On 14-05-07 10:45 AM, Antonio Roberts wrote:
 Hi,
 
 I recently used Pango to add text to a series of images (see here:
 https://www.flickr.com/photos/hellocatfood/sets/72157641915581285/ )
 
 I used pango in conjunction with imagemagick and didn't specify a
 font. Is there any way to find out what font was used?

Try running fc-match serif --sort and walk down the list until you get to
the first font that you think supports those characters.  Looks like DejaVu
Serif to me.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango font rendering on OSX

[Behdad Esfahbod]

On 14-03-14 01:58 PM, Vojtěch Knyttl wrote:
 I can list it with fontconfig as well:

Does fc-list or fc-match find it?  Looks like that directory is not scanned by
fontconfig.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: SCRIPT_FONTPROPERTIES(windows uniscribe) : how to get font properties on linux

[Behdad Esfahbod]

On 14-01-28 10:58 AM, ken wrote:
 no, need to get all font properties.
 you would see the link above(uniscribe)

Then go figure out how to do it...

 此邮件来自易信 - 点击下载，体验邮件随身提醒！ http://u.163.com/yxgw?from=chajian
 
 
 
 在2014年1月28日 23:52:09, Behdad Esfahbod beh...@behdad.org 写道：
 
 On 14-01-24 07:18 AM, ken wrote:
  eg,we need to get the glyph which is indicate a blank.

 Just get the glyph for the space character perhaps.

 --
 behdad
 http://behdad.org/
 
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: SCRIPT_FONTPROPERTIES(windows uniscribe) : how to get font properties on linux

[Behdad Esfahbod]

On 14-01-24 07:18 AM, ken wrote:
 eg,we need to get the glyph which is indicate a blank.

Just get the glyph for the space character perhaps.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Activating the 'calt' feature in (Py)GTK

[Behdad Esfahbod]

On 14-01-22 03:29 PM, Alexis Luengas wrote:
 Thank you Dave, but WebKit does not implement the 'calt' feature in a fully
 thorough way; it seems to omit certain lookups.

Try text-rendering:optimizeLegibility in your CSS, and of-course turning on
'calt' feature.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: SCRIPT_FONTPROPERTIES(windows uniscribe) : how to get font properties on linux

[Behdad Esfahbod]

On 14-01-23 03:42 AM, ken wrote:
 Hello everybody:
 I am porting a program from uniscribe(windows) to pango(linux), but I don't
 know how to get font properties on linux.
 Does anybody know?

We don't have anything similar to that.  Why exactly does the code need this?


 http://msdn.microsoft.com/en-us/library/windows/desktop/dd368802%28v=vs.85%29.aspx
 
 
 Thanks
 Ken
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/dd368802%28v=vs.85%29.aspx
 
 
 http://msdn.microsoft.com/en-us/library/windows/desktop/dd368802%28v=vs.85%29.aspx
 
 
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Activating the 'calt' feature in (Py)GTK

[Behdad Esfahbod]

On 14-01-23 03:58 PM, Alexis Luengas wrote:
 I have tried that already, but thanks Behdad. If you are curious, the lookup
 types which WebKit misses are, among others:
 
 lookup foo{
   sub backtrack glyphs @class1' look ahead glyphs by @class2;
 } foo;
 
 (where class1 and class2 are of course disjunct classes with the same number
 of glyphs)

Humm.  I bet either your backtrack or lookahead includes non-letters?  That's
a known bug that is being worked on.

behdad

 On Thu, Jan 23, 2014 at 6:59 PM, Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org wrote:
 
 On 14-01-22 03:29 PM, Alexis Luengas wrote:
  Thank you Dave, but WebKit does not implement the 'calt' feature in a 
 fully
  thorough way; it seems to omit certain lookups.
 
 Try text-rendering:optimizeLegibility in your CSS, and of-course turning 
 on
 'calt' feature.
 
 --
 behdad
 http://behdad.org/
 
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Activating the 'calt' feature in (Py)GTK

[Behdad Esfahbod]

On 14-01-23 04:56 PM, Alexis Luengas wrote:
 That's right! I'll stay tuned for the fix.

This is the bug to track:

  https://code.google.com/p/chromium/issues/detail?id=311372

 
 On Thu, Jan 23, 2014 at 10:14 PM, Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org wrote:
 
 On 14-01-23 03:58 PM, Alexis Luengas wrote:
  I have tried that already, but thanks Behdad. If you are curious, the 
 lookup
  types which WebKit misses are, among others:
 
  lookup foo{
sub backtrack glyphs @class1' look ahead glyphs by @class2;
  } foo;
 
  (where class1 and class2 are of course disjunct classes with the same 
 number
  of glyphs)
 
 Humm.  I bet either your backtrack or lookahead includes non-letters?  
 That's
 a known bug that is being worked on.
 
 behdad
 
  On Thu, Jan 23, 2014 at 6:59 PM, Behdad Esfahbod beh...@behdad.org
 mailto:beh...@behdad.org
  mailto:beh...@behdad.org mailto:beh...@behdad.org wrote:
 
  On 14-01-22 03:29 PM, Alexis Luengas wrote:
   Thank you Dave, but WebKit does not implement the 'calt' feature
 in a fully
   thorough way; it seems to omit certain lookups.
 
  Try text-rendering:optimizeLegibility in your CSS, and of-course
 turning on
  'calt' feature.
 
  --
  behdad
  http://behdad.org/
 
 
 
 --
 behdad
 http://behdad.org/
 
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Activating the 'calt' feature in (Py)GTK

[Behdad Esfahbod]

On 14-01-22 08:45 AM, Alexis Luengas wrote:
 
 I'm looking for a way of adding the 'calt' feature to an entire TextView
 object. Is this possible with PyGTK?

Currently, no.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: inconsistency of pangocairo on Mac and Linux

[Behdad Esfahbod]

On 14-01-15 09:31 PM, Jun T. wrote:
 Is this a bug of pangocairo on Mac?

Just pushed out a patch to default to 96dpi on CoreText.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: issue with Devanagari rendering

[Behdad Esfahbod]

On 14-01-09 06:23 PM, Parth Kanungo wrote:
 Hello Werner, Behdad,
 
  
 
 Probably I am getting things wrong here.
 
 I infer that you are suggesting that the fault lies in the font file itself.
 
  
 
 I ran my code with different font files available in Windows, like Kokila,
 Managal and Arial Unicode MS, all of which contain the Unicode U+25CC.
 The output is still wrong.
 
  
 
 Don't you think that this behaviour has anything to do with harfbuzz?

Ok, maybe then you should send a screenshot, like any useful bug report has.

 Thanks and regards,
 
 Parth Kanungo
 
 // 
 
  
 
  
 
  
 
  
 
 --- *Original Message* ---
 
 *Sender* : Behdad Esfahbodbeh...@behdad.org
 
 *Date* : Jan 09, 2014 12:39 (GMT+05:30)
 
 *Title* : Re: issue with Devanagari rendering
 
  
 
 On 14-01-09 02:19 PM, Werner LEMBERG wrote:

 Get a non-broken-beyond-repair font.  Ie. remove freesans from your
 system.

 Hmm.  FreeSans is actively developed, as far as I know.  So why not
 contact the author so that he fixes such issues?
 
 The maintainer is in fact CC'ed on this message already.  Recent versions have
 fixed a lot, but the version stuck on most Linux distros is beyond repair in
 the shaper.
 
 In general, I've found that both GNU freefonts and GNU unifont have a
 quantity-over-quality mindset that is quite hurtful IMO.
 
 -- 
 behdad
 http://behdad.org/
 
  
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: issue with Devanagari rendering

[Behdad Esfahbod]

That *is* correct rendering.  What do you expect?

On 14-01-09 06:42 PM, Parth Kanungo wrote:
 Hi Behdad,
 
  
 
 Attached are the images, I got from the string { 0x094D, 0x0930, 0x };
 
 Also, attached is the test code to reproduce the issue.
 
  
 
 Thanks and regards,
 
 Parth Kanungo
 
  
 
  
 
 --- *Original Message* ---
 
 *Sender* : Behdad Esfahbodbeh...@behdad.org
 
 *Date* : Jan 09, 2014 15:56 (GMT+05:30)
 
 *Title* : Re: issue with Devanagari rendering
 
  
 
 On 14-01-09 06:23 PM, Parth Kanungo wrote:
 Hello Werner, Behdad,

  

 Probably I am getting things wrong here.

 I infer that you are suggesting that the fault lies in the font file itself.

  

 I ran my code with different font files available in Windows, like Kokila,
 Managal and Arial Unicode MS, all of which contain the Unicode U+25CC.
 The output is still wrong.

  

 Don't you think that this behaviour has anything to do with harfbuzz?
 
 Ok, maybe then you should send a screenshot, like any useful bug report has.
 
 Thanks and regards,

 Parth Kanungo

 //

  

  

  

  

 --- *Original Message* ---

 *Sender* : Behdad Esfahbod

 *Date* : Jan 09, 2014 12:39 (GMT+05:30)

 *Title* : Re: issue with Devanagari rendering

  

 On 14-01-09 02:19 PM, Werner LEMBERG wrote:

 Get a non-broken-beyond-repair font.  Ie. remove freesans from your
 system.

 Hmm.  FreeSans is actively developed, as far as I know.  So why not
 contact the author so that he fixes such issues?

 The maintainer is in fact CC'ed on this message already.  Recent versions 
 have
 fixed a lot, but the version stuck on most Linux distros is beyond repair in
 the shaper.

 In general, I've found that both GNU freefonts and GNU unifont have a
 quantity-over-quality mindset that is quite hurtful IMO.

 --
 behdad
 http://behdad.org/

  



 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

 
 -- 
 behdad
 http://behdad.org/
 
  
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: issue with Devanagari rendering

[Behdad Esfahbod]

On 14-01-09 06:51 PM, Parth Kanungo wrote:
 I expect this dotted circle with halant and also a Ra (र)

The halant-ra forms a vattu and that's what you are getting.

 Grammatically, it might be inaccurate. But, my problem is related with input
 method.
 
 So, if a user enters something wrong, my application should be able to render 
 it.
 
  
 
 --- *Original Message* ---
 
 *Sender* : Behdad Esfahbodbeh...@behdad.org
 
 *Date* : Jan 09, 2014 16:14 (GMT+05:30)
 
 *Title* : Re: issue with Devanagari rendering
 
  
 
 That *is* correct rendering.  What do you expect?
 
 On 14-01-09 06:42 PM, Parth Kanungo wrote:
 Hi Behdad,

  

 Attached are the images, I got from the string { 0x094D, 0x0930, 0x };

 Also, attached is the test code to reproduce the issue.

  

 Thanks and regards,

 Parth Kanungo

  

  

 --- *Original Message* ---

 *Sender* : Behdad Esfahbod

 *Date* : Jan 09, 2014 15:56 (GMT+05:30)

 *Title* : Re: issue with Devanagari rendering

  

 On 14-01-09 06:23 PM, Parth Kanungo wrote:
 Hello Werner, Behdad,

  

 Probably I am getting things wrong here.

 I infer that you are suggesting that the fault lies in the font file itself.

  

 I ran my code with different font files available in Windows, like Kokila,
 Managal and Arial Unicode MS, all of which contain the Unicode U+25CC.
 The output is still wrong.

  

 Don't you think that this behaviour has anything to do with harfbuzz?

 Ok, maybe then you should send a screenshot, like any useful bug report has.

 Thanks and regards,

 Parth Kanungo

 //

  

  

  

  

 --- *Original Message* ---

 *Sender* : Behdad Esfahbod

 *Date* : Jan 09, 2014 12:39 (GMT+05:30)

 *Title* : Re: issue with Devanagari rendering

  

 On 14-01-09 02:19 PM, Werner LEMBERG wrote:

 Get a non-broken-beyond-repair font.  Ie. remove freesans from your
 system.

 Hmm.  FreeSans is actively developed, as far as I know.  So why not
 contact the author so that he fixes such issues?

 The maintainer is in fact CC'ed on this message already.  Recent versions 
 have
 fixed a lot, but the version stuck on most Linux distros is beyond repair in
 the shaper.

 In general, I've found that both GNU freefonts and GNU unifont have a
 quantity-over-quality mindset that is quite hurtful IMO.

 --
 behdad
 http://behdad.org/

  



 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list


 --
 behdad
 http://behdad.org/

  

 
 -- 
 behdad
 http://behdad.org/
 
  
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: issue with Devanagari rendering

[Behdad Esfahbod]

On 14-01-08 11:21 PM, Parth Kanungo wrote:
 On further investigation, I found that even this string
 
 {0x094D, 0x0930,0x094D, 0x0930,0x094D, 0x0930}
 
 shows wrong output.

Get a non-broken-beyond-repair font.  Ie. remove freesans from your system.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: issue with Devanagari rendering

[Behdad Esfahbod]

On 14-01-09 02:19 PM, Werner LEMBERG wrote:
 
 Get a non-broken-beyond-repair font.  Ie. remove freesans from your
 system.
 
 Hmm.  FreeSans is actively developed, as far as I know.  So why not
 contact the author so that he fixes such issues?

The maintainer is in fact CC'ed on this message already.  Recent versions have
fixed a lot, but the version stuck on most Linux distros is beyond repair in
the shaper.

In general, I've found that both GNU freefonts and GNU unifont have a
quantity-over-quality mindset that is quite hurtful IMO.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: ellipsis per layout

[Behdad Esfahbod]

On 14-01-02 01:36 PM, Parth Kanungo wrote:
 Hello,
 
  
 
 I was trying to add ellipsis to a text containing '\n'.
 
 I noticed that pango implements ellipsis per paragraph, but not ellipsis per
 layout.
 
 Can anyone throw some light on how to go about implementing it ?

If you can patch PangoLayout to implement that, I will take it upstream.

 
 I ran the following test sample, where I expect an ellipsis after an.
 
 text = This is sample text to reproduce an\n\n issue related to ellipsis
 
 font_size = 20,  layout.width = 150,   layout.height = 60
 
  
 
 Thanks and regards,-
 
 Parth Kanungo
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: regarding open file descriptors in Pango

[Behdad Esfahbod]

You are on your own re implementing FT_Face caching on PangoFT2 fontmaps.  If
you come up with a cache, I'll consider upstreaming it.

behdad

On 13-10-29 04:45 AM, Parth Kanungo wrote:
 Hello all,
 
  
 
 I observed that in pangoft2, the file descriptor opened for the font file,
 does not get closed until we destroy the PangoFontMap.
 
 If we create 2 or 3 instances of PangoFontMap and try to render for different
 sizes, for every size, pangoft2 opens a file descriptor.
 
 This is creating an issue in my module, as multiple file descriptors get 
 opened.
 
 To achieve my goal, I have closed the file descriptor in
 pango_ft2_unlock_face() by calling FT_Done_Face().
 
 But, this implementation opens and closes the file every time, which is a bit
 costly.
 
 Is there any other workaround for this ?
 
  
 
 Thanks and regards,
 
 Parth Kanungo
 
 // 
 
  
 
  
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: file descriptors in pango

[Behdad Esfahbod]

Which backend are you using?

On 13-10-17 01:11 PM, Parth Kanungo wrote:
 Hello,
 
  
 
 I observed that when pango_fc_font_lock_face() is used, it opens a file
 descriptor.
 
 I was hoping that pango_fc_font_unlock_face() would close the file descriptor.
 However, it does nothing. In fact, the function does not have any body.
 
 Is this a bug ?
 
  
 
 This seems to be causing my application to shut down after some time, as a
 whole lot of memory is occupied by open font file descriptors (for the same
 font file).
 
  
 
 Thanks and regards,
 
 Parth Kanungo
 
 // 
 
  
 
  
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: issue with line break option PANGO_WRAP_CHAR

[Behdad Esfahbod]

On 13-09-06 08:22 AM, Parth Kanungo wrote:
 Hello,
 
 I am facing an issue with a line break option - PANGO_WRAP_CHAR.
 
 You can see the output (image.bmp)
 
 for my code (main.cpp)
 
 It is clear that i can be rendered on the first line after Th.
 
 However, it is coming on the second line. This is wrong.
 
 Is this a known bug?

There's many things going on here:

1. Unicode line breaking algorithm prohibits breaking before a space.  As such
we try to fit the space after i in the same line.  Normally, after we break
line, we zero the width of the final space on the line (see
pango-layout.c:zero_line_final_space).  We try to account for that when
deciding where to break, but it's possible that we are messing things up,

2. When WRAP_CHAR, we still never break before a space, while sometimes that's
the right thing to do no matter what Unicode says.

In short, that piece of code needs some long overdue love, but I don't know
anyone with the time and expertise to look into it right now.

behdad

 
 I further debugged and found that
 
 1. can_break_at() gives false for space character.
 
 2. break_width contains the width of Th only, when it should contain the
 width of The
 
  
 
 But, I am not sure how to fix this.
 
 Moreover, this problem aggravates if we introduce multiple spaces between 2 
 words.
 
  
 
 Any pointers in this direction would be helpful.
 
  
 
 Thanks and regards,
 Parth Kanungo
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Issue with composite glyph rendering in Hindi Text

[Behdad Esfahbod]

On 13-07-22 11:51 AM, Parth Kanungo wrote:
  Hello,
 
  
 
 When I render Hindi Text using PANGO_WRAP_CHAR, the breaks are incorrect (
 See: pangoCairo.png ). Some of the composite glyphs get distributed on 2 
 lines.
 
 Attach with the mail is an example code (this time using PangoCairo).
 
 Any pointers on this would be helpful.

I would have expected that the grapheme boundaries would prevent breaks there.
 But apparently I'm wrong.  Feel free to take a look into break.c to see if
you can fix it.  Not sure what Unicode recommends in such cases, but we
definitely don't want to disallow cursor positions in an entire Indic cluster.
 On the other hand, the issue you raise cannot be solved without doing so.
I'm not sure what a desirable outcome would be.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: regarding setting resolution in pangoft2

[Behdad Esfahbod]

On 13-07-10 01:06 AM, Parth Kanungo wrote:
 In that case, I will try to resolve this myself.
 
 By the way, if I can find a solution to this issue, would that be accepted and
 added in the next release by the pango community ?

Possible.

 Or, do you plan to deprecate PangoFT2 in the upcoming releases?

No.

  
 
 --- *Original Message* ---
 
 *Sender* : Behdad Esfahbodbeh...@behdad.org
 
 *Date* : Jul 09, 2013 20:01 (GMT+05:30)
 
 *Title* : Re: regarding setting resolution in pangoft2
 
  
 
 AFAIK Pango doesn't currently support that.  And PangoFT2 is obsolete as far
 as I'm concerned...
 
 On 13-07-09 10:09 AM, Parth Kanungo wrote:
 Okay, It does impact the resolution.

 What I meant is that the effect is observed only when I change the
 Y-resolution (dpi_y).

 Moreover, the value passed in dpi_y impacts both the x-resolution and the
 y-resolution. This behaviour seems wrong and is illustrated in the attached
 output images and sample code. ( 72_140.bmp means dpi_x=72 and dpi_y=140 )

  

 Can you tell me how do I modify only the X resolution (without impacting Y
 resolution at all)?

 It seems that it has something to do with FT_Set_Char_Size() statement in
 pangoft2.c

 --

 Thanks and regards,

 Parth Kanungo

  

 --- *Original Message* ---

 *Sender* : Behdad Esfahbod

 *Date* : Jul 09, 2013 18:31 (GMT+05:30)

 *Title* : Re: regarding setting resolution in pangoft2

  

 On 13-07-09 08:06 AM, Parth Kanungo wrote:
 it did not impact the resolution.

 What do you mean by this exactly?

 The resolution is only used when converting from font size in points to 
 font
 size in pixels.

 --
 behdad
 http://behdad.org/

  

  

 
 -- 
 behdad
 http://behdad.org/
 
  
 
 
 
 ___
 gtk-i18n-list mailing list
 gtk-i18n-list@gnome.org
 https://mail.gnome.org/mailman/listinfo/gtk-i18n-list
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: regarding setting resolution in pangoft2

[Behdad Esfahbod]

On 13-07-09 08:06 AM, Parth Kanungo wrote:
 it did not impact the resolution.

What do you mean by this exactly?

The resolution is only used when converting from font size in points to font
size in pixels.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: regarding setting resolution in pangoft2

[Behdad Esfahbod]

AFAIK Pango doesn't currently support that.  And PangoFT2 is obsolete as far
as I'm concerned...

On 13-07-09 10:09 AM, Parth Kanungo wrote:
 Okay, It does impact the resolution.
 
 What I meant is that the effect is observed only when I change the
 Y-resolution (dpi_y).
 
 Moreover, the value passed in dpi_y impacts both the x-resolution and the
 y-resolution. This behaviour seems wrong and is illustrated in the attached
 output images and sample code. ( 72_140.bmp means dpi_x=72 and dpi_y=140 )
 
  
 
 Can you tell me how do I modify only the X resolution (without impacting Y
 resolution at all)?
 
 It seems that it has something to do with FT_Set_Char_Size() statement in
 pangoft2.c
 
 --
 
 Thanks and regards,
 
 Parth Kanungo
 
  
 
 --- *Original Message* ---
 
 *Sender* : Behdad Esfahbodbeh...@behdad.org
 
 *Date* : Jul 09, 2013 18:31 (GMT+05:30)
 
 *Title* : Re: regarding setting resolution in pangoft2
 
  
 
 On 13-07-09 08:06 AM, Parth Kanungo wrote:
 it did not impact the resolution.
 
 What do you mean by this exactly?
 
 The resolution is only used when converting from font size in points to font
 size in pixels.
 
 -- 
 behdad
 http://behdad.org/
 
  
 
  
 

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Contribute to Pango source.

[Behdad Esfahbod]

On 13-06-25 01:43 PM, Pranay Samanta wrote:
 Hello,
 
 I have implemented a few features (like Monospace and PANGO_WRAP_HYPHEN) using
 pango and pangoft2. I was wondering if I could get that code reviewed and
 contribute in the next update of Pango.
 
 However, I could not find any guidelines or Do's n Don'ts about this
 on http://www.pango.org/Contributing
 
 Can anyone share with me the guidelines/procedure to be followed while
 submitting the code ? 

Please file bugs on bugzilla.gnome.org and attach patches.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Making Graphite2 work with Pango?

[Behdad Esfahbod]

On 13-06-21 01:37 PM, Alex Kerr wrote:
 Many thanks for any ideas on how to get this working!

I'm more inclined to say that you probably have an installation issue, ie.
running against older Pango, not the one you built.  Otherwise, if your Pango
is using HarfBuzz, and HarfBuzz has graphite2 enabled, it should all just
work.  You should try with the hb-view tool.  That one also has a --shaper
option that you can use to nail down what shaper is doing the work.

-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Pango Hindi Text rendering error

[Behdad Esfahbod]

On 13-06-12 10:01 PM, Mayank Jha wrote:
 you mean to say that these fonts aren't supposed to render conjugate 
 characters ?

Unless the fonts render correctly on *some* environment, I'd say the font is
just incomplete.


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: difference between inkRect and logRect

[Behdad Esfahbod]

On 13-06-12 12:10 PM, Parth Kanungo wrote:
 Can you tell me the difference between inkRect and logRect ?

ink_rect is exactly what it says: tight bounding box of glyph images.
logical_rect is the conceptual size of the text.  Say, you have a line of text
that has one period only: .  The ink rect of that line has a very narrow
height, but for line spacing purposes we want it to have a full line's height.
 Same for width: even if the glyph spills way out on the sides, conceptually
the glyph has an advance width narrower than the ink width.  Those values are
what logical_rect returns.


-- 
behdad
http://behdad.org/
___
gtk-i18n-list mailing list
gtk-i18n-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-i18n-list