Re: Extending pango markup

[Behdad Esfahbod <behdad cs toronto edu>]

On Wed, 12 Apr 2006, Kalle Vahlman wrote:

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

Yes, exactly.  So rule this off.


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

Ok, I guess so, but you didn't say in your original post that you
want to emit pango attributes in your tags, so I was not sure.


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

Yeah, that's almost what I have in mind now.  I was thinking more
about having a hashtable mapping new tags to callbacks, but that
is not even easier to use, so one callback is probably the
easiest.  It takes the tag, XML attribute name/values,
current Pango attributes (not sure if this last one is a good
idea / really needed.  do you happen to need them?), and a
GError, and one of 1) returns one attribute (flawed), 2) returns
a list of attributes (a bit more pain than 1, but more generic),
or 3) prepends the new attributes to the input list and return
the new list.  Option 2 is probably the cleanest, while 3 is
easiest to use...  Not sure here.

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

Yes agreed.  I on the other hand, prefer to address the problem
more generally now that we are adding API for this.  For example,
it should allow for turning off the internal set of attributes
IMO, so you can write parsers for arbitrary markups.

Some not-quite-unrelated discussion is going on in bug 330960:

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

Although with this new approach, it seems to be quite unrelated
now :).


Ok, I think you should file this as a bug and we can continue
there.


behdad