[EMAIL PROTECTED] writes:
> I remember, a guy was trying to port cairo to Win9x, although
> yet I've not heard successful report, at present.
OK. Doesn't sound too promising, then.
> Dropping Win9x code from HEAD means "GTK+ 2.12 won't support for
> Win9x"?
Yes. For GTK+ 2.10 the situation is the same as for 2.8, i.e. it would
presumably work otherwise, if cairo would.
> I see. Do you think it is possible that packaging Win95 support
> code as separate library?
Yes. The "separate library" is calld GTK+ 2.6 ;)
> I guess, the import Uniscribe into pangowin32 is requested to
> add complex script rendering feature to pangowin32 itself.
> By Uniscribe rendering, the complex script rendering would
> be exactly same with popular Win32 applications (e.g. wordpad.exe).
Yes. ("would" is wrong, it *is* (one would hope) and has been for a
long time.)
> I guess it is the advantage prioritized by the people who request
> default-and-builtin Uniscribe support. Am I right?
Hmm, I don't really understand what you mean here. There are no
alternatives to Uniscribe for Pango on Win32. There is code in Pango
itself for complex script processing only when using the
fontconfig-based backends.
The Uniscribe use in Pango is currently optional both during
configuration/compilation, and during runtime. I am suggesting that
the optionality during configuration/compilation could be
removed. (Thus one would have to have the Platform SDK, or at least
just usp10.h, on the machine where one builds Pango.)
The code would still check at run-time for the availability of
usp10.dll, and link to it dynamically. Thus one might still be able to
use pangowin32 on Win9x... but that is mostly a pointless fact as GTK+
uses pangocairo (which uses cairo and pangowin32).
--tml
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
