Now that we've agreed we are going to use ATSUI for UniCode rendering...

This is a place holder bug for figuring out who might do this work and how hard its going to be. adding bobj kevinjw to cc list.

This is a place holder bug for figuring out who might do this work and how hard its going to be. adding bobj kevinjw to cc list.

I'm learning about ATSUI now, and discussing with Frank Tang how best to divide up the work.

Added ftang to cc list.

The "Hack" is check in. But we need to redeisgn GFX interface to optimize it.

I believe this bug is about if/how to support ATSUI on pre-MacOS8.5. Frank's previous comment is about a hack to allow other development to continue while we get the "real" display work done on 5.0. From Frank's email: "Here is the patch which will make Mac GFX rendering Unicode on MacOS 8.5 until we rework the GFX. It is quick and dirty. My only intention is to make it display CJK for now so we can start working on IME stuff without waiting for GFX to complete." This still assumes MacOS8.5 and is not related to this particular bug. We still need to determine if we can run ATSUI on 8.1 and maybe even 7.6.1. If not, we need an alternative plan for 5.0 Mac I18N.

Changing beginning of Summary from [PP] to [I18n]. We will now use this system to keep track of international parity bugs to address by Mar 1.

Changing beginning of Summary from [PP] to [I18n]. We will now use this system to keep track of international parity bugs to address by Mar 1.

Changing beginning of Summary from [PP] to [I18n]. We will now use this system to keep track of international parity bugs to address by Mar 1.

Changing beginning of Summary from [PP] to [I18n]. We will now use this system to keep track of international parity bugs to address by Mar 1.

Setting all current Open/Normal to M4.

I got some info from Apple- since this bug system is public, I cannot attach the exact mail here. But here is the summary- 1. Apple is considering have ATSUI 1.1 SDK which will run on MacOS 8.1. Date unknown for that SDK. 2. ATSUI API is part of CarbonLib and it should be able to run on 8.x. Date unknown for CarbonLib. add Apple's contact into the bug cc list.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

Reassigning qa contact to petersen@netscape.com.

We're reversing our requirement on ATSUI for 5.0. ftang has worked on the ATSUI implementation and discovered that it's too slow. The ATSUI model works at the layout level and Gecko only needs it for lower level measuring and drawing. Frank's measurements indicate that the best case performance with the ATSUI APIs would be 3 times slower than using the QuickDraw (QD) APIs. ftang has a new design that is not dependent upon ATSUI. The requirement for ATSUI was based upon the belief that (1) implementing using ATSUI would be easier than using QD, and (2) the functionality would be much better. With further investigation of the GFX design, ftang came up with a QD approach that is less complex than originally SWAG'ed. ftang implemented this with a couple additional weeks of work and it provides far better performance. We still use the ATSUI work that was been done as a fallback for glyphs that cannot be drawn using the QD approach. If ATSUI is unavailable (e.g. on MacOS 8.1), then square boxes (no-glyph glyph) will be drawn. With Frank's new QD approach, these cases are minimized and should rarely occur. Using CarbonLib on MacOS 8.1 can be optional and should be release noted. Bottom line: We have eliminated our dependency on ATSUI.

We're reversing our requirement on ATSUI for 5.0. ftang has worked on the ATSUI implementation and discovered that it's too slow. The ATSUI model works at the layout level and Gecko only needs it for lower level measuring and drawing. Frank's measurements indicate that the best case performance with the ATSUI APIs would be 3 times slower than using the QuickDraw (QD) APIs. ftang has a new design that is not dependent upon ATSUI. The requirement for ATSUI was based upon the belief that (1) implementing using ATSUI would be easier than using QD, and (2) the functionality would be much better. With further investigation of the GFX design, ftang came up with a QD approach that is less complex than originally SWAG'ed. ftang implemented this with a couple additional weeks of work and it provides far better performance. We still use the ATSUI work that was been done as a fallback for glyphs that cannot be drawn using the QD approach. If ATSUI is unavailable (e.g. on MacOS 8.1), then square boxes (no-glyph glyph) will be drawn. With Frank's new QD approach, these cases are minimized and should rarely occur. Using CarbonLib on MacOS 8.1 can be optional and should be release noted. Bottom line: We have eliminated our dependency on ATSUI.

Pierre has reviewed Frank's code. He wants to make some changes, but this won't happen until after M5.

Frank has checked in his changes for M6.

Frank has checked in his changes for M6.

Fixed in Mac 5/17 Build.