From: Daniel Glassey (danglassey-abi_at_ntlworld.com)
Date: Fri Nov 07 2003 - 17:04:35 EST
On Wed, 2003-10-29 at 08:44, Tomas Frydrych wrote:
> Hi Daniel,
>
> > > One of the problems I run into was lack of adequate XP API. ... For many of the things I
> > > needed to do in our XP code, I would have to use X/FT/Win32-specific
> > > calls.
> >
> > What kind of things?
>
> I cannot give you the details of the top of my head, and things are
> likely to be different (I have not looked at Panogo for 18 months). I
> just know that at that time I could have not written the code (most
> of which was XP) without going into engine specific calls -- what I
> am saying is that anyone who wants to venture this needs to consider
> whether the Panogo XP API provides all we need, and what it would
> meant if it does not.
OK, I'm just wondering if the non-XP calls can be moved to the platform
specific grGraphics classes or somewhere else in non-XP land.
> > > Then there is the larger question of being able to use Pango on
> > > QNX/BeOS/Mac. The FT2 engine would make that possible in theory, but
> > > then someone needs to port FT2 to QNX/BeOS/Mac;
> >
> > I'd be suprised if it doesn't already work on all those.
>
> It might, but I would not be making any assumptions. 18-months ago it
> was really only available on *nix, its part of a *nix GUI library ...
>From what I remember FT2 should work fine on anything as long as you can
give it the path to the font.
> > However, imho the ft2 engine is not the right solution. Pango for
> > win32 uses the native shaping system (uniscribe) where it deems it
> > necessary. For complex i18n text layout it would make sense to use
> > the native systems. On MacOSX that means ATSUI, on Win32 that means
> > uniscribe (or pango->uniscribe), on Gtk/Gnome that means pango,
> > don't know about QNX or BeOS.
>
> There are two things that need to be considered. One is consistent
> behaviour cross plaforms. Chances are that if you use four different
> shapers, you will end up with different layout for identical text on
> different platforms.
OK, that needs considered. It is true that consistency is important. I
don't have the answer but I would guess it would also be good for the
same doc to appear the same (hopefully correct) way in different apps on
the same platform.
I guess it depends how deeply pango is used (all platforms or only
some). If pangos breaker is the only breaker that is used rather than a
platform specific one then it would be more consistent.
> For instance, the MS bidi algorithm is different
> from the Unicode bidi algorithm, and it behaves differently on
> different win32 flavours; it has proved unusable for our purposes.
Yuck.
> Are the capabilities of the PangoWin32 anything like the capabilites
> of PangoX;
Yes, well, it now uses uniscribe which I think is comparable to
pangoxft.
> how do the capabilites of Uniscribe/ATSUI compare?
That I don't know. From a quick look at the API, ATSUI looks different.
> What if
> we are unable to used the native shaper on one of the platforms?
FT2 might be useful as an alternative for if the native shaper can be
used.
> Once
> you start asking these kinds of questions, the (portabile) FT2
> solution may not seem so bad.
It's not a bad solution, I just don't think it is the best.
> The other thing to consider is maintainability. We have been
> struggling to maintain the bidi side of things even though 99% of it
> is in XP code, and even though conceptually the bidi problem is very
> simple. Who is going to write the code on these different platforms
> in the first instance, and who is going to maintain it? Unless we can
> write and maintain such code in the longterm, all the other potential
> advantages are nullified.
If we can design it so that as much as possible is in XP land and that
things are made as easy as possible for platform maintainers then we
have got a long way. If we don't then we won't get anywhere.
If we don't try then we won't get anywhere either.
> > Does it seem feasible to make a layout class that would provide
> > the breaking and other funcs that the rest of AW layout requires?
> > Since pango only works on a paragraph at a time AW still has to do
> > a lot around it.
>
> If it was just a question of replacing the block layout basic block
> layout functionality, it would not be too bad. What seems to me to be
> the problem is that the classes above block layout and the view class
> still make direct access to the classes bellow the block, such as
> runs. I think this is a design flaw, ideally, each subsequent layer
> in the layout should only have access to and manipulate directly the
> layer immediately below. This not being the case, the issue that I
> think would prove the real problem is how attach the run classes to
> the Pango engine.
Martin?
Regards,
Daniel
This archive was generated by hypermail 2.1.4 : Fri Nov 07 2003 - 17:02:38 EST