Re: Extending pango markup

[Behdad Esfahbod <behdad cs toronto edu>]

Hi,

I certainly don't like the way your patch works.  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...

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.)  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.


behdad


On Fri, 7 Apr 2006, Kalle Vahlman wrote:

> Hi!
>
> Ever since I decided I'd use a markup tag in my widgets[1] for
> activatable text and embedding icons, I've been suffering from my
> crappy C-string foo. I just don't seem to get it right with C, but the
> reason for that could be motivational too ;)
>
> The idea is to take a string with markup and replace the tags with
> attributes (both standard pango and custom attributes), but my code is
> currently far from robust.
>
> The other problem with parsing the tags is that it gets very tricky
> since you need to do it before parsing the string with pango (since
> it'll choke on the custom tags) and thus you need to keep track of the
> attribute indexes by hand so that you know where to apply them after
> the markup tags are gone.
>
> This made me really want to have the possibility to extend the pango
> markup language so that I could register my tags there with a handler
> and have it "just work". So I poked at it and found out that extending
> pango markup would not be too hard to implement.
>
> The attached patch is a quick stab at it to start the conversation. It
> seems to work and was trivial to use (when compared to  the hack I had
> to produce earlier :).
>
> What I did was:
>
>  - move the MarkupData and OpenTag to a public header
>  - ditto for the TagParseFunc type
>  - create a pango_markup_register_tag(tag_name, TagParseFunc) function
>
> So I could simply create a function matching the TagParseFunc
> signature  and call the register_tag with the tag name and function.
> Internally, the registering happens to a hash table from which the tag
> names are looked up if they don't match the builtin ones.
>
> I'm not sure if the MarkupData or OpenTag really offer things that
> should be available for applications. If not, they could be wrapped
> away with another function which would just offer the attribute list.
> But I guess this would depend on the use cases for the extended tags.
> For my particular uses, simply adding the attributes is enough.
>
> Overriding the builtin tags should not be allowed in my opinion, nor
> would queuing old tag handlers really be useful (as the scope is just
> the application anyway).
>
> Thoughts? Obvious downsides? Am I on crack? Is it Good crack?-)
>
> [1] http://iki.fi/zuh/scw
>
> --
> Kalle Vahlman, zuh iki fi
> Powered by http://movial.fi
> Interesting stuff at http://syslog.movial.fi
>

--behdad
http://behdad.org/

"Commandment Three says Do Not Kill, Amendment Two says Blood Will Spill"
	-- Dan Bern, "New American Language"