Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Poor quality of OLE's alternative view ( bad looking metafiles for 3D charts, zoomfactor mismatch? )|
|Component:||ui||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||Armin.Le.Grand, bjoern.milcke, clippka, IngridvdM, issues, mikhail.voytenko, thb, thomas.klarhoefer|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
|Issue Depends on:|
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 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 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
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
Comment 23 kla 2008-06-11 07:26:31 UTC
*** Issue 90498 has been marked as a duplicate of this issue. ***