[cairo] Font metrics under font transformations

[Maarten Breddels]

Keith Packard wrote:

>Around 18 o'clock on Jan 11, Maarten Breddels wrote:
>
>  
>
>>yup, I vote for vectors solution too, just makes life easier i guess.
>>    
>>
>
>I guess I have two questions:
>
> 1)	Where do we expect to use transformed fonts, and how do
> 	applications want to set text with transformed fonts?
>
>I see two 'legitimate' cases here --
>
> a)	Artificial oblique -- shearing text along the X axis.  In this 
>	case, the Y values don't change at all, so there's no actual 
>	problem
>
> b)	Inverting the coordinate space.  Right now, cairo uses the upper 
>	left corner as 0,0.  I imagine applications like PostScript or PDF
>	viewers might want a lower-left origin, in which case they must 
>	flip both the graphics coordinate system and the font coordinate
>	system.  Do we want to report negative line spacing in this case?
>	PostScript does not; to move down the page, you subtract the
>	font height.
>
>  
>
I think this flipped coordinate systems complicates things too much. For 
a simple hello world example it's fine, but when you're doing sth 
complicated, you always have to think about it. I would rather see cairo 
use the bottom left as (0,0), i mean, using the upper left corner is 
from the days of accessing framebuffers etc :). The other solution could 
be to not flip the text, so it will default appear upside down, it's not 
nice, but more consistent.

Anyway, as it's now, it might be a an idea to see it as if there is a 
hardcoded (1,0,0,-1) matrix in the font backends. This way, lets say we 
have set the fontsize to 30, and the 'height' (of a line) would be 40, 
it's made into the vector (40, 0), using the ('hardcoded') 'flip 
matrix'  it becomes (-40, 0), assuming the identity matrix in cairo, you 
would substract this height vector from your current 'pen location', and 
end up 40 pixels down. It may be weird to have a negative height, but in 
my mind, it's easier to use.
In case if i flipped the coordinate system, i would also have to flip 
the font matrix, the font matrix only affects the height vector, and 
would now become (40, 0) (the CTM doesn't and shouldn't affect the 
height vector i guess, since it should all be in user space).
For me this makes it easier, i just substruct the height vector to go to 
the next line, and add the advance vector to go to the next word etc.
(A bit overkill, but maybe the font needs 2 matrices, one for scaling, 
and 1 that should actually only be used to flip the coordinate system, 
the default would be a (1, 0, 0, -1) matrix, and people who dislike 
this, could set it to the identity matrix).
No matter how weird the transformation is, the 'add advance vector' and 
'substract height vector' should always work, i think.

>Other transformations should be considered 'fringe' cases for which "some" 
>answer should probably be given, although a strong argument for returning 
>an error when asked for font metrics can be made.
>
> 2)	How should an application set text in neat rows when presented
>	with line spacing which includes an X component?
>
>For this, I have no good answer -- as we do currently present glyph advance 
>values as vectors, it seems logical to do the same with line advances, but 
>the inverted coordinate space case makes this less compelling.
>
>-keith
>
>
>  
>
-Maarten Breddels