Hi all, I think this can only be solved by reworking the complete flash export to only use B2DPolyPolygon. But this should not be done before we have the drawing layer support for primitives. I suggest we keep the current solution, even if it does not find all characters that are equal. We should check if at least some equals are found and resulting exported files will be smaller than before. If this is the case and there are no errors then we should integrate the CWS (after QA) with the current known limitations.
Regards, Christian H Duerr wrote: > Hello Fang, > > >> I am regret to say that there still some problems in texporting the >> complex charactors. For example, >> "一二三四，一二" >> the first charactor "一" should be compared to be the same as the sixth >> charactor"一"，but the result is not the same. I debugged for it and I >> found that the >> if ( Count() != rPolyPoly.Count() ) >> bIsEqual = >> sal_False; //PolyPolygon::IsEqual() in poly2.cxx >> and >> if ( GetSize() != rPoly.GetSize() ) >> bIsEqual = sal_False; //Polygon::IsEqual() in >> poly.cxx >> >> always turned bIsEqual to be false and then made the result to be false >> even the charactor is the same. >> I think it is none of the bussiness of the offset of the aPolyPoly, it >> is related to the count() which gained from the vcl. >> >> The problem appears irregularly, some times are right but some time are >> wrong and some times the fisrt is not compared to be the same with the >> sixth and some time the second is not compared to be the same with the >> seventh. >> I cannot explain this, can you give me any suggestions? And the I want >> to know whether the occasion will be happening ：when a charactor be >> generated twice and the PolyPolygon.count() of the the two polypolygon >> will not be the same? >> > > First please make sure that the same font is selected for the whole string. > > Also in your code there are implicit conversions from > basegfx::B2DPolygon to tools Polygon. As far as I know these conversions > optimize away duplicate points and remove bezier control points when > they are not needed. Identifying duplicate points is non-trivial since > equality of floating point coordinates is a little tricky. Since > outlines of glyphs get transformed dependent on their position this > could make a difference on whether a point is identified as duplicate > and gets removed or not. Please compare the polygon and point count > before the conversion. > > -- > Herbert > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Sun Microsystems GmbH Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB 161028 Geschaeftsfuehrer: Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
