To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=93169
User aw changed the following:
What |Old value |New value
================================================================================
Status|NEW |STARTED
--------------------------------------------------------------------------------
------- Additional comments from [EMAIL PROTECTED] Fri Oct 17 12:59:03 +0000
2008 -------
AW: The FormControl primitive rendering was defaulted to decomposition on aw033
(which is a good test and revealed other stuff). For this fix, i will add
special rendering for the ControlPrimitive2D in the VclMetafileProcessor2D and
the VclPixelProcessor2D.
One problem was the pos and size of the controls. There was a choice to position
and size them either (a) in the VOC at the point in time the PrimitiveSequence
is fetched (ViewObjectContactOfUnoControl::createPrimitive2DSequence) or (b)
directly in the primitive renderers when a ControlPrimitive2D is rendered. Old
version used (a), but had an own positioning for the controls in the renderers
which was pixel based and was not working for all cases.
I experimented with (b) but ran in big problems, e.g. when the controls are in
live mode, the VCL-Windows representing them reduces the repaint region and thus
the form control primitive would sometimes not be in the region at repaint
preparation and would not be repainted -> not nrewly positioned. Only one
exapmle, there were others.
So i now decided to (a) which also allows to greatly reduce complexity in the
renderers since they imply that pos and scale (and font scale) are correct and
just need to resemble the various paints in the former VOCs for FormControls.
Only one case cannot be simplified, the decompose of the FormControl, since it
aints at (0, 0) in a VDev and uses quadratic pixel reduction to not make the
bitmaps too huge. There, the font scaling still needs to be set individually
(fixed in aw057 already).
After positioning and sizing (and zooming) in (a), i corrected the handlings of
ControlPrimitive2D in the two renderers mentioned above. All Cases so far are
working just as expected. Also the decompose of ControlPrimitive2D to bitmap
primitive(s) does not happen anymore now (but was necessary to test since other
primitive technique users will not support ControlPrimitive2D directly).
Doing some more tests...
---------------------------------------------------------------------
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]
