Hello, I came across the following bug report (#59390). In looking at the report it seems that an attempt was made to add some APIs that would allow Pango markup to be added to a text buffer (GtkTextBuffer). Has this work been completed (The report status is 'FIXED')? I didn't see it listed in the online API docs for GtkTextBuffer. If I understood this correctly the purpose was to allow someone to add Pango markup language to a GtkTextBuffer and in doing so the text would be displayed in a GtkTexView with the section of text rendered with the given Pango markup "directives" (i.e., bold or underline text, font size change, color, etc.). Is this correct? Kent --- New APIs (?) --- - text_buffer_insert_markup() - text_buffer_insert_markup_with_tag() - text_buffer_set_markup() - text_buffer_set_markup_with_tag() --- Bug Report 59390 --- Reporter: jpritikin@xxxxxxxxx (Joshua N Pritikin) > Is there an easy way to load Pango Markup into a GtkTextBuffer? Nope. > Or do i need to do it myself -- create the appropriate GtkTextTags, scan > the string with a GMarkup parser, and insert chunks piece by piece? This is essentially the problem, there are no default tags, and inserting markup would require that. So yeah, what you have to do right now is write your own gmarkup parser that does this. You could of course start with pango-markup.c source code, and change it to modify a text buffer instead of a PangoAttrList. Should think of a GTK 2.2 or 3.0 solution, no doubt this feature will be popularly requested. Havoc Pennington <hp@xxxxxxxxxx> ------- Additional Comment #1 From Havoc Pennington 2002-02-22 12:27 ------- <rambokid> hp: peeking at the testtext example, it doesn't seem to hard to add a function to your text widget taht inserts text with pango markup. <hp> rambokid: no it shouldn't be hard <hp> rambokid: the only issue is what you do about the tag table <hp> rambokid: one way is to require people to use the special "pango markup tag table" <hp> rambokid: another is to have gtk_text_tag_table_create_pango_markup_tags() to modify any existing tag table to contain the markup tags <hp> rambokid: another is to have a markup language that's like <tag name="foo">text</tag> and then work with any tag table <rambokid> hp: you have tag names, i guess you'd add pango-* tags on demand (i.e. if such a tag isn't already there) kinda like we use qdata on widgets along side the user using qdata as well <hp> rambokid: but that last option wouldn't use the Pango markup format <hp> rambokid: that might be a good option, yes, to implicitly add the tags when they are first used ------- Additional Comment #2 From Matthias Clasen 2003-02-05 10:31 ------- *** Bug 105313 has been marked as a duplicate of this bug. *** ------- Additional Comment #3 From Tim-Philipp Müller 2004-01-15 23:43 ------- Created an attachment (id=23423) small test that implements text_buffer_insert_markup() and other convenience functions ------- Additional Comment #4 From Tim-Philipp Müller 2004-01-15 23:49 ------- Attachement above is a self-contained test program that implements this functionality in a simple and crude way. It has four new functions: - text_buffer_insert_markup() - text_buffer_insert_markup_with_tag() - text_buffer_set_markup() - text_buffer_set_markup_with_tag() The _with_tag functions take an extra GtkTextTag to apply to the whole text, for word wrapping and justification parameters etc. Possibly it would be better to use GMarkupParser here and parse the markup ourselves. That would also allow us to expand the markup to include stuff like word wrapping and text justification, which cannot be set via pango markup. Additionally it would allow us to insert pixbufs with markup like <img file='foo.png'>. Or is that overkill? In any case, it would be nice if something like this went into 2.4, however crude it is implemented. In the worst case, one could point out in the docs that those functions are only suitable for short text. Cheers -Tim ------- Additional Comment #5 From Tim-Philipp Müller 2004-01-16 12:30 ------- Created an attachment (id=23451) Test app with text_buffer_insert_markup() implementation. This version fixes memory leaks of the previous version. ------- Additional Comment #6 From Tim-Philipp Müller 2004-01-22 01:45 ------- Created an attachment (id=23628) proposed patch that adds four new functions to the API ------- Additional Comment #7 From Tim-Philipp Müller 2004-01-22 01:54 ------- First of all, sorry for the flood. I thought it was better to post a sample first to see if my approach was right, but I guess it's better to just submit a patch. Won't do it again. The above patch introduces four new functions to the API, as described in my previous comment, ie: - gtk_text_buffer_insert_markup() - gtk_text_buffer_insert_markup_with_tag() - gtk_text_buffer_set_markup() - gtk_text_buffer_set_markup_with_tag() None of these functions takes a length argument. The markup text is expected to be NUL-terminated and will always be inserted fully. This is because the alternatives all seem a bit awkward to me. Any thoughts or comments? Cheers -Tim PS: maybe someone could change the keywords to API, PATCH ... ------- Additional Comment #8 From Owen Taylor 2004-01-22 11:58 ------- Moving to 2.6 API Freeze since we have a patch. Haven't looked at the patch or proposed API. ------- Additional Comment #9 From Elijah Newren 2004-03-10 16:14 ------- I'm adding the BLOCKED_BY_FREEZE keyword. ------- Additional Comment #10 From Tim-Philipp Müller 2004-06-15 08:33 ------- Created an attachment (id=28723) same patch, but with 'Since: 2.6' in the description ------- Additional Comment #11 From Bug flys 2004-08-19 01:53 ------- What about markups which overlap to each others? something like: <i><u>2 tags text</i></u> The real_insert_markup should check if the range of a markup overlaps with the previous one and accumulate tags before insert. Also a new tag is created for every markup encountered, that cause tags the same markup being created. Shouldn't a hashtable of 'markup' -> tag be saved in the textbuffer, so that tags can be reused by name? ------- Additional Comment #12 From Bug flys 2004-08-19 01:59 ------- or: <i>and <u>underline me </u> to stop it </i>. ------- Additional Comment #13 From Tim-Philipp Müller 2004-08-19 05:42 ------- I assume you meant <i><u>2 tags text</u></i> ? I would expect pango_parse_markup() to accumulate tags like that (I haven't actually checked whether it does though). I am not sure I understand the purpose of your last example <i>and <u>underline me</u> to stop it</i>. I agree a hash table that maps a certain format to a re-usable tag would be nice, but it doesn't seem worth the effort to me. In any case, this kind of optimisation could still be added later IMHO. Feel free to modify the patch though, or come up with a new one :) Cheers -Tim ------- Additional Comment #14 From Bug flys 2004-08-21 03:09 ------- About reuse the tag of a given markup, there is a function: GtkTextTag* gtk_text_tag_table_lookup (GtkTextTagTable *table, const gchar *name); A named tag should be checked first and if NULL is returned, a new one can be created. No hashtable is neccessary. ------- Additional Comment #15 From Tim-Philipp Müller 2004-08-21 06:53 ------- When I said 'effort' I didn't mean the hashtable lookup or the gtk_text_table_lookup(), but rather the problem of 'I have this bunch of PangoAttributes with these values; how do I know I already have a tag with exactly the same attributes?'. Maybe this is trivial, but I don't see how to easily do it. Of course one could always serialise the attributes into a string again and derive a tag name from that, but I have my doubts that that would really be of advantage for the common case. Similarly, we could parse the attributes ourselves using GMarkupParser instead of pango_parse_markup(), but that seems like unnecessary code duplication for hardly any benefit to me. Cheers -Tim _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
