Issue 75867

Summary: Poor quality of OLE's alternative view ( bad looking metafiles for 3D charts, zoomfactor mismatch? )
Product: Draw Reporter: wolframgarten
Component: uiAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: Armin.Le.Grand, bjoern.milcke, clippka, IngridvdM, issues, mikhail.voytenko, thb, thomas.klarhoefer
Version: 680m202   
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 90135    
Attachments:
Description Flags
screenshot
none
screenshot old chart
none
new chart screenshot with correct mime type
none
screenshot new chart
none
62percent zoom old/new and inplace/outplace
none
100percent zoom old/new and inplace/outplace
none
ExampleDoc none

Description wolframgarten 2007-03-29 14:46:52 UTC
The alternative view of an OLE has very poor quality (please have a look at
screenshot). In edit mode this is much better.
Comment 1 wolframgarten 2007-03-29 14:53:08 UTC
Created attachment 44021 [details]
screenshot
Comment 2 wolframgarten 2007-03-29 14:58:06 UTC
Title and keyword added.
Comment 3 wolframgarten 2007-03-29 15:11:46 UTC
Adding kla to cc.
Comment 4 wolframgarten 2007-03-30 09:53:20 UTC
Created attachment 44045 [details]
screenshot old chart
Comment 5 wolframgarten 2007-03-30 09:54:03 UTC
Created attachment 44047 [details]
new chart screenshot with correct mime type
Comment 6 wolframgarten 2007-03-30 09:57:03 UTC
Created attachment 44051 [details]
screenshot new chart
Comment 7 IngridvdM 2007-03-30 16:01:16 UTC
Created attachment 44073 [details]
62percent zoom old/new and inplace/outplace
Comment 8 IngridvdM 2007-03-30 16:04:06 UTC
Created attachment 44074 [details]
100percent zoom old/new and inplace/outplace
Comment 9 IngridvdM 2007-03-30 16:21:17 UTC
This is not a new problem in the new chart, but already occurs for the old chart.
Look at the both screenshots I have attached.
On the left side you see the old chart on the right side the new chart.
In the top line you see the metafile replacement and on the bottom the inplace
edit mode.
For 100percent zoom all four images look the same ugly.
For 62percent zoom the metafile replacement looks significantly worse than the
edit mode.
So there seems to be a problem with the zoom factor.
Comment 10 IngridvdM 2007-03-30 16:25:57 UTC
Created attachment 44076 [details]
ExampleDoc
Comment 11 IngridvdM 2007-06-05 20:13:24 UTC
->Armin, please take over, as you have more insight in the creation of the
metafile from the 3D scene. Thanks a lot.
Comment 12 Armin Le Grand 2007-06-20 15:17:49 UTC
AW, IHA->CL: What we need is a parametrisation of GraphicExporter in UNO. ATM no
DPI can be handed over, thus the default-DPI from vcl VDev creation is used.
Please define parameters for handing over target DPIs.
Please define what parameters need to be passed over (DPI, Zoom?) and expand API
accordingly.
Comment 13 Armin Le Grand 2007-06-20 15:51:24 UTC
AW: Added myself to CC.
AW->CL: IHA will not take action, create a CWS and add tasks for it. Seems like
we need changes to GraphicExporter API and SdrOleObj::DpOaintObj. There. the
GetGraphic() will also need to pass parameters, but i do not know what xRef is
there and what APIs need to expanded there. Please use Your API knowledge to
give IHA hints about it.
Comment 14 clippka 2007-07-12 08:31:23 UTC
retargeting
Comment 15 IngridvdM 2007-07-12 16:10:12 UTC
To ease the pain with this issue I made a workaround - see issue 79544.
The chart uses the last known zoomfactor and sets it to the MapMode which is
used to create the MetaFile in UnoGraphicExporter. I added according properties
to the exporter.
This workaround cannot be applied for charts in impress, because in impress the
zoomfactor of the presentation mode is the most important. So I didn't change
the behaviour for 3D charts in impress and they will still look almost always
ugly there in edit mode.

So the root cause remains:
3D scenes are rendered as bitmaps and then used in supposedly resolution
independent metafiles.
Comment 16 bjoern.milcke 2007-07-19 17:35:59 UTC
Listening to this issue
Comment 17 clippka 2007-10-31 19:07:47 UTC
cl->iha: I'm currently completly unsure what the status of this is and what I
have do to. If I remember correctly you already added a resolution property to
the graphic exporter?
Comment 18 IngridvdM 2007-10-31 22:06:28 UTC
To solve this problem the applications need to ask the chart for a resolution
dependent output.
One way could be to use primitives instead of metafiles in the ole framework
communication. But that would be only possible with aw033.
To get an earlier solution either the applications need to ask for a resolution
dependent metafile or we avoid using metafiles completely and switch back to
direct rendering like we had it before OOo 2.0.
I can try to work on this together with mav, but not sure whether Impress has
special needs with its presentation view.
Christian, as this problem is worst in impress and you are an impress specialist
you maybe can help with that question: Are there specialties of ole object
display in the presentation view, or does it work like the ole display in the
edit mode for all applications?
Comment 19 clippka 2007-11-01 11:17:33 UTC
cl->iha: I add thb to cc, he can best answer your previous question
cl->thb: to the rescue!
Comment 20 thb 2007-11-01 21:30:55 UTC
@iha: no, currently the slideshow relies on a metafile being provided by the
XShape. There might be hacks possible to pass along required resolution, but I'd
hate to have them, shortly before aw033. Another possibility is to handle them
like embedded plugins or videos, which I have a task for anyway (for frame
support). Personally, I wouldn't mind waiting for aw033, instead of investing in
stop-gap solutions for one minor, though...
Comment 21 IngridvdM 2008-01-16 15:32:45 UTC
For the slideshow I implemented a workaround within issue 84569 (ooh680m2 and
src680m243). It works for normal full screen slideshow. The complete solution
for the slideshow is targeted with issue 84570.

For printing and pdf export I implemented a mechanism that avoids the usage of
meta file replacements for charts and creates correct resolution dependent
output (see issue 82893). The solution will be available in ooh680m2 and
src680m243 (look for CWS chart15).

This implementation could also be used for direct rendering of the chart during
the edit mode of the applications: In file
svx/source/svdraw/chartprettypainter.cxx  in method 
ChartPrettyPainter::ShouldPrettyPaintChartOnThisDevice return true at the end
instead of false.
But the painting of the SdrView is much slower than the painting of an accessory
meta file. Thus for performance reasons still meta files are used.

->cl: The chart now has all done what is reasonable possible here. Now it's up
to the draw team to speed up rendering or provide a complete different working
solution (primitives...). Please consider and plan accordingly.
Comment 22 wolframgarten 2008-05-23 15:11:47 UTC
Target changed.
Comment 23 kla 2008-06-11 07:26:31 UTC
*** Issue 90498 has been marked as a duplicate of this issue. ***
Comment 24 Marcus 2017-05-20 10:47:36 UTC
Reset assigne to the default "issues@openoffice.apache.org".