Now that bug 99010 is fixed, transitory font APIs need to be cleaned up. Vallers should be moved to GetTextDimensions(). Nobody likes the name DrawString2()... it should be renamed and take over from the old DrawString() which is going away. A canditate name of DrawString2() could be DrawText() to help clear the old semantics attached to the old DrawString(). Also, DrawText() matches nicer with GetTextDimensions(). However there are several helper DrawString() methods, and I wonder if it is worth the launching of a s///g on these helpers too. Hence it is also tempting to stay with the old name DrawString(). To do or not to do. Let the quibbling begins.

-> rbs

Does DrawString2/DrawText pass in a y coordinate at the baseline? If so, will this work smoothly with baseline adjust values from the BASE table? http://www.microsoft.com/typography/tt/win95tt.htm The BASE table contains baseline and minimum/maximum extent data for each script. Script baselines can be defined in relation to one another to properly align glyphs from different scripts.

adding yokoyama and nhotta to the cc: list as they may have interest in font API changes

>Does DrawString2/DrawText pass in a y coordinate at the baseline? Yes. >If so, will this work smoothly with baseline adjust values from the BASE table? Yes since it is the GDI that is doing the drawing in TA_BASELINE mode. In fact, GfxWin used not to draw at the baseline, but when the support for MathML/Symbol fonts where hooked in, misalignements were experienced during font-switching, and we had to switch to the baseline mode. Since then, no case of misalignments have been observed.

Ready for r/sr Back to DrawString(). I tried DrawText() and had troubles with it because the same name is used by the Windows GDI and caused it to be confused. I had to re-cleanup :-(

Comment on attachment 55710 [details] [diff] [review] cleanup patch sr=attinasi

Comment on attachment 55710 [details] [diff] [review] cleanup patch r=waterson

patch checked in.