Re: Extending pango markup

(finally got time to continue this...)

On 4/9/06, Behdad Esfahbod <behdad cs toronto edu> wrote:
> Hi,
> I certainly don't like the way your patch works.

Given that it indeed was the quick-and-dirty hack to see if it would
be feasible at all, I'd hate you if you _did_ like it. ;)

>  What I like
> instead is a way to get/set GMarkup markup-parser and data on
> your PangoLayout.  Then you can get the current parser and data,
> embed them into your own data, and set your own parser and data
> that will fallback to Pango's parser/data for tags it doesn't
> like...

Hmm, not sure if I get this right but wouldn't this be almost like
repimplementing the whole markup parsing in every application with the
only convenience being the parsing of existing tags (so you'd have to
keep track of the indexes etc. yourself)?

> This should let you do what you want, but doesn't allow
> implementing arbitrary markup parsers, as it doesn't expose the
> MarkupData struct (and it really shouldn't.)

I agree here.

>  Another approach is
> to go one step further and make the markup-parser paroperty take
> a function with similar signature as pango_parse_markup and data
> so you don't even have to use GMarkup (and GMarkup is not in the
> Pango API currently.)  But then you cannot do what you currently
> want to do.  Something in between should be possible, I'm not
> sure.

Basically what I'm looking for is a way to say to pango "if this tag
is present when you parse the markup, please ask me if I want to apply
attributes to that location".

What about having an "unkown tag" callback to a
pango_parse_markup()-sibling that would simply give the tag name and
attributes as parameter to the callback and that callback would return
a list of attributes to be applied for the enclosed text? Possibly
you'd want a user data parameter too there...

My concern with full-featured parsing support is that it easily gets
too heavy to use when compared to some lazy hacking (and we all know
what people are like when doing it Right gets too complicated... ;).

Kalle Vahlman, zuh iki fi
Powered by
Interesting stuff at

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]