Issue 122216 - Form controls will not be printed or exported to PDF
Summary: Form controls will not be printed or exported to PDF
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: 4.0.0-dev
Hardware: PC Windows 7
: P3 Major (vote)
Target Milestone: 4.0.0
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: regression
Depends on:
Blocks:
 
Reported: 2013-05-02 17:26 UTC by Rainer Bielefeld
Modified: 2022-10-28 12:54 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: 4.0.0
Developer Difficulty: ---


Attachments
Test Kit (21.71 KB, application/zip)
2013-05-02 17:26 UTC, Rainer Bielefeld
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Rainer Bielefeld 2013-05-02 17:26:54 UTC
Created attachment 80624 [details]
Test Kit

Steps how to reproduce with server installation of  "AOOo 4.0.0-Dev – English UI / German locale [AOO400m1(Build:9700) - Rev.1476029]" on WIN7 Home Premium (64bit)", own separate user profile:

1. Open new Writer document from AOOo Start Center
2. If necessary, make visible Form Controls Toolbar in menu 'View -> Toolbars'
3. Insert some form controls (radi button, checkbox, button
4. Menu 'File -> Print'
   Expected: Form controls visible in print preview, will be printed
   Actual: Form controls NOT visible in print preview, will be NOT printed
           Although 'Print Form Controls' is checked in Print Dialog

Additional info:
Also Calc affected (Draw, Impress not tested(
Also PDF export affected, also when "Create PDF Form" is checked
No problem with 3.4.1
In attached test kit you find sample document and my results of PDF export with 4.0 and 3.4.1
Comment 1 Edwin Sharp 2013-05-02 17:52:01 UTC
Confirmed on Rev. 1476029 Win 7
Comment 2 Oliver Brinzing 2013-05-03 05:02:28 UTC
.
Comment 3 Armin Le Grand 2013-05-03 12:49:35 UTC
ALG: Preparing SW with debug...
Comment 4 Armin Le Grand 2013-05-03 17:08:04 UTC
ALG: May have to do with #115754#, there is a hint in ViewObjectContactOfUnoControl::createPrimitive2DSequence, this hinders draw information from the controls to be created at all.
As second, these MetaActions cerated by case PRIMITIVE2D_ID_CONTROLPRIMITIVE2D in VclMetafileProcessor2D seem to be positined/scaled wrong; when creating a control top-left it is shown in the preview...
Comment 5 Armin Le Grand 2013-05-03 17:25:04 UTC
ALG: Seems as if FormControls are painted much too big, checking, need toolkit with debug...
Comment 6 Armin Le Grand 2013-05-06 08:05:21 UTC
ALG: I'm wondering what changed between 3.4.1 and now, taking a look at 3.4.1 version. INdeed works there...
Comment 7 Armin Le Grand 2013-05-06 08:28:18 UTC
ALG: Has to do with https://issues.apache.org/ooo/show_bug.cgi?id=121534, there I changed ObjectContactOfPageView::DoProcessDisplay to leave object transformation empty for metafile recording. This seems to trigger this task. Checking...
Comment 8 Armin Le Grand 2013-05-06 08:36:28 UTC
ALG: Confirm that this is the reason; need to check now why I did that and what it ought to fix; it is definitely not correct to not use the ViewTransformation of the targte OutputDevice. Must have to do with rotated graphics...
Comment 9 Armin Le Grand 2013-05-06 11:17:07 UTC
ALG: Has to do with the test if graphics are inside (VclProcessor2D::RenderBitmapPrimitive2D). In the metafile case this comparison goes wrong when a ViewTransformation is set. Indeed the MetafileProcessor should have no ViewTransformation set, the goal is to record logical coordinates in the whole process. Thus, not setting the ViewTransformation for metafile recording was correct.
On the other hand the visualisation substituton creator in case PRIMITIVE2D_ID_CONTROLPRIMITIVE2D in VclMetafileProcessor2D::processBasePrimitive2D needs to create the discrete positions to draw that control using awt::XView and awt::XGraphics. In this case it is known that a metafile is recorded and access to the target OutputDeice is given, so it seems to be best to fix it here. Also strange is that at the OutputDevice there is a neutral MapMode set, but maMapRes contains the scaling. It seems to be prepared when setting the MapMode, in this case only containing the MAP_100TH_MM as value.
Checking if this can be fixed directly in the Metafileprocessor...
Comment 10 Armin Le Grand 2013-05-06 11:57:08 UTC
ALG: I can calculate the real discrete pos/size and set it at awt::XWindow (rescuing the old, resetting after), but the font size is not well adapted. Maybe I'll also have to get/set Zoom to discrete units...
Comment 11 Armin Le Grand 2013-05-06 13:32:05 UTC
ALG: This gets too dangerous. It's better to turn back setting ViewTransformation from #121534# and change processing in drawinglayer to not use ViewInformation2D::getDiscreteViewport() in VclMetafileProcessor2D implementations. Comparisons with discrete coordinates will not work in VclMetafileProcessor2D and should not be used. Main reason is that the local current transformation for processing gets set to LogicToWorld, but not to LogicToDiscrete.
Checked this, works well as expected.
Also took the time to check if VclMetafileProcessor2D will work well with setting the local transformation as in the pixel processor, and in principle it does. The metafile will then contain a mapping action to MAP_PIXEL at the start what is allowed. It is for now too dangerous to find out if this is supported everywhere needed (e.g. in interpretMetafile in MetafilePrimitive2D implementation. Too dangerous for now.
Comment 12 Armin Le Grand 2013-05-06 14:13:57 UTC
ALG: Okay, comitting changes, done.
Thanks to all finding this, this would have been pretty bad for 4.0. Continue to write tasks when you see something going wrong, please, we need that ;-)
Comment 13 Armin Le Grand 2013-05-06 14:14:14 UTC
ALG: OKay, done.
Comment 14 SVN Robot 2013-05-06 14:21:06 UTC
"alg" committed SVN revision 1479578 into trunk:
i122216 Ensure FormControls get printed/PDFed, also ensure graphics are all v...