Nabble - Gtk+ - Internationalization

Re: [rrd] Re: pango / fontconfig / cairo performance with rrdtool

2008-09-04T14:38:11Z

Hi Behdad,

> No, unless you:
>
> - Use a different fontmap each time (that is, you use
> pango_cairo_font_map_new())
>
> - Call pango_fc_font_map_clear_cache()
>
> - Use more than 64 different font descriptions
>
> none of which you seem to be doing.

drawing from the don'ts, I have modified my system as follows.

static PangoFontMap *fontmap = NULL;

surface = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, 100, 100);
cr = cairo_create(surface);

if (fontmap == NULL){
fontmap = pango_cairo_font_map_get_default();
}

context = pango_cairo_font_map_create_context((PangoCairoFontMap*)fontmap);

pango_cairo_context_set_resolution(context, 100);

pango_cairo_update_context(cr,context);

layout = pango_layout_new(context);

this seems to work and I like to think that it is because I
preserve the font map across multiple graphs ...

cheers and thanks for the help

tobi

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi@... ++41 62 775 9902 / sb: -9900
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Questions about building Pango statically & dynamically

2008-09-04T11:58:37Z

On Sep 4, 2008, at 12:33 PM, Behdad Esfahbod wrote:

> Did you try configuring with --with-included-modules?

Thank you! That solved the problems.

Nick Zitzmann
<http://seiryu.home.comcast.net/>
S/MIME signature available upon request

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Questions about building Pango statically & dynamically

2008-09-04T11:33:37Z

Did you try configuring with --with-included-modules?

behdad

Nick Zitzmann wrote:

> Hi:
>
> I've been searching around Google and have found nothing to answer my
> questions, so I'm asking here.
>
> I'm trying to build an LGPL'd framework for Mac OS X, and I want to
> statically link Pango and the ATSUI module into the framework so I don't
> have to distribute them separately. I'm using Pango 1.21.4 and Glib
> 2.17.6, and I'm compiling Pango against the Cairo back-end (not X). And
> I'm running into a few problems:
>
> 1. If I build Pango without shared libraries, then the build succeeds,
> but the pango.modules file is almost empty. OK, so I understand I can
> statically link the ATSUI module into the framework with the Pango
> static library and work around this, but how do I do that?
>
> 2. Searching around for answers to question #1, I came across the
> pango_module_register() function, which apparently manually registers
> modules if statically linked. But when I define PANGO_ENABLE_BACKEND and
> include pango-modules.h, I get the following build errors:
>
> /usr/local/include/pango-1.0/pango/pango-modules.h:38: error: expected
> ')' before '*' token
> /usr/local/include/pango-1.0/pango/pango-modules.h:40: error: expected
> ';' before 'void'
> /usr/local/include/pango-1.0/pango/pango-modules.h:48: error: expected
> '=', ',', ';', 'asm' or '__attribute__' before '*' token
>
> I must be leaving out something, but what? I'm using GCC 4.2 and I'm
> building with the GNU99 dialect. I tried switching dialects to C99, and
> building with GCC 4.0, and there was no improvement in either case.
>
> 3. And finally, I can't get Pango to build at all as a dynamic library.
> When I try, the console gets flooded with messages like these:
>
> (process:11109): GLib-GObject-CRITICAL **: gtype.c:2458: initialization
> assertion failed, use g_type_init() prior to this function
>
> (pango-querymodules:11109): GLib-GObject-WARNING **: cannot retrieve
> class for invalid (unclassed) type `<invalid>'
>
> (pango-querymodules:11109): GLib-GObject-CRITICAL **: g_enum_get_value:
> assertion `G_IS_ENUM_CLASS (enum_class)' failed
>
> (pango-querymodules:11109): Pango-WARNING **: Engine reported invalid
> script value -1
>
> What's going on here? If it helps, my Glib installation is static-only.
>
> Thanks for any advice...
>
> Nick Zitzmann
> <http://seiryu.home.comcast.net/>
> S/MIME signature available upon request
>
>
>
>
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list
>

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Questions about building Pango statically & dynamically

2008-09-04T11:16:16Z

Hi:

I've been searching around Google and have found nothing to answer my
questions, so I'm asking here.

I'm trying to build an LGPL'd framework for Mac OS X, and I want to
statically link Pango and the ATSUI module into the framework so I
don't have to distribute them separately. I'm using Pango 1.21.4 and
Glib 2.17.6, and I'm compiling Pango against the Cairo back-end (not
X). And I'm running into a few problems:

1. If I build Pango without shared libraries, then the build succeeds,
but the pango.modules file is almost empty. OK, so I understand I can
statically link the ATSUI module into the framework with the Pango
static library and work around this, but how do I do that?

2. Searching around for answers to question #1, I came across the
pango_module_register() function, which apparently manually registers
modules if statically linked. But when I define PANGO_ENABLE_BACKEND
and include pango-modules.h, I get the following build errors:

/usr/local/include/pango-1.0/pango/pango-modules.h:38: error: expected
')' before '*' token
/usr/local/include/pango-1.0/pango/pango-modules.h:40: error: expected
';' before 'void'
/usr/local/include/pango-1.0/pango/pango-modules.h:48: error: expected
'=', ',', ';', 'asm' or '__attribute__' before '*' token

I must be leaving out something, but what? I'm using GCC 4.2 and I'm
building with the GNU99 dialect. I tried switching dialects to C99,
and building with GCC 4.0, and there was no improvement in either case.

3. And finally, I can't get Pango to build at all as a dynamic
library. When I try, the console gets flooded with messages like these:

(process:11109): GLib-GObject-CRITICAL **: gtype.c:2458:
initialization assertion failed, use g_type_init() prior to this
function

(pango-querymodules:11109): GLib-GObject-WARNING **: cannot retrieve
class for invalid (unclassed) type `<invalid>'

(pango-querymodules:11109): GLib-GObject-CRITICAL **:
g_enum_get_value: assertion `G_IS_ENUM_CLASS (enum_class)' failed

(pango-querymodules:11109): Pango-WARNING **: Engine reported invalid
script value -1

What's going on here? If it helps, my Glib installation is static-only.

Thanks for any advice...

Nick Zitzmann
<http://seiryu.home.comcast.net/>
S/MIME signature available upon request

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [rrd] Re: pango / fontconfig / cairo performance with rrdtool

2008-09-01T09:17:45Z

Tobias Oetiker wrote:

