[Mono-winforms-list] [Mono-dev] libgdiplus pango patch

[Sebastien Pouliot]

Hello Jonathan,

On Thu, 2009-02-12 at 18:46 +0700, Jonathan Anderson wrote:
> Sebastien,
> 
> Thanks for the reply.
> 
> Sebastien Pouliot wrote:
> > Hello Jonathan,
> > 
> > On Tue, 2009-02-10 at 13:53 +0700, Jonathan Anderson wrote:
> >> Hi all,
> >>
> >> I was wondering if anyone has had a chance to look at my patch submitted 
> >> last week yet.  Any and all feedback is appreciated, and if I need to do 
> >> some more work to get this accepted, I just need to know what to do. 
> > 
> > I only had a quick look last week, but will look at it more carefully
> > soon.
> > 
> > A quick comment: it needs a ChangeLog ;-)
> 
> I should have done that.  Here's a list of what my changes do:
> 
> * improve accelerator handling
> * improve end-of-line whitespace trimming (still needs some work, but it 
> should be about the same as the cairo renderer now)
> * vertical text support (needs more work)
> * clipping more consistent with MS GDI+
> * better bidi text support
> * string trimming closer to MS GDI+
> * tab stops (untested)
> * better bounding boxes returned (taking into account ink and logical space)
> * support for codepointsFitted in MeasureString
> * better linesFilled support in MeasureString

Great :)

> >> Should I create a bug in the tracker to help track the work on complex 
> >> script support?
> > 
> > Yes, that would be useful - which brings me to a "long term" comment:
> > libgdiplus can't switch to pango output until it becomes a superset of
> > the features that it currently (custom text renderer) support - i.e.
> > complex script support is awesome but not enough as many people depends
> > on other features not yet available in the pango renderer.
> 
> 
> Yes, I understand that.  I mainly want to get some code out there for 
> complex script support that works better than what's there now.  Of 

we understand each other perfectly :)

> course I'd like it to be the default some day, but I know there needs to 
> be more work and testing done before that can be the case.  Even if it 
> doesn't get to be the default, having a good option for non-roman 
> scripts when needed is great.
> 
> There are a couple of issues that I've fixed since the patch I submitted 
> as well (fixed a problem with vertical text and another difference with 
> how MS GDI+ handles the NoWrap flag).  Should I do another patch with 
> everything again, or just a patch on the patched version for those?

You can issue a new, complete patch.

> Here's what I know isn't supported and/or needs more work:
> * Need to test the tab stop support
> * There are a few small differences with the MS GDI+ in string trimming 
> and wrapping that will be hard to fix unless I use the lower-level pango 
> API instead of the pango_layout calls.  

That was my original conclusion too. The high-level pango API is not
able to give us everything needed to support the options already present
in the custom renderer. The "right" (complete) solution is to use the
low level API.

> The cairo renderer also has some 
> differences in these areas as well.

Yes, there are a few (4-5) bugs open on some specific cases. Most of
them requires *big* changes to the custom renderer (things that was not
part of its design) which are unlikely to occur soon*

        * in fact my original idea was, once the pango version was
        complete enough to replace the current renderer, to detect the
        pango library at build time and use it (and the system cairo) if
        possible - falling back to the old renderer on older systems.

> * digit substitution is not implemented
> * the DisplayFormatControl flag is not implemented
> * MeasureString is significantly slower than the cairo renderer 
> (DrawString is a little slower, but not that much)

That's also what I noticed a while ago - but the output also looked
better (e.g. kerning).

> I don't think the digit substitution or DisplayFormatControl flag are 
> implemented in the cairo renderer either.  I've built myself a test app 
> to help see differences between MS GDI+, the cairo renderer, and the 
> pango renderer, so that's helping a lot in working things out.

Yes, I had such a (crude) tool when I looked at "all" the options (which
made me realize we were doing very badly on the, thankfully, uncommon
StringFormat options). This is something that needs to be turned into
"real" tests at some stage.

>  From a MWF perspective, the only control that I think needs a bit of 
> work is the TextBox and derivatives.  To be able to support non-roman 
> scripts, it needs to think of text in terms of paragraphs instead of 
> lines.  I have some ideas that I'll be playing with to push down some 
> more of the rendering/placement functionality into the 
> TextBoxTextRenderer.  I should be able to take the existing code and 
> abstract it in a way that would allow the TextBox to swap rendering 
> back-ends using the current code, uniscribe, or pango.

Sounds good (even if this is not parts I'm involved with ;-)

Thanks!
Sebastien