To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=101050
------- Additional comments from [email protected] Thu Apr 30 17:08:20 +0000 2009 ------- AW: Ah, Yes! Da**ed! Normals are simply not points. Argh! As can be seen, a compromize of older ages (transport normals as polygon, there was tooling for this already) leads to growing problems in the future :-( I have no quick idea how to fix this, but the error definitely happens in the API implementation (Svx3DPolygonObject::setPropertyValueImpl). For OWN_ATTR_3D_VALUE_NORMALSPOLYGON3D and for OWN_ATTR_3D_VALUE_TEXTUREPOLYGON3D PolyPolygonShape3D_to_B3dPolyPolygon should not call basegfx::tools::checkClosed; a flag at PolyPolygonShape3D_to_B3dPolyPolygon may do that. In that case, the normal and/or texture polygon can never have less, but maybe one more 'point' than the original (when the original was closed). The safety decisions proposed in ViewContactOfE3dPolygon::createViewIndependentPrimitive3DSequence would have to be adapted to not only work on normal and/or texture data with the same, but with the same or more (>= instead of ==) points. We need to write a task for cleaning this up in the future. The API is simply not good designed for the purpose here... --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