> Yesterday Behdad Esfahbod wrote:
>
>>
>> Tobias Oetiker wrote:
>>> Behdad,
>>>
>>>> Hi Tobias,
>>>>
>>>> The part creating the layout looks good. Any *interesting* thing will be
>>>> hidden in other parts of the code, namely the code calling this function. In
>>>> general I'm quite surprised that you are hitting the load_fontset() path all
>>>> the time as the fontsets should be cached and simply reused. One way to debug
>>>> it is to run with FC_DEBUG=1 and look for all different Sort Patterns passed
>>>> to fontconfig and see how they differ (I'm guessing minor difference in the size).
>>> I just finished modifying the code, so that I am keeping multiple
>>> sets of PangoFontDescriptions for each combination of font and
>>> size. I then pass the FontDescription into the text function. This
>>> magically resolved the problem ... now the load_fontset gets only
>>> called 3 times or so ...
>>>
>>> Does this match expectations ?
>> Not really. As I said, most probably you have been creating
>> slightly-different font descriptions. You can run the old code and print out
>> the font descriptions to see what has been causing it. In general you should
>> not need to cache much to make Pango behave. Just use the default font map
>> (which you are) and it should work reasonably.
>
> Hmm,
>
> I am using the same font name across the board in 4 different sizes.
>
> DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier 7
> DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier 8
> DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier 9
> DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier 5.5
>
> Is there a way to figure what font pango picked based on my
> description and then tell it to use this one again ?
>
> Could it be that when I ask for font
>
> "ABC,CCD 9"
>
> that pango finds
>
> "CCD 8.99999"
>
> and then when I ask again for
>
> "ABC,CCD 9"
>
> it goes looking again ?

No.

> Could it be that I am doing something that makes pango forget about
> the fonts (flush its cache).

No, unless you:

- Use a different fontmap each time (that is, you use
pango_cairo_font_map_new())

- Call pango_fc_font_map_clear_cache()

- Use more than 64 different font descriptions

none of which you seem to be doing.

> How should I be structuring my program for optimal results.
> Have a separate layout for each font I am going to use and then
> switch layout according to the font ?

Fontsets are cached on the fontmap. Recreating layout and/or font
descriptions should not matter as long as you use the exact same font description.

> As I said, I have shuffled my code around and suddenly the time
> for generating a second graph has gone down dramatically. I just
> don't know exactly why.

Can't tell without closely inspecting your code. But I already suggested how
to debug it further using FC_DEBUG.

> old code:
> 0.221
> 0.158
> 0.152
> 0.157
>
> shuffled code with separate PangoFontDescription structures for
> each font/size which I then apply to the layout as required:
> 0.194
> 0.024
> 0.023
> 0.023
>
> rrd 1.2 code with libart/freetype:
> 0.031
> 0.024
> 0.023
> 0.024

Neat.

behdad

> cheers
> tobi
>
>
>
>
>> behdad
>>
>>> cheers
>>> tobi
>>>
>>>
>>>
>>
>

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [rrd] Re: pango / fontconfig / cairo performance with rrdtool

2008-08-31T16:58:31Z

Yesterday Behdad Esfahbod wrote:

>
>
> Tobias Oetiker wrote:
> > Behdad,
> >
> >> Hi Tobias,
> >>
> >> The part creating the layout looks good. Any *interesting* thing will be
> >> hidden in other parts of the code, namely the code calling this function. In
> >> general I'm quite surprised that you are hitting the load_fontset() path all
> >> the time as the fontsets should be cached and simply reused. One way to debug
> >> it is to run with FC_DEBUG=1 and look for all different Sort Patterns passed
> >> to fontconfig and see how they differ (I'm guessing minor difference in the size).
> >
> > I just finished modifying the code, so that I am keeping multiple
> > sets of PangoFontDescriptions for each combination of font and
> > size. I then pass the FontDescription into the text function. This
> > magically resolved the problem ... now the load_fontset gets only
> > called 3 times or so ...
> >
> > Does this match expectations ?
>
> Not really. As I said, most probably you have been creating
> slightly-different font descriptions. You can run the old code and print out
> the font descriptions to see what has been causing it. In general you should
> not need to cache much to make Pango behave. Just use the default font map
> (which you are) and it should work reasonably.

Hmm,

I am using the same font name across the board in 4 different sizes.

DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier 7
DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier 8
DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier 9
DejaVu Sans Mono,Bitstream Vera Sans Mono,monospace,Courier 5.5

Is there a way to figure what font pango picked based on my
description and then tell it to use this one again ?

Could it be that when I ask for font

"ABC,CCD 9"

that pango finds

"CCD 8.99999"

and then when I ask again for

"ABC,CCD 9"

it goes looking again ?

Could it be that I am doing something that makes pango forget about
the fonts (flush its cache).

How should I be structuring my program for optimal results.
Have a separate layout for each font I am going to use and then
switch layout according to the font ?

As I said, I have shuffled my code around and suddenly the time
for generating a second graph has gone down dramatically. I just
don't know exactly why.

old code:
0.221
0.158
0.152
0.157

shuffled code with separate PangoFontDescription structures for
each font/size which I then apply to the layout as required:
0.194
0.024
0.023
0.023

rrd 1.2 code with libart/freetype:
0.031
0.024
0.023
0.024

cheers
tobi

> behdad
>
> > cheers
> > tobi
> >
> >
> >
>
>

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi@... ++41 62 775 9902 / sb: -9900
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [rrd] Re: pango / fontconfig / cairo performance with rrdtool

2008-08-31T16:17:56Z

Tobias Oetiker wrote:

> Behdad,
>
>> Hi Tobias,
>>
>> The part creating the layout looks good. Any *interesting* thing will be
>> hidden in other parts of the code, namely the code calling this function. In
>> general I'm quite surprised that you are hitting the load_fontset() path all
>> the time as the fontsets should be cached and simply reused. One way to debug
>> it is to run with FC_DEBUG=1 and look for all different Sort Patterns passed
>> to fontconfig and see how they differ (I'm guessing minor difference in the size).
>
> I just finished modifying the code, so that I am keeping multiple
> sets of PangoFontDescriptions for each combination of font and
> size. I then pass the FontDescription into the text function. This
> magically resolved the problem ... now the load_fontset gets only
> called 3 times or so ...
>
> Does this match expectations ?

Not really. As I said, most probably you have been creating
slightly-different font descriptions. You can run the old code and print out
the font descriptions to see what has been causing it. In general you should
not need to cache much to make Pango behave. Just use the default font map
(which you are) and it should work reasonably.

behdad

> cheers
> tobi
>
>
>
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [rrd] Re: pango / fontconfig / cairo performance with rrdtool

2008-08-31T14:19:00Z

Behdad,

> Hi Tobias,
>
> The part creating the layout looks good. Any *interesting* thing will be
> hidden in other parts of the code, namely the code calling this function. In
> general I'm quite surprised that you are hitting the load_fontset() path all
> the time as the fontsets should be cached and simply reused. One way to debug
> it is to run with FC_DEBUG=1 and look for all different Sort Patterns passed
> to fontconfig and see how they differ (I'm guessing minor difference in the size).

I just finished modifying the code, so that I am keeping multiple
sets of PangoFontDescriptions for each combination of font and
size. I then pass the FontDescription into the text function. This
magically resolved the problem ... now the load_fontset gets only
called 3 times or so ...

Does this match expectations ?

cheers
tobi

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi@... ++41 62 775 9902 / sb: -9900
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: pango / fontconfig / cairo performance with rrdtool

2008-08-31T14:08:24Z

Tobias Oetiker wrote:

> Wizards,
>
> A few months back I ported rrdtool (www.rrdtool.org) over from
> libart/freetype to cairo/pango. It all went quite well and the
> resulting graphs look cool. But when it comes to performance things
> look realy bad.
>
> Creating a little test graph with rrdtool 1.2 (libart/freetype)
> takes about 0.01s while the same graph with (cairo/pango) takes
> 0.2s in other words, I am seeing a 20 times slow down. Creating
> several graphs in the same session does not change things much.
>
> I have sat down with callgrind to analyze and found that 80% of the
> time is spend in the
>
> pango_font_map_load_fontset
>
> function. I bet I am doing something terribly wrong here, since I
> use the same font in only 2 sizes all over the graph.
>
> I have based my code on the example in the documentation
> http://developer.gimp.org/api/2.0/pango/pango-Cairo-Rendering.html#rotated-example
> but maybe this is not optimal. I tried to add some caching but it
> did not help much.
>
> I have put a few details up on
>
> http://tobi.oetiker.ch/rrd_pango/
>
> any ideas ?

Hi Tobias,

The part creating the layout looks good. Any *interesting* thing will be
hidden in other parts of the code, namely the code calling this function. In
general I'm quite surprised that you are hitting the load_fontset() path all
the time as the fontsets should be cached and simply reused. One way to debug
it is to run with FC_DEBUG=1 and look for all different Sort Patterns passed
to fontconfig and see how they differ (I'm guessing minor difference in the size).

behdad

> cheers
> tobi
>
>
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

pango / fontconfig / cairo performance with rrdtool

2008-08-31T03:36:02Z

Wizards,

A few months back I ported rrdtool (www.rrdtool.org) over from
libart/freetype to cairo/pango. It all went quite well and the
resulting graphs look cool. But when it comes to performance things
look realy bad.

Creating a little test graph with rrdtool 1.2 (libart/freetype)
takes about 0.01s while the same graph with (cairo/pango) takes
0.2s in other words, I am seeing a 20 times slow down. Creating
several graphs in the same session does not change things much.

I have sat down with callgrind to analyze and found that 80% of the
time is spend in the

pango_font_map_load_fontset

function. I bet I am doing something terribly wrong here, since I
use the same font in only 2 sizes all over the graph.

I have based my code on the example in the documentation
http://developer.gimp.org/api/2.0/pango/pango-Cairo-Rendering.html#rotated-example
but maybe this is not optimal. I tried to add some caching but it
did not help much.

I have put a few details up on

http://tobi.oetiker.ch/rrd_pango/

any ideas ?

cheers
tobi

--
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi@... ++41 62 775 9902 / sb: -9900
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Win32: Pango font problem

2008-08-29T23:15:33Z

I have a problem with Pango in Win32. Consider that I have an initialized variable of type
LOGFONTW. In the following code:

LOGFONTW *LogFont;
// Initialize LogFont
PangoContext *pc = pango_win32_get_context();
PangoFontDescription *font_desc =
pango_win32_font_description_

from_logfontw(LogFont);
pango_context_set_font_description(pc, font_desc);
PangoFont *pf := pango_context_load_font(pc, font_desc);
PangoFontMetrics *fm := pango_font_get_metrics(pf, NULL);

everything is fine until we reach pango_font_get_metrics. It seems that this
function avoids the provided font and resets the font to the default font and returns the metrics of default font.

Could anybody tell me what's wrong here?

Kind regards,
Vahid.

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: adding elastic tabstops to a widget

2008-08-22T11:13:38Z

On Tue, 2008-08-19 at 23:39 +0200, Nick Gravgaard wrote:

> Hi all,
>
> I'm trying to make a proper GTK text editing widget that supports
> elastic tabstops [1] with a view to being able to use it in the near
> future in a PyGTK project (a programmer's text editor), and perhaps one
> day getting it added to GtkTextView or GtkSourceView.
>
> I have something pretty close to being finished. I've developed it by
> hacking the main Pango and GTK code directly rather than making new GTK
> objects that inherit from the standard objects - I figured I'd get the
> functionality working properly before moving the code into new files. It
> consists of 2 parts:
>
> 1. Modified PangoTab structure to contain "width" (distance between tab
> characters) and "contents_width" (width of text between tabs) values,
> instead of "location" (distance from left margin to tab).

[...]

> 2. Modified gtktextview.c (or gtktextlayout.c - not sure which is a
> better place) to get and set PangoTabs' width and contents_width values
> as text is inserted/deleted etc. This makes up most of the code.
[...]

I talked with some with Nick about this yesterday on IRC and wanted to
summarize here.

My personal opinion on the elastic tab idea is that it's quite neat, and
if tabs worked that way, my life would be better. But it's hard for me
to see how to get from the way that tabs work now to the elastic tabs
model ... I wouldn't want to commit code that used elastic tabs to a
public project because then it would be indented weirdly for everybody
who didn't have elastic tabs. So, I think it's better to focus on how we
can make it possible to implement an elastic-tabs editor with
GtkTextView rather than adding the feature itself to GtkTextView.

It turns out that the PangoTab changes are mostly an optimization .. to
be able to use the same structure to set tabs on a PangoLayout as to be
able to store the cached lengths of the different segments of a line.
So, I don't think they are needed in

It also seems that you should mostly be able to do what is needed for
GtkTextView using the public API from a subclass or application. There
is one missing piece:

- You need to be able to tell when parts of the GtkTextView are
revalidated (that is, layout has happpened for those lines.)

Right now, the only way to do this is to get the not-really-public
GtkTextLayout object for the GtkTextView and connect to it's ::changed
signal. This is hackish from C (requires accessing a non-public
structure field), and much more hackish from Python (I gave Nick some
code using ctypes that manages to pull out the GtkTextLayout with some
effort.) And such hacks won't work at all in GTK+ 3.0. So, I think a
::range-validated signal on GtkTextView would be a good addtion.

It also would be useful to have a way of attaching "user data" to a line
of a GtkTextView. (In this case, what you want to store is a cache of
the segment widths for a line.) It is possible to keep a lookaside data
structure in sync with the GtkTextView, but it's a bit awkward and
inefficient.

- Owen

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: adding elastic tabstops to a widget

2008-08-20T11:34:38Z

On Wed, 20 Aug 2008 11:30:56 -0400, "Havoc Pennington" <hp@...>
said:
> Previous thread on this for reference spans three months:
> http://mail.gnome.org/archives/gtk-devel-list/2007-July/msg00046.html
> http://mail.gnome.org/archives/gtk-devel-list/2007-August/msg00086.html
> http://mail.gnome.org/archives/gtk-devel-list/2007-September/msg00088.html
>
> (save everyone else the googling)

Thanks - I should have thought of including those.

I should probably explain that the difference between then and now is
that my new implementation caches the tab structure and width of the
text in each "cell" rather than recalculating it all every time any
change is made to the contents of the buffer (horribly inefficient!).
The old code was more of a proof of concept than a proper
implementation.

Nick
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: On font dialog default sample string selection

2008-08-19T14:43:31Z

2008-08-18 klockan 06:14 skrev Behdad Esfahbod:
> Note that Gtk+ can also use a special translatable string to let translators
> decide what string should be used for their language. Let's call this
> "current locale's preferred sample string".

There's a bunch of sample strings (mostly pangrams) in gnome-specimen
translations.

mvrgr, Wouter

--
:wq mail uws@...
web http://uwstopia.nl

never lived never lived :: i'm in love -- black rebel motorcycle club

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

signature.asc (253 bytes) Download Attachment

adding elastic tabstops to a widget

2008-08-19T14:39:07Z

Hi all,

I'm trying to make a proper GTK text editing widget that supports
elastic tabstops [1] with a view to being able to use it in the near
future in a PyGTK project (a programmer's text editor), and perhaps one
day getting it added to GtkTextView or GtkSourceView.

I have something pretty close to being finished. I've developed it by
hacking the main Pango and GTK code directly rather than making new GTK
objects that inherit from the standard objects - I figured I'd get the
functionality working properly before moving the code into new files. It
consists of 2 parts:

1. Modified PangoTab structure to contain "width" (distance between tab
characters) and "contents_width" (width of text between tabs) values,
instead of "location" (distance from left margin to tab). Changed
"get_tab_pos" function in pango-layout.c to accumulate "width"s leading
up to and including a given index, instead of returning the "location"
for that index. This allows programs to just change one cell's width
without getting every leading cell's location and changing the location
of every subsequent cell on that line (IMO this makes the API easier to
use regardless of the elastic tabstop functionality), as well as letting
my elastic tabstop code cache the widths of the text betwen cells for
performance reasons (I don't want to have to recalculate it for
potentially many lines every time a character is inserted/deleted).
Note: with a bit of work I suspect my contents_width cache values could
also be used to improve the performance of conventional tabstops.

2. Modified gtktextview.c (or gtktextlayout.c - not sure which is a
better place) to get and set PangoTabs' width and contents_width values
as text is inserted/deleted etc. This makes up most of the code.

So, my questions are:

What do I do next given my goals of being able to use this stuff in a
PyGTK project and perhaps one day getting it added to GTK proper?

and

How do I make an object which inherits it's functionality from, say,
GtkSourceView, adds my functionality described in point 2 above, and
uses my modified PangoTab structure and pango-layout functionality
described in point 1?

Thanks,
Nick

[1]
http://nickgravgaard.com/elastictabstops
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

On font dialog default sample string selection

2008-08-17T21:14:54Z

[CC'ing gtk-i18n-list]

Henrique Carvalho Alves wrote:

> 2008/8/17 Henrique Carvalho Alves <hcarvalhoalves@...>:
>> 2008/8/17 Sven Neumann <sven@...>:
>>> Using the font name for preview does not work. You could try to add some
>>> heuristics that select a reasonable text depending on font coverage. But
>>> that is likely going to fail in some corner cases. So whatever you end
>>> up doing, you should give the user a way to change the text used for
>>> preview.
>>>
>>> Sven
>>>
>> You're right. The current font dialog also fails for that (see Ubuntu,
>> which ships some fonts for other languages, and the preview just
>> presents a default "abcdABCDE" text in sans). I too guess finding the
>> glyph coverage for the font is hard and not reliable. As stated on the
>> last reply, making the preview editable is better, of course. The
>> question here: is using the font name and size as preview text a
>> better default?

The text should be editable, sure.

It's still useful to have a better default preview text. It may also be
useful to have a drop down of some other preset texts the font supports.

For preset texts, there's a lot around:

- For Latin: The quick brown... [1], abcd..., "Hamburgfonts" [2], Lorem
ipsum [3],

- Font samples for other lagnauges [4]

- Pangrams for other languages [5],

- When no languages are available, "I can eat glass" [6]

In fact, these can go right in Pango. There's already API for that:
pango_language_get_sample_string(). There's a bug to make that more useful
[7]. I may have been motivated now to fix that for tomorrow's release.

Note that Gtk+ can also use a special translatable string to let translators
decide what string should be used for their language. Let's call this
"current locale's preferred sample string".

I have also added API to Pango already to be able to tell if a font can render
a particular string. Just turn fallback off in your layout
(pango_attr_fallback_new()), then use pango_layout_get_unknown_glyphs_count()
and divide that by the number of characters in the string.

Next is to decide which language to show by default, and which ones to show in
the drop down. Here's what I propose:

- If the font can render the current locale's preferred sample string, that
should be the default, otherwise pick one of the supported strings
arbitrarily. For bonus, prefer those that use scripts other than Latin.
Among those, take one that uses the PangoScript with smaller/larger value,
depending on whether you want to promote common or exotic languages :P.

- To the list add all strings that can be rendered by the font. If the
Pango fontmap being used is not a PangoFcFontMap, simply add the Latin ones
(other than the current locale's preferred sample string that is). If it is a
PangoFcFontMap:

* Get a PangoFont of the font at hand (simply use any string and fallbacks
off)

* Get the "pattern" GObject property of the PangoFont (which actually is a
PangoFcFont) which is a FcPattern *. Note that this fails with older Pango
versions, so be prepared for handling that.

* Fetch all the FC_LANG elements of the pattern.

* For all those languages, use pango_language_get_sample_string() and add
them. Note that that function returns a junk string if it doesn't know about
the language. This can be detected by comparing the return value to that of
pango_language_get_sample_string(pango_lanugage_from_string ("xx")).

That's all. I don't mind jumping in and implementing this when someone has a
patch against GTK+ to use the right widget there.

behdad

[1] http://en.wikipedia.org/wiki/The_quick_brown_fox_jumps_over_the_lazy_dog
[2] http://en.wikipedia.org/wiki/Hamburgefonts
[3] http://en.wikipedia.org/wiki/Lorem_ipsum
[4] http://en.wikipedia.org/wiki/Sample_Font_Displays_In_Other_Languages
[5] http://en.wikipedia.org/wiki/List_of_pangrams#Other_languages
[6] http://svn.gnome.org/viewvc/pango/trunk/pango-view/GLASS.txt?view=markup
[7] http://bugzilla.gnome.org/show_bug.cgi?id=473806

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

cairo 1.8 and pango 1.22 and GNOME 2.24

2008-08-13T12:07:27Z

Hi,

It was pointed that my cairo 1.7.2 release mail was not very clear about
the timing. Just a clarification that cairo 1.8 WILL be released before
pango 1.22, which WILL be released before GNOME 2.24 tarballs due date.

Also, pango 1.22 will REQUIRE cairo 1.8.

That's all,

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

Re: Pango-1.21.4 released [unstable]

2008-08-13T11:21:58Z

Alexander Jones wrote:
> Still no RGBA colours... or opacity attributes :(

Bugs need to be discussed on bugzilla and a solution found before fixes
magically appearing in next release. I still have no definite solution to this.

http://bugzilla.gnome.org/show_bug.cgi?id=413941

Though I'm getting some better ideas, in the context of attribute extension
APIs I like to add:

http://bugzilla.gnome.org/show_bug.cgi?id=511130

However, this just proves that the flat attribute inheritance I propose
there is suboptimal.

behdad

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Pango-1.21.4 released [unstable]

2008-08-11T16:58:08Z

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pango-1.21.4 is now available for download at:

http://download.gnome.org/sources/pango/1.21/
or
ftp://ftp.gtk.org/pub/pango/1.21

75f8dea346a160f8f45c47cd30e6ab3b pango-1.21.4.tar.bz2
3a12cb5a7f2dc562aab415d764810f4e pango-1.21.4.tar.gz

I figured Vincent is at Akademy busy distracting the KDE folks from
hacking, so I thought I may sneak in some last-minute API additions
while he's not paying attention. All the additions are pretty
straightforward. The more complex ones (supporting application fonts)
did not make it this time around and so are pushed forward for the next
Pango stable series :(.

Notes:

* This is unstable development release. While it has had
fairly extensive testing, there are likely bugs
remaining to be found. This release should not be used
in production.

* Installing this version will overwrite your existing
copy of Pango. If you have problems, you'll need
to reinstall Pango-1.20.x

* Bugs should be reported to http://bugzilla.gnome.org.

About Pango
===========

Pango is a library for layout and rendering of text, with an emphasis
on internationalization. Pango can be used anywhere that text layout
is needed, though most of the work on Pango so far has been done in
the context of the GTK+ widget toolkit. Pango forms the core of text
and font handling for GTK+-2.x.

Pango is designed to be modular; the core Pango layout engine can
be used with different font backends. There are three basic backends,
with multiple options for rendering with each.

- Client side fonts using the FreeType and fontconfig libraries.
Rendering can be with with Cairo or Xft libraries, or directly
to an in-memory buffer with no additional libraries.

- Native fonts on Microsoft Windows using Uniscribe for
complex-text handling. Rendering can be done via Cairo or
directly using the native Win32 API.

- Native fonts on MacOS X, rendering via Cairo.

The integration of Pango with Cairo (http://cairographics.org)
provides a complete solution with high quality text handling
and graphics rendering.

Dynamically loaded modules then handle text layout for particular
combinations of script and font backend. Pango ships with a wide
selection of modules, including modules for Hebrew, Arabic,
Hangul, Thai, and a number of Indic scripts. Virtually all of the
world's major scripts are supported.

As well as the low level layout rendering routines, Pango includes
PangoLayout, a high level driver for laying out entire blocks of text,
and routines to assist in editing internationalized text.

More information about Pango is available from http://www.pango.org/.
Bugs should be reported to http://bugzilla.gnome.org.

Pango 1.21.4 depends on version 2.17.3 or newer of the GLib
library and version 1.7.4 or newer of the cairo library (if the
cairo backend is desired); more information about GLib and cairo
can be found at http://www.gtk.org/ and http://cairographics.org/
respectively.

Overview of changes between 1.21.3 and 1.21.4
=============================================
- - Use cairo_show_text_glyphs() if target cairo surface supports that.
This is done by adding a new PangoRenderer method, draw_glyph_item().
Custom PangoRenderer implementations that delegate to pango_cairo
may want to implement this method if they target PDF files.
- - Requires cairo >= 1.7.4 now
- - Win32 build improvements
- - Justify lines broken by U+2028 LINE SEPARATOR
- - Various small fixes and improvements
- - New API additions:

New public API:

PangoRenderer::draw_glyph_item()
pango_renderer_draw_glyph_item()

Make layout and layout-line default renderers go through
draw_glyph_item(), which then by default falls back to
draw_glyphs(). The advantage in draw_glyph_item() is that it
has access to the text and cluster information.

New public API, for iterating a PangoGlyphItem:

PangoGlyphItemIter
PANGO_TYPE_GLYPH_ITEM_ITER
pango_glyph_item_iter_copy()
pango_glyph_item_iter_free()
pango_glyph_item_iter_init_start()
pango_glyph_item_iter_init_end()
pango_glyph_item_iter_next_cluster()
pango_glyph_item_iter_prev_cluster()

Make the following previously backend-only API public:

pango_context_new()
pango_context_set_font_map()

This also means that bindings are recommended to allow
instantiation of pango.Context. This was discouraged before.

New public API:

pango_font_map_create_context()

This is equivalent to pango_context_new() followed by an
immediate pango_context_set_font_map(). This change also
deprecates various per-fontmap-type context constructors:

Deprecate pango_cairo_font_map_create_context().
Deprecate pango_fc_font_map_create_context().
Deprecate pango_ft2_font_map_create_context().
Deprecate pango_win32_get_context().
Deprecate pango_xft_get_context().
Deprecate pango_x_get_context().

Language bindings are encouraged to bind
pango.Fontmap.create_context() and remove the create_context()
method from subclass implementations.

- - Bugs fixed in this release:
Bug 547303 – pango_layout_get_cursor_pos crashes on certain text
buffers
Fedora Bug 457883 - Sindhi Characters are not supported in
pango [U+097B-U+097F]
Patch from Pravin Satpute
Bug 441654 – prefix fails when more than one base characters (as
conjuncts) present after a half form the next prefix renders
incorrectly
Patch from Rahul Bhalerao
Bug 546534 – pango_cairo_font_map_set_default(NULL) errs
Bug 431394 – Use pango_glyph_item_iter in more places
Bug 377948 – Make pango_glyph_item_iter public
Bug 472625 – Add draw_glyph_item() to PangoRenderer
Bug 540592 – Crash in HB_GSUB_Apply_String with Linux-Libertine font
Bug 540036 – Doesn't link to fontconfig
Bug 380094 – Fix split matra rendering bug for Kannada language
Bug 536017 – Remove SF_MPRE_FIXUP from Sinhala script flags
Patch by Harshula

11 August 2008
Behdad Esfahbod
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkig0g8ACgkQn+4E5dNTERV+yQCfb3b+JHGACR6AUZOAXH1auMEU
qu4Anj5MvfsrEPTsvHGl9O/XzCuicrju
=+b5H
-----END PGP SIGNATURE-----
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: pango-view and libpangoft dependencies

2008-07-29T20:57:36Z

On Jul 28, 2008, at 11:10, Julien Palmas wrote:

> I'm trying to build pango 1.21.3 on my Mac OS X 10.5 box.
>
> I get a build error like this one :
>
> mv -f .deps/viewer-pangocairo.Tpo .deps/viewer-pangocairo.Po
> make[3]: *** No rule to make target `../pango/libpangoft2-1.0.la',
> needed by `pango-view'. Stop.
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> Looks like a rule is missing.
>
> Can anyone help me on this ?

I don't see a problem building pango 1.21.3 on Mac OS X 10.4.11 with
Xcode 2.5 or on Mac OS X 10.5.4 with Xcode 3.1, both on Intel Macs.

I added a port pango-devel to MacPorts to build this version of
pango. You could install MacPorts and then see if that portfile works
for you (by typing "sudo port install pango-devel").

http://www.macports.org/

Or if you especially want to compile it yourself, you can look at the
portfile here to see how I did it:

http://trac.macports.org/browser/trunk/dports/x11/pango-devel/Portfile

Though I'm not doing anything particularly special so I'm not sure
why it's failing for you.

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

pango-view and libpangoft dependencies

2008-07-28T09:10:18Z

Hi,

I'm trying to build pango 1.21.3 on my Mac OS X 10.5 box.

I get a build error like this one :

mv -f .deps/viewer-pangocairo.Tpo .deps/viewer-pangocairo.Po
make[3]: *** No rule to make target `../pango/libpangoft2-1.0.la',
needed by `pango-view'. Stop.
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

Looks like a rule is missing.

Can anyone help me on this ?

Thx
Julien
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: Status of support for Romanian

2008-07-18T12:39:27Z

Here's a short "appendix". I did a quick test in Open Office since
it doesn't use pango but ICU (as far as I know). It's less impressive than
Pango:

* No support for GSUB/latn/ROM/locl (or ccmp). I guess it needs a special
CTL (Complex text layout) module for Romanian, but I don't think there
is any.

* Fonts steal glyphs from similar fonts, but sometimes luck out and seem
to choose inappropriately (sans replaces serif). Here is a little demo:
http://www.cs.umd.edu/~gaburici/oo-ro-font-test.tgz. I cannot find a way
to turn off fallback substitution either.

I guess this stuff is mostly Sun's problem, but if you have any comments...

Thanks,
Vasile

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Status of support for Romanian

2008-07-18T11:53:52Z

The text below is also part of the archive with code and images available
at: http://www.cs.umd.edu/~gaburici/ro-fonts-test.tgz

Here is the summary of the tests (as of July 18, 2008 on Fedora 9):

== Quickie 1: Test for Unicode code points relevant for Romanian ==

Issues (and suggested fixes):

* All PS1 (non-OTF) fonts need an additional mapping from 021A/B to
U+162/3.

Background: Most PS1 fonts (not OpenType) that ship with Linux distorts
lack the code points U+21A/B (t with comma below) which is the proper
code point for Romanian t with comma below. Thankfully, Adobe once
decided that t with cedilla is not used in any language so the proper
glyphs are usually present at U+162/3, which used to be the unified code
point for t cedilla and t comma below before Unicode 3.0. The Uniscribe
renderer automatically handles this issue by remapping U+21A/B to
U+162/3 when the former glyphs are missing. Unfortunately,
Pango/fonconfig doesn't do this, so most new Romanian documents can only
be displayed with a very narrow font selection.

Proposed solution: adopt Uniscribe solution; editing the PS1 fonts is
pointless and would violate the license for the commercial ones.

* Liberation fonts lack "s with comma" completely -- the glyph needs to be
added to the fonts. Hopefully, they'll be made into OT fonts at the same
time (see further discussion why this would be good). "T with comma" can
be copied from U+162/3.

== Quickie 2: Test for localized OT forms (GSUB/latn/ROM/{locl,ccmp}) ==

The Adobe/Linotype/Vista industry standard seems to that activating
ROM/locl should map "s with cedilla" to "s with comma". Since in Adobe
(Pro) OT fonts U+162/3 is by default mapped to "t with comma", activating
this optional mapping for s renders old, pre-Unicode 3.0 Romanian texts
with comma below both s and t. Thankfully Pango already handles this!

Funny enough, the MS Uniscribe from XP SP 3 doesn't turn ROM/locl for
Romanian locale (or at least I don't know how to convince it).

The OT SIL fonts take a slightly different approach, but work with Pango
nonetheless. First, they have proper cedilla variants for both s and t.
Second, they don't have a ROM/locl feature, but a ROM/ccmp feature which
remaps both cedilla variants to comma-below counterparts. I'm not sure
this approach is entirely correct because the OpenType spec on MS.com says
that ccmp should not be language sensitive. YMMV, I'm no expert on this.
[http://www.microsoft.com/typography/OTSPEC/features_ae.htm#ccmp]

Issues (and suggested fixes):

* DejaVu fonts (which are already OT), do not have a ROM/locl feature.
From what I've seen on typophile.com this is a two line fix in fontlab.

* Pango does not allow an application to set the OT features language
independently from UI language. For instance, there's currently no way
to run gedit with the English UI but to force Romanian localized rendering
for U+015E/F, which is silly because those code points mean nothing in
English. Hopefully somebody there will grok it. See my comments on the
Pango bug at http://bugzilla.gnome.org/show_bug.cgi?id=442786.

Finally, if this doesn't make any sense to you, there's some further
background info on the Wikipedia page for the Romanian alphabet.

Much ado for some commas ;)
Vasile

P.S. The Linux console fonts also lack U+219-B code points, but few care
about the console fonts these days...
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: pango doesn't render non-Latin characters with cairo-quartz-font

2008-07-16T06:59:35Z

On Tue, 2008-07-15 at 06:19 -0500, Ryan Schmidt wrote:
> I posed this question on July 3 and nobody responded. I also asked
> the cairo list on July 6 and nobody answered there either. Can anyone
> give me any guidance about how to deal with this issue?

If no one replied, chances are no one can give you any guidance about
how to deal with this issue. At some point someone needs to dig into
the code, and that someone is not easy to find because of the
platform-specific nature of your issue.

I'm also surprised how that neither your report nor the "detailed bug
report" even mention what kind of "issues" it's showing. No
screenshots.

behdad

> On Jul 3, 2008, at 00:35, Ryan Schmidt wrote:
>
> > Hello. I maintain cairo and pango in MacPorts, and I have a report
> > from a user that when cairo-quartz-font is in use, pango doesn't
> > render non-Latin characters (Chinese, Japanese, Korean, Thai,
> > Tibetan). When cairo-quartz-font is turned off (i.e. when cairo-
> > quartz-font.pc is deleted and pango is rebuilt), these characters
> > show up.
> >
> > The reporter was using Mac OS X 10.5.x (Leopard) with cairo 1.6.4
> > and pango 1.20.3. I can confirm the issue with Mac OS X 10.4.11
> > (Tiger) on Intel with cairo 1.6.4 and pango 1.20.5.
> >
> > Here is the detailed bug report that was filed with MacPorts:
> >
> > http://trac.macports.org/ticket/15626
> >
> > I don't know if this is a cairo bug or a pango bug. I thought I'd
> > start by asking the pango list. Please let me know if you think I
> > should ask the cairo list instead. Thanks.
>
>
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

--
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: [gtk-i18n-list] Re: pango doesn't render non-Latin characters with cairo-quartz-font

2008-07-15T04:45:41Z

Hi,

I'm interested in this issue. Until 2008-07-28, I don't
have sufficient time to reproduce the bug. If nobody
works for the bug until the day, I will try to analyze
the bug.

Regards,
mpsuzuki

On Tue, 15 Jul 2008 06:19:12 -0500
Ryan Schmidt <pango-2008c@...> wrote:

>I posed this question on July 3 and nobody responded. I also asked
>the cairo list on July 6 and nobody answered there either. Can anyone
>give me any guidance about how to deal with this issue?
>
>
>On Jul 3, 2008, at 00:35, Ryan Schmidt wrote:
>
>> Hello. I maintain cairo and pango in MacPorts, and I have a report
>> from a user that when cairo-quartz-font is in use, pango doesn't
>> render non-Latin characters (Chinese, Japanese, Korean, Thai,
>> Tibetan). When cairo-quartz-font is turned off (i.e. when cairo-
>> quartz-font.pc is deleted and pango is rebuilt), these characters
>> show up.
>>
>> The reporter was using Mac OS X 10.5.x (Leopard) with cairo 1.6.4
>> and pango 1.20.3. I can confirm the issue with Mac OS X 10.4.11
>> (Tiger) on Intel with cairo 1.6.4 and pango 1.20.5.
>>
>> Here is the detailed bug report that was filed with MacPorts:
>>
>> http://trac.macports.org/ticket/15626
>>
>> I don't know if this is a cairo bug or a pango bug. I thought I'd
>> start by asking the pango list. Please let me know if you think I
>> should ask the cairo list instead. Thanks.
>
>
>_______________________________________________
>gtk-i18n-list mailing list
>gtk-i18n-list@...
>http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: pango doesn't render non-Latin characters with cairo-quartz-font

2008-07-15T04:19:12Z

I posed this question on July 3 and nobody responded. I also asked
the cairo list on July 6 and nobody answered there either. Can anyone
give me any guidance about how to deal with this issue?

On Jul 3, 2008, at 00:35, Ryan Schmidt wrote:

> Hello. I maintain cairo and pango in MacPorts, and I have a report
> from a user that when cairo-quartz-font is in use, pango doesn't
> render non-Latin characters (Chinese, Japanese, Korean, Thai,
> Tibetan). When cairo-quartz-font is turned off (i.e. when cairo-
> quartz-font.pc is deleted and pango is rebuilt), these characters
> show up.
>
> The reporter was using Mac OS X 10.5.x (Leopard) with cairo 1.6.4
> and pango 1.20.3. I can confirm the issue with Mac OS X 10.4.11
> (Tiger) on Intel with cairo 1.6.4 and pango 1.20.5.
>
> Here is the detailed bug report that was filed with MacPorts:
>
> http://trac.macports.org/ticket/15626
>
> I don't know if this is a cairo bug or a pango bug. I thought I'd
> start by asking the pango list. Please let me know if you think I
> should ask the cairo list instead. Thanks.

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: pangp on cygwin

2008-07-05T10:56:24Z

> I apologize for not being an expert but I really want to get this working on my CYGWIN_NT-5.1 1.5.25 platform.

Sorry for asking, but why not just run real Linux instead, either in a
virtual machine, or separate machine? I can understand using Cygwin to
run non-GUI applications like build tools etc (I do it myself all the
time, both MSYS which is technically a fork of MSYS and "real"
Cygwin). But to me running an X11 server, and X11 clients using a
toolkit like GTK+, on top of Cygwin seems somewhat odd. Is the use
case to work around a boneheaded IT department that won't allow
running Linux, but doesn't object to running Cygwin?

--tml
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: pangp build bug on cygwin

2008-07-05T10:37:18Z

Please file a bug report at bugzilla.gnome.org and attach the patch in
unified diff format.

--tml
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Pango support for Opentype

2008-07-05T08:36:51Z

Hi all,

I'm one of the Myanmar/Burma font developer for burmese script.
I would like to know, current Pango support status for Opentype.
If opentype is supported, I would like to know for which pango revision is supported for Unicode specification. The latest is Unicode 5.1.

Thanks and Regards,

Victor San Kho Lin
www.unimm.org

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: OpenType and font-variant support

2008-07-03T13:03:24Z

On Thu, 2008-07-03 at 19:57 +0000, Steven Robertson wrote:
>
> I'd love to help in getting that last piece in place.

I probably give it a shot next week at GUADEC.

> > http://bugzilla.gnome.org/show_bug.cgi?id=439298
>
> I filed a similar bug against HarfBuzz. Apologies for not checking in
> Pango's issue tracker first; since the bug was in the lower-level
> library I didn't think to check Pango as well.

Thanks fine.

> https://bugs.freedesktop.org/show_bug.cgi?id=16580
>
> Much of the proposal in the second email was designed to deal with the
> improper ordering of features described in those bug reports. If the
> bugs can be closed, then the complexities described in the second
> email (written before I had learned of this bug) largely vanish.

Yeah. I need to make some changes to PangoOTRuleset to allow applying
features in stages. Something like a features tag of "\0\0\0\0" for
example. Nothing hard.

> I'm very interested in getting this feature implemented in Inkscape,
> and of course that process starts with Pango. Let me know how I can
> help.

You can monitor the bugs. I make note there when I make progress.

> Steven
>
--
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: OpenType and font-variant support

2008-07-03T12:57:50Z

On Thu, Jul 3, 2008 at 7:15 PM, Behdad Esfahbod <behdad@...> wrote:
> Pango already has infrastructure in place to apply arbitrary OpenType
> features. The only missing piece is a PangoAttribute for them.

I'd love to help in getting that last piece in place.

> http://bugzilla.gnome.org/show_bug.cgi?id=439298

I filed a similar bug against HarfBuzz. Apologies for not checking in
Pango's issue tracker first; since the bug was in the lower-level
library I didn't think to check Pango as well.

https://bugs.freedesktop.org/show_bug.cgi?id=16580

Much of the proposal in the second email was designed to deal with the
improper ordering of features described in those bug reports. If the
bugs can be closed, then the complexities described in the second
email (written before I had learned of this bug) largely vanish.

I'm very interested in getting this feature implemented in Inkscape,
and of course that process starts with Pango. Let me know how I can
help.

Steven
_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

Re: OpenType and font-variant support

2008-07-03T12:15:07Z

Pango already has infrastructure in place to apply arbitrary OpenType
features. The only missing piece is a PangoAttribute for them. See:

http://bugzilla.gnome.org/show_bug.cgi?id=460831

Also:

http://bugzilla.gnome.org/show_bug.cgi?id=439298

behdad

On Mon, 2008-06-30 at 00:30 +0000, Steven Robertson wrote:

> On second thought...
>
> After exploring the code and specifications more thoroughly, I
> realized that the proposal in the previous mail is naive and not
> backwards-compatible. Kindly ignore most of it.
>
> I'd like to get comments on the issues and ideas I've had since
> gaining a deeper understanding of the interaction between Pango and
> OpenType. I imagine that these points are obvious to Pango's
> developers, but it is useful to state them for those less familiar
> with the potential pitfalls.
>
> --
>
> There are, in my opinion, far too many distinct published OpenType
> feature tags to explicitly support each one with its own boolean
> property. Even a comma-separated list of humanized names, as
> suggested previously, is insufficient, not only for reasons of size
> but also because the order is critical in some cases (ex: applying
> 'liga' before 'smcp' means that common ligatures, like ffi and Th,
> contain regular lower-case letters instead of small capitals). This
> would be unpleasant to maintain.
>
> On the other hand, simply providing direct access to the lists of
> enabled GSUB and GPOS tags poses too much implementation work for most
> of Pango's users. This is because different shape engines have
> different sets of default parameters, so writing code for a check-box
> that says "Small Caps" goes from a couple lines to dozens. With such
> a design, applications can very easily make changes that will disrupt
> the default settings, which isn't so bad for Latin scripts but is
> unacceptable for others. This solution is too prone to failure,
> especially considering that the most intrusive bugs may only show up
> in a language other than the developer's native one.
>
> Picking and choosing which OpenType features to support also seems
> like headaches in the making. I imagine a number of "You support X,
> why don't you support Y" issues popping up as a result of that, which
> will either persist ad nauseum or result in piecemeal adoption of an
> excessive number of tables.
>
> One final problem is worth noting. Consider a hierarchical document
> of some sort, where font attributes can be inherited from a parent
> element. (HTML, SVG, even ODT and Word do this.) Every existing
> attribute (at the Pango level) can either be inherited, or it can be
> overridden, but not both; for example, you cannot set font-size to
> "larger" at the Pango level, because Pango does not understand a
> document's hierarchy. This is fine for existing attributes, because
> it isn't much work for a document engine to keep track of hierarchy
> for properties with only one value. However, it must be kept in mind
> when implementing any property that takes the form of a list. If I
> have a text segment in a document which uses 'tnum' (tabular figures),
> and I wish to set a line with 'smcp' (small capitals), the program
> will have to somehow combine the 'tnum' flag with the 'smcp' flag. It
> is important that this process be as simple as possible to accomplish
> programmatically, and ideally should require no knowledge of OpenType.
>
> --
>
> At this time, I believe that a hybrid between the two models is the
> wisest choice. This hybrid would require the addition of two
> attributes to Pango's library, which for the sake of discussion I will
> call 'ot_features' and 'ot_tags'. Also for the sake of discussion,
> consider a font which supports the 'kern', 'liga', and 'smcp' features
> (kerning, default ligatures, and small capitals, respectively), and
> assume that the 'kern' and 'liga' features are on by default.
>
> ot_tags is a string-based property which allows more-or-less raw
> access to the list of OpenType Layout tags that will be enabled for a
> text segment. The argument takes the form of a comma-separated list;
> each item on the list can either be a tag, such as 'smcp', to append a
> feature to the list of those to be enabled, or a tag prefixed with a
> hyphen, as in '-liga', to remove that feature from the list. This
> allows a developer to get as technical as he or she needs to without
> requiring knowledge or code pertaining to any other tags (or scripts).
> For example, as mentioned above, the substitutions specified by
> 'smcp' must come before those specified by 'liga', but 'liga' is in
> the set of default options, so 'smcp' will always come after 'liga'.
> Setting ot_tags="-liga,smcp,liga" ensures proper operation. Another
> incentive of this method of setting individual tags is that
> inheritance is as simple as concatenation, making implementing it in
> applications and Pango-based toolkits a snap.
>
> ot_features is a list of which of the most commonly-used OpenType
> features to enable; by default, no features will be shown as enabled
> in this list (implying that features like kerning, which are always
> enabled by default, will not be in this list). While the mapping of
> ot_features to OpenType feature tags is usually one-to-one, some
> instances (like for small caps) require reordering or disabling of
> mutually-exclusive tags; this will be accomplished in the same way as
> those for ot_tags - in fact, setting ot_features may actually update
> ot_tags to ensure consistency. ot_features should probably be a
> bitfield to keep it simple, and the items it supports would be derived
> from a look at which OpenType features are most commonly exposed in
> applications.
>
> --
>
> The two properties mentioned above, while considerably more feasible
> than reusing 'variant', do still suffer from a few limitations.
> Foremost among these is a lack of any way to determine the OpenType
> Layout tags that are available and enabled by default for a particular
> font or script. While this information isn't necessary to accomplish
> most tasks programmatically, it is important for UI feedback in many
> applications. An associated problem is that the information for tags
> enabled by default isn't available until the script and text direction
> (vertical or horizontal) is known. I do not yet have a solution in
> mind, but I'll keep looking into it.
>
> Thanks,
> Steven
> _______________________________________________
> gtk-i18n-list mailing list
> gtk-i18n-list@...
> http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

pango doesn't render non-Latin characters with cairo-quartz-font

2008-07-02T22:35:10Z

Hello. I maintain cairo and pango in MacPorts, and I have a report
from a user that when cairo-quartz-font is in use, pango doesn't
render non-Latin characters (Chinese, Japanese, Korean, Thai,
Tibetan). When cairo-quartz-font is turned off (i.e. when cairo-
quartz-font.pc is deleted and pango is rebuilt), these characters
show up.

The reporter was using Mac OS X 10.5.x (Leopard) with cairo 1.6.4 and
pango 1.20.3. I can confirm the issue with Mac OS X 10.4.11 (Tiger)
on Intel with cairo 1.6.4 and pango 1.20.5.

Here is the detailed bug report that was filed with MacPorts:

http://trac.macports.org/ticket/15626

I don't know if this is a cairo bug or a pango bug. I thought I'd
start by asking the pango list. Please let me know if you think I
should ask the cairo list instead. Thanks.

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list

fontconfig "preferred" families and where to get more information

2008-07-02T12:28:04Z

The fontconfig configuration files 60-latin.conf, 65-nonlatin.conf, and several others contain lists of preferred font families broken down by serif, sans-serif, and monospace. Since there are therefore several lists of preferred sans-serif families, how are these different lists applied when a font description of say "sans 12" is used? We have lots of cases of English mixed with Eastern languages, so I would like to really understand this.

That's one specific question. More generally, does anyone know a book (or other information source) that goes into real detail on the fontconfig system from a user perspective? The so-called "User's Manual" on the fontconfig website is a joke.

_______________________________________________
gtk-i18n-list mailing list
gtk-i18n-list@...
http://mail.gnome.org/mailman/listinfo/gtk-i18n-list