Re: label markup

[Havoc Pennington <hp redhat com>]

OK, I did an initial implementation of this in Pango and GtkLabel
(though it doesn't work yet, my attributes seem to get lost sometime
between pango_layout_set_attributes() and pango_itemize()...) and yep
some of the issues you mentioned came up...

Owen Taylor <otaylor redhat com> writes:
> >   <p align="center">
> 
> How are you going to implement this? (See below - GtkLabel can
> have multiple paragraphs, but they all need the same alignment,
> currently)
>

In fact this is not implementable that I see. Will probably just dump
it.
 
> >   <language name="isocountrycode">
> 
> >   <font family="Sans" size="10" style="italic" weight="bold" 
> >         variant="smallcaps" stretch="condensed" desc="Serif Italic 10"
> >         foreground="FFFFFF" background="FFFFFF" underline="double"
>                       ^ Definitily need the # here
> 

Right, I cut and pasted parse_color from io-xpm.c and it requires the #.

> >         strikethrough="true" rise="100">
> 
> It would actually be more "modern" to do
> 
>  <span lang="en" font_desc="Serif Italic 10">Some Text</span>
> 
> Also, I think <font foreground="blue"></font> is a little odd.
>

So you're suggesting simply s/font/span/g, or more than that?
My HTML book seems to end with 3.2, so I'll dig up a 4.0 reference and
copy what it has.
  
> > Syntactic sugar that can be done with the base tags:
> >   <i>     italic
> >   <b>     bold
> >   <u>     underline
> >   <s>     strikethrough
> >   <sup>   superscript
> >   <sub>   subscript
> 
> >   <big>   somewhat larger
> >   <small> somewhat smaller
> 
> Hmm, if you are going to support these, I'd be tempted to actually
> implement the real CSS way of doing this, allow size=[xx-small |
> x-small | small | medium | large | x-large | xx-large | larger |
> smaller] In the <font> description, and then make <big> and <small>
> synonyms for <font size="smaller"> <font size="larger">.
>

I've run into a problem here, which is that you don't have the base
font until pango_itemize() time or so. To a lesser degree this breaks
super/subscript too, since the amount of rise should presumably be a
function of font size, and you want super/sub to be in a font size
somewhat smaller than the main font.

One way to do this (I don't know if it's worth it) is to have two new
pango attributes, one for "scaled rise" that's some percent of base font
height, and one for "scaled size" that's some percent of base font
size. Alternatives are to just junk these tags (although I think
they're somewhat useful) or pass in a base font to parse_markup()
(this means e.g. that the order in which you call layout_set_markup()
and layout_set_font_desc() will matter).
 
> >  - would be nice to use gdk_color_parse for color, but it isn't 
> >    in pango; maybe move the non-X version to pango?
> 
> I don't think making gdk-pixbuf depend on pango is any nicer
> than making pango depend on gdk-pixbuf :-); and I'm sure
> we don't want that big table in two places.
>

Yep, I didn't consider that gdk-pixbuf is not linking to Pango.
 
> One possibility would be to pass in a color parse function into
> pango_markup_parse(), then virtualize the operation in PangoContext
> to avoid having to pass these functions around everywhere.
> I don't know if that is overkill just to get foreground="red"
> to work.
>

Seems pretty ugly, and also creates nonstandard markup flavors
depending on what function is passed in.
 
> One possibility would be to instead, support the 16 HTML colors
> instead of the full rgb.txt set; that avoids having to have
> the huge table.
>  

I guess that's the least of the evils. I'm sort of tempted to suggest
g_parse_color() in GLib, but. Probably shouldn't. The table does chew
substantial disk space.

> >  - the <p> tag is the root tag; this markup language is for single 
> >    paragraphs. For GtkLabel, it's kind of annoying to have
> >    to do <p>My Label</p> though, so we should automatically bracket
> >    the markup text in <p></p> if the first two chars aren't "<p".
> 
> GtkLabel allows multiple paragraphs. I'd suggest making the
> root tag <markup> and allowing that to be omitted as well as
> <p>.
>

OK, will do it that way.
  
> Though I don't seem to have implemented this yet. 
> 

I'm going to simply dump all references to alignment in the markup for
now. Will think about whether and how it should go back.

Havoc