Apache OpenOffice (AOO) Bugzilla – Issue 85715
Writer's RTL text rendered incorrectly when embedded via OLE in 3rd party application
Last modified: 2013-08-07 14:43:03 UTC
When emdedding a writer document with hebrew text into another (non OOo) document, the text appears completely garbled. I am attaching a simple writer document and a screenshot of the compound document, with this document embedded. You may notice that the hebrew word is misaligned. The metafile used in the OLE data transfer would probably need a SetTextAlign (..., TA_RIGHT) command before text output. When using more complext text, words are frequently rendered one on top of other. See second screenshot.
Created attachment 51253 [details] writer doc used for embedding
Created attachment 51254 [details] Screenshot
Created attachment 51255 [details] Additional screenshot
Created attachment 51492 [details] Screenshot from my OOo
Cannot reproduce the problem, as you can see from my screenshot. Are you sure, that you are working with the native build which can be downloaded from OOo website? Tested with OO 2.3.1 and OO 2.4 on Windows. Do you have OOo on Windows Vista?
Closed, not reproducible.
@mru: try the same thing e.g. with MS Word, or any other OLE container application, but not inside OOo. You will see something else...
It is a problem of the Container Application in creating the metafile display of the object. When you activate (double click) the object the formatting will be displayed fine.
It is true that the cause of the problem is with the metafile display. But OOo is responsible for the creation of the windows metafile, not the container application. The container application typically draws the object by calling OleDraw or IViewObject2.Draw. The metafile is provided by the object's implementation of IDataObject.GetData. If you embed the object into another OOo document, it is displayed fine, as (I assume) OOo internal metafile format is used, which is handled correctly. If you embed it into another container (and I tested it with a lot of containers, results are all the same), the OOo metafile is converted to a windows metafile, and this conversion is faulty with RTL text. And by the way, an embedded object is only useful, if it is displayed correctly in its passive state. Usually you want to create a proper printout. There actually two problems in the metafile conversion. 1. The layout mode recorded in the original OOo metafile is not read in the conversion to the windows metafile. But the flags TEXT_LAYOUT_BIDI_RTL, TEXT_LAYOUT_TEXTORIGIN_RIGHT and TEXT_LAYOUT_TEXTORIGIN_LEFT should be read and converted to the appropriate TA_LEFT, TA_RIGHT and TA_RTLREADING values, that should be applied to a META_SETTEXTALIGN record. 2. The hebrew unicode characters cannot be written to the windows metafile, instead a polygon replacement is used, leading to a substantial quality loss. If you determined the appropriate windows code page and windows font character set from the unicode characters, the polygon replacement could be avoided. I experimented with some hacks, which unfortunately haven't lead to a complete solution, but hopefully they will give some ideas. Adding functionality to the metafile conversion to overcome problem 1 is straightforward. I didn't have enough knowledge of your platform independent rtl_, font and code page support functions to come up with a solution for problem 2, though. So I fixed problem 1 in the conversion to the enhanced metafile format. Then I hacked into the IDataObject.QueryGetData implementation, forcing it to use the EMF instead of the WMF format: STDMETHODIMP EmbedDocument_Impl::QueryGetData( FORMATETC * pFormatetc ) { ... ... else if ( pFormatetc->cfFormat == CF_METAFILEPICT ) { // ugly hack return DV_E_FORMATETC; I'll attach my patch to the enhanced metafile conversion. This, together with the QueryGetData hack, fixes the described display problem. Unfortunately this also causes other problems with saving and loading the OOo object from the container application, so this is definitively not a solution. But it should outline the necessary actions. And please, reopen the issue. Thx
Created attachment 51514 [details] patch for svtools/source/filter.vcl/wmf/emfwr.hxx
Created attachment 51515 [details] patch for svtools/source/filter.vcl/wmf/emfwr.cxx
Reopened.
MRU->SJ. could you please have a look, if the attached patch could solve the mentioned metafile problem in third party applications?
just to clarify: this patch does not solve the problem itself. The logic of the performed changes should be also applied to wmfwr.cxx. In addition, additional steps are required to solve the problem with the output of unicode characters. See my comments above.
Created attachment 52359 [details] Patch for svtools/source/filter.vcl/wmf/wmfwr.cxx
Created attachment 52360 [details] Patch for svtools/source/filter.vcl/wmf/wmfwr.hxx
I made the equivalent changes to wmfwr.cxx, according to my previous patch to the enhanced metafile writer. I addition, I took a piece of code from the msword filter to convert the unicode string, which is not compatible to wmf, to its appropriate windows font character set. It seems to work fine. Please evaluate and integrate.
Thanks for your patch, I will evaluate and then integrate it.
The patch looks very good. I only needed to add the link dependency to i18nutil in the makefile of svtools. The patch will be integrated with cws[impress143].
this issue is ready to be verified in cws[impress143]
To reproduce the bug: - Insert the oletest.odt attachment as a OLE in an application (tested with Impress) - export the ole as a wmf graphic - import the graphic also in the Impress - the OLE and the imported wmf have to be identical. CGU: Verified in cws impress143
Checked fix in OOO300m3.