[Cairo] Text APIs round 2

[Owen Taylor]

On Fri, 2003-08-15 at 13:11, Keith Packard wrote:
> Around 11 o'clock on Aug 15, Owen Taylor wrote:
> 
> > The way postscript handles this is that fonts start off with a default
> > size of 1 unit... sort of useless, but at least gives *some* meaning
> > to the situation.
> 
> But, PostScript doesn't have to deal with bitmap fonts.  I need to know 
> the pixel size before I can select anything in that case.  I guess
> I just need to keep the font parameters around and reselect a font if the 
> transformation changes.  Hmm.  How about I resolve the font the first time 
> it's used and never re-resolve it; that way I can have 'squishy' fonts that 
> are 'solidified' as late as possible, but then never again.  Change the 
> transformation a second time and you get garbage for bitmap fonts.  I can 
> certainly live with that.
> 
> > How about _width()?
> 
> Is that width of the glyph bounding box or the distance along the baseline?
> If we use 'width', then we'd better be pretty careful about the names we 
> stick in the extents structure.

I suggested it because dx is a bit obscure and it is called 'width'
in Postscript and in core X (that's what XTextWidth() gives you)

> > Well, the Pango API's basic drawing call is "draw this string of glyphs
> > in this font"...
> 
> Yeah, but a 'font' consists of many underlying TrueType fonts as needed to 
> cover the text being set; for Mozilla, it was easy to ignore which font a 
> glyph came from, but for Pango that's not true.

Not completely sure what you are saying here. A PangoFont corresponds
to a system font pretty much exactly. It isn't a fontset.

> However, you can't get 'correct' output unless you provide an API that 
> specifies the font for each glyph as the compositing will be broken when 
> switching fonts.  You don't get to choose the XDrawText style API either 
> (yuck), so the choice is between having a single API which takes a font 
> for each glyph or having two APIs, one of which takes a font for each 
> glyph and one which doesn't.  The underlying code for either is pretty 
> simple, so I guess I can be persueded to include two versions, but it's 
> not going to make me happy :-)

I really suspect that "correct output when switching fonts" is not a
real concern. There are two possible concerns:
  
 - Overlapping glyphs drawn at half-alpha. Overlapping glyphs from 
   different fonts just don't occur in normal text.
 
 - Operations where 0 alpha pixels in the input have a non-null effect
   in the ouput. This is related to the problem of clip masks not
   clipping for these operators. 

   The question is where do you stop? Do you render entire lines in 
   one go? Entire paragraphs? Entire pages? What happens when 
   you have color changes within a line? Don't you need color in 
   your API too? 

   I also note that XftGlyphFontSpec uses separate calls per 
   font change; it seems to me that if you really want 
   "one composite per draw text", you'll have to create your
   own temporary Pixmap to hold the composited operation, rather
   than relying on XRenderCompositeString().

I don't want to spend too much time arguing against an API that
takes a font per glyph, I'm just saying that as far as I can see,
I'll just be sticking the same font into every glyph structure.

Regards,
						Owen


Note:

For comparison, the PDF model as I can figure it out is:

 - An entire set of text rendering operations is grouped
   with BT/ET. Within the group can be text drawing operators,
   but also changes in the color, changes in the text drawing
   mode (stroke glyphs instead of filling) and so forth.

 - By default, each operations "knocks out" previous operations;
   this is more or less.

    GroupSurface = (Source IN Glyph) Add (Glyph OutReverse GroupSurface)

   It's possible to configure PDF so that it's just

    GroupSurface = (Source IN Glyph) Over GroupSurface
 
 - Then the entire text group is composited against the background

Which is basically a generalization of the XRenderCompositeString
model. One of places where this behavior is most noteable is when
filling and stroking the same glyph - since the stroke intersects
the fill, you don't want that area to be painted twice, once in
each color.