Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, On 27.10.2011 19:46, Regina Henschel wrote: Hi Armin, [..] No, I have not known, that they are possible now too. [..] So I have to do some additional tests. I would appreciate this. I hope it's fun to play with it :-) [..] I have updated my build and see the improvements :) Good. So, Your build is working now at last? [..] I'm working on it with Thorsten, it's solvable... That sounds great. I'm looking forward to the result of your teamwork. Opened #118558# (https://issues.apache.org/ooo/show_bug.cgi?id=118558) and added a patch similar to what Thorsten suggested. Not yet comitted, checking a bit more. I have written a Basic macro to set the background and line style to NONE. Developing it I have noticed, that the Math-objects do not support the services LineProperties and FillProperties. But I can set the single properties 'LineStyle' and 'FillStyle' and Xray lists all the other properties. So shouldn't they support these services? Not sure. StarMath is a regular OLE, so it should support LineProperties and FillProperties. But not inside StarMath itself, it's supported in the SdrObject containing the StarMath. There may be exceptions in the old code for StarMath. It's also possible that You used it in Writer which has it's own OLE implementation and does not (yet) support those new features...? I have used it in Draw and I'm on the OLE-object not on the StarMath model. The chart-object has the same problem. I have attached a document containing macros. Select 1 object and call TestService from module 'Diagnose' in Library 'RepairFormulas'. Thanks for the doc, I'll have a look. Kind regards Regina Sincerely, Armin -- ALG
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Armin, Armin Le Grand schrieb: Hi Regina, On 25.10.2011 18:33, Regina Henschel wrote: Hi Armin, Armin Le Grand schrieb: [..] I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. I did some further tests. Good, go ahead :-) Have You checked the converters? No, I have not known, that they are possible now too. It's even possible to convert charts directly to Sdr-3D-Objects (but not nice) :-) You can directly substract e.g. an ellipse from a chart, too. So I have to do some additional tests. In activated mode there should be no rot/shear and no green handles anymore (was an error anyways, modifying these while the OLE was activated leaded to unpredictable errors). Changing dimensions of the activated OLE will adapt to the centered OLE after deactivation as needed. I have updated my build and see the improvements :) [..] Documents made with LibreOffice are not converted. The background is blue and the line black. Is a solution possible inside AOOo? Should it be done? Source of this is that LO already has 3.4 version and the correction would have to be done for LO <= 3.4, plus writing OLEs with LINE_NONE and FILL_NONE if set (activating LineProperties/FillProperties for OLEs in LO, too). I'm already in contact with Thorsten and we are working on a solution for both together. I need to check if LO files can be detected and it looks like being possible. ODF exchange is very important for all of us, so there should be a correction in AOO at LO-created-file load time and mentioned corrections in LO, too. As described above, seen from ODF, OLEs are actually blue8 and hairline, so technically it's correctly displayed. Some other product using ODF FileFormat may have written such files where the OLEs are actually blue8 and hairline, so correction can only be done for known cases, e.g. OOo < 3.4 and LO <= 3.4 where we know for sure that the error was that the old paints just ignored LineStyle/FillStyle. I'm working on it with Thorsten, it's solvable... That sounds great. I'm looking forward to the result of your teamwork. I have written a Basic macro to set the background and line style to NONE. Developing it I have noticed, that the Math-objects do not support the services LineProperties and FillProperties. But I can set the single properties 'LineStyle' and 'FillStyle' and Xray lists all the other properties. So shouldn't they support these services? Not sure. StarMath is a regular OLE, so it should support LineProperties and FillProperties. But not inside StarMath itself, it's supported in the SdrObject containing the StarMath. There may be exceptions in the old code for StarMath. It's also possible that You used it in Writer which has it's own OLE implementation and does not (yet) support those new features...? I have used it in Draw and I'm on the OLE-object not on the StarMath model. The chart-object has the same problem. I have attached a document containing macros. Select 1 object and call TestService from module 'Diagnose' in Library 'RepairFormulas'. Kind regards Regina MakroInside for Armin.odg Description: application/vnd.oasis.opendocument.graphics
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, On 25.10.2011 18:33, Regina Henschel wrote: Hi Armin, Armin Le Grand schrieb: [..] I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. I did some further tests. Good, go ahead :-) Have You checked the converters? It's even possible to convert charts directly to Sdr-3D-Objects (but not nice) :-) You can directly substract e.g. an ellipse from a chart, too. In activated mode there should be no rot/shear and no green handles anymore (was an error anyways, modifying these while the OLE was activated leaded to unpredictable errors). Changing dimensions of the activated OLE will adapt to the centered OLE after deactivation as needed. I have taken some older documents, where the transformations are done via matrix (you know them). Chart and Math-Formulas behave now the same way as simple drawing objects. So that is OK. Good, thanks for checking. OOo sxd-documents are converted fine, the fill style and the line style is corrected to NONE. Yes, all OOo < 3.4 are corrected at load time. In ODF, no attributes for fill and line are set, so the default blue8/hairline is what is defined in the ODF, just because it was not set to none in the OLE constructors. I added that for OOo 3.3 but it failed since ODF export goes over UNO API and fill/line was not allowed for OLEs (which I also changed now). The change looks big, but it touches no too critical parts. It is also necessary to bring it in AOOo3.4, this change relies on a version change (here: 3.3 to 3.4) to be able to correct files written by OOo up to 3.3 (and only those). Some background: The root problem here was that older versions straight ignored attributes set at OLE objects by just not painting them. This means that in files generated the attributes are written and in plain ODF OLEs are filled default (blue8) and have line on default (black hairline). Documents made with LibreOffice are not converted. The background is blue and the line black. Is a solution possible inside AOOo? Should it be done? Source of this is that LO already has 3.4 version and the correction would have to be done for LO <= 3.4, plus writing OLEs with LINE_NONE and FILL_NONE if set (activating LineProperties/FillProperties for OLEs in LO, too). I'm already in contact with Thorsten and we are working on a solution for both together. I need to check if LO files can be detected and it looks like being possible. ODF exchange is very important for all of us, so there should be a correction in AOO at LO-created-file load time and mentioned corrections in LO, too. As described above, seen from ODF, OLEs are actually blue8 and hairline, so technically it's correctly displayed. Some other product using ODF FileFormat may have written such files where the OLEs are actually blue8 and hairline, so correction can only be done for known cases, e.g. OOo < 3.4 and LO <= 3.4 where we know for sure that the error was that the old paints just ignored LineStyle/FillStyle. I'm working on it with Thorsten, it's solvable... I have written a Basic macro to set the background and line style to NONE. Developing it I have noticed, that the Math-objects do not support the services LineProperties and FillProperties. But I can set the single properties 'LineStyle' and 'FillStyle' and Xray lists all the other properties. So shouldn't they support these services? Not sure. StarMath is a regular OLE, so it should support LineProperties and FillProperties. But not inside StarMath itself, it's supported in the SdrObject containing the StarMath. There may be exceptions in the old code for StarMath. It's also possible that You used it in Writer which has it's own OLE implementation and does not (yet) support those new features...? Questions/Comments are welcome, Armin Kind regards Regina Sincerely, Armin -- ALG
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Armin, Armin Le Grand schrieb: [..] I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. I did some further tests. I have taken some older documents, where the transformations are done via matrix (you know them). Chart and Math-Formulas behave now the same way as simple drawing objects. So that is OK. OOo sxd-documents are converted fine, the fill style and the line style is corrected to NONE. The change looks big, but it touches no too critical parts. It is also necessary to bring it in AOOo3.4, this change relies on a version change (here: 3.3 to 3.4) to be able to correct files written by OOo up to 3.3 (and only those). Some background: The root problem here was that older versions straight ignored attributes set at OLE objects by just not painting them. This means that in files generated the attributes are written and in plain ODF OLEs are filled default (blue8) and have line on default (black hairline). Documents made with LibreOffice are not converted. The background is blue and the line black. Is a solution possible inside AOOo? Should it be done? I have written a Basic macro to set the background and line style to NONE. Developing it I have noticed, that the Math-objects do not support the services LineProperties and FillProperties. But I can set the single properties 'LineStyle' and 'FillStyle' and Xray lists all the other properties. So shouldn't they support these services? Questions/Comments are welcome, Armin Kind regards Regina
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Armin, Armin Le Grand schrieb: [..] I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. [..] Questions/Comments are welcome, If an OLE-object contains another OLE, this is wrong placed. This happens, when you have got a Writer document with Math formula, which you want to show in a Draw document or in a presentation. The error is not new with your changes, but becomes worse. Perhaps now, as you are working in this area, you can have a look at the problem? I have attached test documents to issue 118527. Kind regards Regina
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, On Wed, Oct 19, 2011 at 01:10:10AM +0200, Regina Henschel wrote: > Hi Ariel, > > Ariel Constenla-Haile schrieb: > >Hi Regina, > > > >On Tue, Oct 18, 2011 at 12:22:39PM +0200, Regina Henschel wrote: > >>Do you have got a full MSVC or do you use a trick, that you does not > >>need --disable atl? > > > >I built it on my Uni (Universidad Nacional de La Plata), where they have > >powerful PCs (build took less than 2 hours) with full MSVisualStudio > >(AFAIK donated by MS). > > (1) Your configure contains nothing about disabling moz, but I > cannot reach macro security. The dialog does not open. > (2) Goto Tools -> Macros -> Organize Macros -> OpenOffice Basic. I > get a crash. > > Is there something special with your build, which I have not noticed? it uses the default at AOOo, which is disabling copy-left components, that's why mozilla is disabled by default, with no switch: http://svn.apache.org/viewvc/incubator/ooo/trunk/main/configure.in?view=markup#l1253 See http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201108.mbox/%3c20110831195300.gj29...@kulungile.erack.de%3E As Eike said, this is an issue, because you should be able to set the macro security level (only the "Trusted Sources" tab should be removed or disabled). Regards -- Ariel Constenla-Haile La Plata, Argentina pgpI9HboN190P.pgp Description: PGP signature
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Ariel, Ariel Constenla-Haile schrieb: Hi Regina, On Tue, Oct 18, 2011 at 12:22:39PM +0200, Regina Henschel wrote: Do you have got a full MSVC or do you use a trick, that you does not need --disable atl? I built it on my Uni (Universidad Nacional de La Plata), where they have powerful PCs (build took less than 2 hours) with full MSVisualStudio (AFAIK donated by MS). (1) Your configure contains nothing about disabling moz, but I cannot reach macro security. The dialog does not open. (2) Goto Tools -> Macros -> Organize Macros -> OpenOffice Basic. I get a crash. Is there something special with your build, which I have not noticed? Kind regards Regina
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, On Tue, Oct 18, 2011 at 12:22:39PM +0200, Regina Henschel wrote: > Do you have got a full MSVC or do you use a trick, that you does not > need --disable atl? I built it on my Uni (Universidad Nacional de La Plata), where they have powerful PCs (build took less than 2 hours) with full MSVisualStudio (AFAIK donated by MS). Regards -- Ariel Constenla-Haile La Plata, Argentina pgplEgeAXGGar.pgp Description: PGP signature
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Armin, I have got a full OLE feature build from Ariel and could do some further tests. Armin Le Grand schrieb: I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. Make a DINA6 document in Writer with two pages. In my test case it includes a linked picture. Export to a pdf-file. Start a new Draw document. Insert the pdf-file via Insert > Object > OLE-object > Further objects [The way via 'from file' does not work, but that was already wrong in OOo3.3] Then 'Adobe Acrobat Document' and 'from file'. The Acrobat Reader opens, here in German, exit with 'Datei' > 'Beenden und zurück zu (null)'. Save the document. Sometimes the dialog 'ASCII Filter Options' comes up, but I cannot reproduce it reliable. In such a case click 'Cancel', the file is saved nevertheless. Reopen the document. Doubleclick the OLE. The Acrobat Reader opens. Switch to second page there and go back to Draw. Do something with the OLE, for example rotate a little bit. Again doubleclick the OLE and switch page in Acrobat Reader. Go back to Draw. Do something and again switch the page. Notice, that the OLE-object in Draw does not always show the chosen page. It seem so work immediately after a reload, but no longer if you have done something. Kind regards Regina
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Ariel, Ariel Constenla-Haile schrieb: Hi Regina, *, On Sun, Oct 16, 2011 at 11:23:35PM +0200, Regina Henschel wrote: Hi Dennis, Dennis E. Hamilton schrieb: While attention is on the topic of rendering control for OLE objects, I have questions: How does this modification show up in the ODF XML surrounding the OLE object (element)? In addition Also, one problem that has been a source of complaint is failure to preserve cropping of the rendering of an OLE object. Is that covered also? I cannot test it, because the Express edition of MSVC does not contain all things to compile the OLE-feature. @Armin: Can you provide a full Windows-build for testing? You can give a try at my build: http://dl.dropbox.com/u/17375654/OOo_3.4.0_Win_x86_install_en-US.exe http://dl.dropbox.com/u/17375654/OOo-SDK_3.4_Win_x86_install_en-US.exe I'm not sure if you'll be able to install it, or even run it (you may need some win redistributable not included in the install set), but may be it's worth giving it a try. I could unpack and install it without problems. Thanks. It's made with --enable-dbgutil, see http://ooo-wiki.apache.org/wiki/Non_Product_Build You may select Error = Window, because MessageBox is rather annoying. Yes, collecting in a window is better. It's based on git-svn-id: https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main@1183367 13f79535-47bb-0310-9956-ffa450edef68 I used the following switches: $ ./configure --with-external-tar="Y:/ext_sources" --with-cl-home="/cygdrive/c/ARCHIV~1/MICROS~1.0/VC" --with-mspdb-path="/cygdrive/c/ARCHIV~1/MICROS~1.0/Common7/IDE" --with-frame-home="/cygdrive/c/ARCHIV~1/MICROS~3/Windows/v6.1" --with-psdk-home="/cygdrive/c/ARCHIV~1/MICROS~3/Windows/v6.1" --with-midl-path="/cygdrive/c/ARCHIV~1/MICROS~3/Windows/v6.1/Bin" --with-asm-home="/cygdrive/c/ARCHIV~1/MICROS~1.0/VC/bin" --with-csc-path="/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5" --with-jdk-home="/cygdrive/c/ARCHIV~1/Java/JDK16~2.0_1" --with-ant-home="/cygdrive/c/apache-ant-1.7.1" --enable-minimizer --enable-presenter-console --enable-pdfimport --enable-wiki-publisher --enable-report-builder --enable-verbose --enable-mysql-connector --with-libmysql-path="C:/ARCHIV~1/MySQL/MYSQLC~1.2" --disable-strip-solver --enable-dbgutil --with-directx-home="/cygdrive/c/ARCHIV~1/MI599E~1" Do you have got a full MSVC or do you use a trick, that you does not need --disable atl? One should always build with --enable-dbgutil, it's quite useful. For example, when selecting any of the Modify - Convert options with an OLE object, you get the following error: Error: Falsche VerbId! From File y:/apache/trunk/main/sfx2/source/control/shell.cxx at Line 1201 Sometimes this kind of errors indicate a real error, sometimes not; but it's worth looking at it. I hope AOOo keeps the high level, that it compiles on Windows with --enable-dbgutil. In LibO it doesn't build at all for me in the moment. But discussion about quality of master would have to be a new thread. Kind regards Regina
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, *, On Sun, Oct 16, 2011 at 11:23:35PM +0200, Regina Henschel wrote: > Hi Dennis, > > Dennis E. Hamilton schrieb: > >While attention is on the topic of rendering control for OLE objects, > >I have questions: > > > >How does this modification show up in the ODF XML surrounding the > >OLE object (element)? > > > >In addition Also, one problem that has been a source of complaint is > >failure to preserve cropping of the rendering of an OLE object. Is > >that covered also? > > I cannot test it, because the Express edition of MSVC does not > contain all things to compile the OLE-feature. > > @Armin: Can you provide a full Windows-build for testing? You can give a try at my build: http://dl.dropbox.com/u/17375654/OOo_3.4.0_Win_x86_install_en-US.exe http://dl.dropbox.com/u/17375654/OOo-SDK_3.4_Win_x86_install_en-US.exe I'm not sure if you'll be able to install it, or even run it (you may need some win redistributable not included in the install set), but may be it's worth giving it a try. It's made with --enable-dbgutil, see http://ooo-wiki.apache.org/wiki/Non_Product_Build You may select Error = Window, because MessageBox is rather annoying. It's based on git-svn-id: https://svn-master.apache.org/repos/asf/incubator/ooo/trunk/main@1183367 13f79535-47bb-0310-9956-ffa450edef68 I used the following switches: $ ./configure --with-external-tar="Y:/ext_sources" --with-cl-home="/cygdrive/c/ARCHIV~1/MICROS~1.0/VC" --with-mspdb-path="/cygdrive/c/ARCHIV~1/MICROS~1.0/Common7/IDE" --with-frame-home="/cygdrive/c/ARCHIV~1/MICROS~3/Windows/v6.1" --with-psdk-home="/cygdrive/c/ARCHIV~1/MICROS~3/Windows/v6.1" --with-midl-path="/cygdrive/c/ARCHIV~1/MICROS~3/Windows/v6.1/Bin" --with-asm-home="/cygdrive/c/ARCHIV~1/MICROS~1.0/VC/bin" --with-csc-path="/cygdrive/c/WINDOWS/Microsoft.NET/Framework/v3.5" --with-jdk-home="/cygdrive/c/ARCHIV~1/Java/JDK16~2.0_1" --with-ant-home="/cygdrive/c/apache-ant-1.7.1" --enable-minimizer --enable-presenter-console --enable-pdfimport --enable-wiki-publisher --enable-report-builder --enable-verbose --enable-mysql-connector --with-libmysql-path="C:/ARCHIV~1/MySQL/MYSQLC~1.2" --disable-strip-solver --enable-dbgutil --with-directx-home="/cygdrive/c/ARCHIV~1/MI599E~1" One should always build with --enable-dbgutil, it's quite useful. For example, when selecting any of the Modify - Convert options with an OLE object, you get the following error: Error: Falsche VerbId! From File y:/apache/trunk/main/sfx2/source/control/shell.cxx at Line 1201 Sometimes this kind of errors indicate a real error, sometimes not; but it's worth looking at it. Regards -- Ariel Constenla-Haile La Plata, Argentina pgp3AQg5B0TxG.pgp Description: PGP signature
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, On 16.10.2011 23:23, Regina Henschel wrote: Hi Dennis, Dennis E. Hamilton schrieb: While attention is on the topic of rendering control for OLE objects, I have questions: How does this modification show up in the ODF XML surrounding the OLE object (element)? In addition Also, one problem that has been a source of complaint is failure to preserve cropping of the rendering of an OLE object. Is that covered also? I cannot test it, because the Express edition of MSVC does not contain all things to compile the OLE-feature. @Armin: Can you provide a full Windows-build for testing? Sorry, I'm currently on something else urgently needed and have no current build of that fixes. I hope You can get Your build working, this will help more in the future. Despite that, I would not know a place currently where to put such huge binary blobs. Is there a place similar to http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/ ? Kind regards Regina - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Sunday, October 16, 2011 12:58 To: ooo-dev@incubator.apache.org Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# [..] Sincerely, Armin -- ALG
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Dennis, On 17.10.2011 17:55, Dennis E. Hamilton wrote: Hi Regina, Thank you for the complete markup. It is clear what is happening now. As Regina wrote, the transformation is applied to the draw:frame, thus used for the OLE itself and the fallback representation. The fallback representation is a draw:image and thus also transformable (added the shear ability for fully guaranteeing this). Thus, if the OLE or the fallback representation is used, transformation will be applied as defined. The text is added to the draw:object-ole only, not to the draw:image fallback representation. There is no cropping yet since a missing cropping was not reported to me. In principle it could be added, too. I guess it's too much for 3.4 now, but please forward and/or write a task describing this for me. BTW: Cropping has the bug that it does not work (the interaction part, not sure about displaying) with rotated shapes currently; when it was designed it was completely forgotten that shapes may be rotated/sheared (or generally: transformed). There is a task for this somewhere, though. Not sure if I understood the Win/MSOffice stuff, but please describe the (obviously a compatibility) feature in that task we will need for this. I think that you can't click on the rendered image because it is the that your build is using as an alternative to the . Presumably that was made from the rendering that was done when the OLE object was embedded and the document saved. The use of the is expected when the client doesn't recognize/support the or it doesn't have the application required to activate the embedded OLE object. This can happen because the client is not running Windows or it is on Windows but the application that served the OLE object is not available. (At one time, Microsoft Office would report the lack of application to users and offer to substitute the static image that had been retained at the same time, making it then a non-OLE editable image. I'm not clear what happens in current releases of Office.) The case that concerns me is that the transformation has to be applicable to all forms of the image or there is some rule for knowing which image for the transformation applies to, since it can only be specified once for the. Also, for cropping/clipping, that is different than scroll bars and such on a recognized OLE embedding. It would apply to the as well. This happens with .doc and users are unhappy when the .odt version loses the cropping, forces shrinking of the full image onto the page, etc., and there is no way to fix it. I think this is partly an ODF problem and also an OO.o problem. - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Monday, October 17, 2011 06:22 To: ooo-dev@incubator.apache.org Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# Hi Dennis, Dennis E. Hamilton schrieb: Regina, That looks good. Is the the only child of the? No, it has a draw:image element for the replacement graphic. I'm asking because I wonder what is needed in the ODF specification with regard to attributes when there are alternative images among the children. E.g., if there were a and a there together. The full node is: Dies ist eine Beschreibung. The wrong class-id is likely because my build does not support OLE, that is, I cannot activate the object via doubleclick. (I also see that cropping doesn't seem to be handled very easily.) There is no cropping on the frame, but for OLE-objects, which belong to ODF, the position of the active part is determined by the scrollbars and the grey edges in the activated object. But for real tests I would need a build including full OLE feature. I think Armin should tell you about cropping. Kind regards Regina - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Sunday, October 16, 2011 14:42 To: ooo-dev@incubator.apache.org Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# Hi Dennis, Dennis E. Hamilton schrieb: While attention is on the topic of rendering control for OLE objects, I have questions: How does this modification show up in the ODF XML surrounding the OLE object (element)? When I test it with a file, where the OLE-object is already inserted, then I see, that the transformation is done in the parent element with the draw:transform attribute. Kind regards Regina
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, On 16.10.2011 21:57, Regina Henschel wrote: Hi Armin, Armin Le Grand schrieb: [..] I played a bit around, you know I'm happy to try out new things. Regina, this is more than welcome. I'll have a look at these ASAP. Take a Draw-document. Insert a default chart. Rotate the chart 90°. Set chart to edit mode. Drag the grey edge to change the size of the chart. Leave edit mode. Notice, the chart jumps to top of page. Expected behavior: Resize is done centered to old position or relative to the opposite site of the dragged one. Take a Impress-document. Insert a default chart. Rotate the chart 90°. Switch to presentation mode. Notice the chart has the size of the rotated one, but is not rotated but scaled to fit the rotated size. (People might want to rotate charts in presentations, because a combined bar-line chart is not available but only a combined column-line chart.) Kind regards Regina Sincerely, Armin -- ALG
RE: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Regina, Thank you for the complete markup. It is clear what is happening now. I think that you can't click on the rendered image because it is the that your build is using as an alternative to the . Presumably that was made from the rendering that was done when the OLE object was embedded and the document saved. The use of the is expected when the client doesn't recognize/support the or it doesn't have the application required to activate the embedded OLE object. This can happen because the client is not running Windows or it is on Windows but the application that served the OLE object is not available. (At one time, Microsoft Office would report the lack of application to users and offer to substitute the static image that had been retained at the same time, making it then a non-OLE editable image. I'm not clear what happens in current releases of Office.) The case that concerns me is that the transformation has to be applicable to all forms of the image or there is some rule for knowing which image for the transformation applies to, since it can only be specified once for the . Also, for cropping/clipping, that is different than scroll bars and such on a recognized OLE embedding. It would apply to the as well. This happens with .doc and users are unhappy when the .odt version loses the cropping, forces shrinking of the full image onto the page, etc., and there is no way to fix it. I think this is partly an ODF problem and also an OO.o problem. - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Monday, October 17, 2011 06:22 To: ooo-dev@incubator.apache.org Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# Hi Dennis, Dennis E. Hamilton schrieb: > Regina, > > That looks good. Is the the only child of > the? No, it has a draw:image element for the replacement graphic. > > I'm asking because I wonder what is needed in the ODF specification with > regard to attributes when there are alternative images among > the > children. E.g., if there were a and a > there together. The full node is: Dies ist eine Beschreibung. The wrong class-id is likely because my build does not support OLE, that is, I cannot activate the object via doubleclick. > > (I also see that cropping doesn't seem to be handled very easily.) There is no cropping on the frame, but for OLE-objects, which belong to ODF, the position of the active part is determined by the scrollbars and the grey edges in the activated object. But for real tests I would need a build including full OLE feature. I think Armin should tell you about cropping. Kind regards Regina > > - Dennis > > -Original Message- > From: Regina Henschel [mailto:rb.hensc...@t-online.de] > Sent: Sunday, October 16, 2011 14:42 > To: ooo-dev@incubator.apache.org > Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# > > Hi Dennis, > > Dennis E. Hamilton schrieb: >> While attention is on the topic of rendering control for OLE objects, >> I have questions: >> >> How does this modification show up in the ODF XML surrounding the >> OLE object (element)? > > When I test it with a file, where the OLE-object is already inserted, > then I see, that the transformation is done in the parent element > with the draw:transform attribute. > > Kind regards > Regina smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Dennis, Dennis E. Hamilton schrieb: Regina, That looks good. Is the the only child of the? No, it has a draw:image element for the replacement graphic. I'm asking because I wonder what is needed in the ODF specification with regard to attributes when there are alternative images among the children. E.g., if there were a and a there together. The full node is: draw:layer="layout" svg:width="8.889cm" svg:height="6.307cm" draw:transform="rotate (0.5235987755982) translate (8.02cm 9.642cm)">draw:class-id="----" xlink:href="./Object 1" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad">Dies ist eine Beschreibung.xlink:href="./ObjectReplacements/Object 1" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad"/> The wrong class-id is likely because my build does not support OLE, that is, I cannot activate the object via doubleclick. (I also see that cropping doesn't seem to be handled very easily.) There is no cropping on the frame, but for OLE-objects, which belong to ODF, the position of the active part is determined by the scrollbars and the grey edges in the activated object. But for real tests I would need a build including full OLE feature. I think Armin should tell you about cropping. Kind regards Regina - Dennis -Original Message----- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Sunday, October 16, 2011 14:42 To: ooo-dev@incubator.apache.org Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# Hi Dennis, Dennis E. Hamilton schrieb: While attention is on the topic of rendering control for OLE objects, I have questions: How does this modification show up in the ODF XML surrounding the OLE object (element)? When I test it with a file, where the OLE-object is already inserted, then I see, that the transformation is done in the parent element with the draw:transform attribute. Kind regards Regina
RE: [PATCH] Fix for #118485#, #108221#, #67705#
Regina, That looks good. Is the the only child of the ? I'm asking because I wonder what is needed in the ODF specification with regard to attributes when there are alternative images among the children. E.g., if there were a and a there together. (I also see that cropping doesn't seem to be handled very easily.) - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Sunday, October 16, 2011 14:42 To: ooo-dev@incubator.apache.org Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# Hi Dennis, Dennis E. Hamilton schrieb: > While attention is on the topic of rendering control for OLE objects, > I have questions: > > How does this modification show up in the ODF XML surrounding the > OLE object (element)? When I test it with a file, where the OLE-object is already inserted, then I see, that the transformation is done in the parent element with the draw:transform attribute. Kind regards Regina smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Dennis, Dennis E. Hamilton schrieb: While attention is on the topic of rendering control for OLE objects, I have questions: How does this modification show up in the ODF XML surrounding the OLE object (element)? When I test it with a file, where the OLE-object is already inserted, then I see, that the transformation is done in the parent element with the draw:transform attribute. Kind regards Regina
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Dennis, Dennis E. Hamilton schrieb: While attention is on the topic of rendering control for OLE objects, I have questions: How does this modification show up in the ODF XML surrounding the OLE object (element)? In addition Also, one problem that has been a source of complaint is failure to preserve cropping of the rendering of an OLE object. Is that covered also? I cannot test it, because the Express edition of MSVC does not contain all things to compile the OLE-feature. @Armin: Can you provide a full Windows-build for testing? Is there a place similar to http://ooo.services.openoffice.org/pub/OpenOffice.org/cws/upload/ ? Kind regards Regina - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Sunday, October 16, 2011 12:58 To: ooo-dev@incubator.apache.org Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# Hi Armin, Armin Le Grand schrieb: Hi *, I took some days to fix that long missing OLE-Attribute feature/bug. It is on one hand a missing feature (no reason to not apply attributes and transformations to OLE which contains the same as graphical object, a MetaFile) and on the other a compatibility issue with a big competitor which is able to add attributes to OLEs for a long time. This fix was already prepared in #67705# but could not be activated due to a missing part of #108221#. Thanks to ORW (aka Oliver-Rainer) which helped to solve that. The patch adds LineStyle, FillStyle, Text, Shadow, Shear and Rotate to OLE objects in Draw/Impress and Calc. It adds Shear to graphic objects. It also fixes some long existing not detected bugs to make all this work. It leaves OLEs and graphical objects for Writer (SW) untouched due to the fact that SW uses it's own implementations for those (one more argument for the long missing consolidation in SW to use DrawingLayer objects for this). [..] I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. I played a bit around, you know I'm happy to try out new things. Take a Draw-document. Insert a default chart. Rotate the chart 90°. Set chart to edit mode. Drag the grey edge to change the size of the chart. Leave edit mode. Notice, the chart jumps to top of page. Expected behavior: Resize is done centered to old position or relative to the opposite site of the dragged one. Take a Impress-document. Insert a default chart. Rotate the chart 90°. Switch to presentation mode. Notice the chart has the size of the rotated one, but is not rotated but scaled to fit the rotated size. (People might want to rotate charts in presentations, because a combined bar-line chart is not available but only a combined column-line chart.) Kind regards Regina
RE: [PATCH] Fix for #118485#, #108221#, #67705#
While attention is on the topic of rendering control for OLE objects, I have questions: How does this modification show up in the ODF XML surrounding the OLE object (element )? In addition Also, one problem that has been a source of complaint is failure to preserve cropping of the rendering of an OLE object. Is that covered also? - Dennis -Original Message- From: Regina Henschel [mailto:rb.hensc...@t-online.de] Sent: Sunday, October 16, 2011 12:58 To: ooo-dev@incubator.apache.org Subject: Re: [PATCH] Fix for #118485#, #108221#, #67705# Hi Armin, Armin Le Grand schrieb: > Hi *, > > I took some days to fix that long missing OLE-Attribute feature/bug. It > is on one hand a missing feature (no reason to not apply attributes and > transformations to OLE which contains the same as graphical object, a > MetaFile) and on the other a compatibility issue with a big competitor > which is able to add attributes to OLEs for a long time. > > This fix was already prepared in #67705# but could not be activated due > to a missing part of #108221#. Thanks to ORW (aka Oliver-Rainer) which > helped to solve that. > > The patch adds LineStyle, FillStyle, Text, Shadow, Shear and Rotate to > OLE objects in Draw/Impress and Calc. It adds Shear to graphic objects. > It also fixes some long existing not detected bugs to make all this > work. It leaves OLEs and graphical objects for Writer (SW) untouched due > to the fact that SW uses it's own implementations for those (one more > argument for the long missing consolidation in SW to use DrawingLayer > objects for this). [..] > > I checked all changes again and added the patch to #118485#. Now I'm > looking for someone volunteering to add the patch, build AOOo and play > around with OLEs a little bit, reading the patch will also help in this > case, it's not too big to do so. I played a bit around, you know I'm happy to try out new things. Take a Draw-document. Insert a default chart. Rotate the chart 90°. Set chart to edit mode. Drag the grey edge to change the size of the chart. Leave edit mode. Notice, the chart jumps to top of page. Expected behavior: Resize is done centered to old position or relative to the opposite site of the dragged one. Take a Impress-document. Insert a default chart. Rotate the chart 90°. Switch to presentation mode. Notice the chart has the size of the rotated one, but is not rotated but scaled to fit the rotated size. (People might want to rotate charts in presentations, because a combined bar-line chart is not available but only a combined column-line chart.) Kind regards Regina
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Armin, Armin Le Grand schrieb: Hi *, I took some days to fix that long missing OLE-Attribute feature/bug. It is on one hand a missing feature (no reason to not apply attributes and transformations to OLE which contains the same as graphical object, a MetaFile) and on the other a compatibility issue with a big competitor which is able to add attributes to OLEs for a long time. This fix was already prepared in #67705# but could not be activated due to a missing part of #108221#. Thanks to ORW (aka Oliver-Rainer) which helped to solve that. The patch adds LineStyle, FillStyle, Text, Shadow, Shear and Rotate to OLE objects in Draw/Impress and Calc. It adds Shear to graphic objects. It also fixes some long existing not detected bugs to make all this work. It leaves OLEs and graphical objects for Writer (SW) untouched due to the fact that SW uses it's own implementations for those (one more argument for the long missing consolidation in SW to use DrawingLayer objects for this). [..] I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. I played a bit around, you know I'm happy to try out new things. Take a Draw-document. Insert a default chart. Rotate the chart 90°. Set chart to edit mode. Drag the grey edge to change the size of the chart. Leave edit mode. Notice, the chart jumps to top of page. Expected behavior: Resize is done centered to old position or relative to the opposite site of the dragged one. Take a Impress-document. Insert a default chart. Rotate the chart 90°. Switch to presentation mode. Notice the chart has the size of the rotated one, but is not rotated but scaled to fit the rotated size. (People might want to rotate charts in presentations, because a combined bar-line chart is not available but only a combined column-line chart.) Kind regards Regina
Replacing nss with OpenSSL (was Re: [PATCH] Fix for #118485#, #108221#, #67705#)
--- On Thu, 10/13/11, Herbert Duerr wrote: ... > > - Use of OpenSSL instead of nss for AES encryption. > > I'm looking into replacing nss by openssl for encryption > and signing of documents. NSS is currently also responsible > for key and certificate management and replacing that seems > to be the really tricky part... > Thanks for working on this! FWIW, Apache has something for that: http://santuario.apache.org/cindex.html but then this FAQ is interesting: _ 1.2. Does the library provide a full C++ wrapper for OpenSSL? The C++ crypto interface layer provided for the library provides only the smallest subset of cryptographic functions necessary for the library to make calls to the provided library. Applications will need to work directly with OpenSSL (or other libraries) to read and manipulate encryption keys that should then be wrapped in XSECCrypto* objects and passed into the library. _ Pedro.
Re: [PATCH] Fix for #118485#, #108221#, #67705#
On Wed, Oct 12, 2011 at 5:47 PM, Pedro Giffuni wrote: > Hi; > > --- On Wed, 10/12/11, Armin Le Grand wrote: > > > Hi Pedro, > > > > On 12.10.2011 03:43, Pedro Giffuni wrote: > > > Hi; > > > > > > I committed it as revision 1182166, and noted it in > > > the bug report, but I admit the patch was too big to do > > > a review on it. > > > > Thanks for comitting. I think - as i wrote - for someone > > knowing the core it would have been possible to read the > > diffs. This is not too big from my POV, I have bigger > > changes in the pipeline. > > > > Oh yes, it was not that big, but it touched a lot of files > which made it difficult to get the context. In any case > big patches are sometimes necessary and I was confident > this wouldn't go bad: it was my way of saying "this guy > should be a committer so he can fix the stuff he breaks" > :), > > +1 Juergen
Re: [PATCH] Fix for #118485#, #108221#, #67705#
On Thu, Oct 13, 2011 at 3:00 AM, Herbert Duerr wrote: > On 10/12/2011 05:47 PM, Pedro Giffuni wrote: >> [...] >> >> Oh yes, it was not that big, but it touched a lot of files >> which made it difficult to get the context. In any case >> big patches are sometimes necessary and I was confident >> this wouldn't go bad: it was my way of saying "this guy >> should be a committer so he can fix the stuff he breaks" >> :), > > Armin should definitely become a committer soon. I'm no longer sure how that > process works. I had sent a vote request regarding Ariel to the private list > but for some reason it did not get there. I even sent it through the apache > SMTP using my @apache.org email address, but it still didn't suffice to let > it through. > Are you subscribed to the ooo-private list? Notes from subscribers, sent from the address they subscribed from, are not moderated. Notes sent from non-subscribers are forwarded to the moderators, but that should only introduce a short delay, at most a few hours. The process for voting in a new committer is described in the Podling Guide here: http://incubator.apache.org/guides/ppmc.html -Rob >> Another thing is that we should be focusing on removing >> copyleft components and perhaps some cleanups before >> doing enhancements. I specifically want to avoid the >> situation in LO where the code and the configuration >> options keep growing and growing without control to >> the point where patches occasionally make gcc run >> out of memory. > > yes. > >> [...] >> - Use of OpenSSL instead of nss for AES encryption. > > I'm looking into replacing nss by openssl for encryption and signing of > documents. NSS is currently also responsible for key and certificate > management and replacing that seems to be the really tricky part... > > Herbert >
Re: [PATCH] Fix for #118485#, #108221#, #67705#
On 10/12/2011 05:47 PM, Pedro Giffuni wrote: > [...] Oh yes, it was not that big, but it touched a lot of files which made it difficult to get the context. In any case big patches are sometimes necessary and I was confident this wouldn't go bad: it was my way of saying "this guy should be a committer so he can fix the stuff he breaks" :), Armin should definitely become a committer soon. I'm no longer sure how that process works. I had sent a vote request regarding Ariel to the private list but for some reason it did not get there. I even sent it through the apache SMTP using my @apache.org email address, but it still didn't suffice to let it through. Another thing is that we should be focusing on removing copyleft components and perhaps some cleanups before doing enhancements. I specifically want to avoid the situation in LO where the code and the configuration options keep growing and growing without control to the point where patches occasionally make gcc run out of memory. yes. [...] - Use of OpenSSL instead of nss for AES encryption. I'm looking into replacing nss by openssl for encryption and signing of documents. NSS is currently also responsible for key and certificate management and replacing that seems to be the really tricky part... Herbert
Re: [PATCH] Fix for #118485#, #108221#, #67705#
On Wed, Oct 12, 2011 at 11:47 AM, Pedro Giffuni wrote: > Hi; > > --- On Wed, 10/12/11, Armin Le Grand wrote: > >> Hi Pedro, >> >> On 12.10.2011 03:43, Pedro Giffuni wrote: >> > Hi; >> > >> > I committed it as revision 1182166, and noted it in >> > the bug report, but I admit the patch was too big to do >> > a review on it. >> >> Thanks for comitting. I think - as i wrote - for someone >> knowing the core it would have been possible to read the >> diffs. This is not too big from my POV, I have bigger >> changes in the pipeline. >> > > Oh yes, it was not that big, but it touched a lot of files > which made it difficult to get the context. In any case > big patches are sometimes necessary and I was confident > this wouldn't go bad: it was my way of saying "this guy > should be a committer so he can fix the stuff he breaks" > :), > +1 > Another thing is that we should be focusing on removing > copyleft components and perhaps some cleanups before > doing enhancements. I specifically want to avoid the > situation in LO where the code and the configuration > options keep growing and growing without control to > the point where patches occasionally make gcc run > out of memory. > > I am very likely to commit stuff in these lines if I > get good patches: > > - Removal of libegg. > - Use of OpenSSL instead of nss for AES encryption. > - replacement of glibc (already discussed in the list) > - Updates to the scanner (sane and twain) headers. > - Updating ICC. > - Bring back Xalan. > - Replace Rhino with V8 ! > > And the list will probably grow as ideas keep coming in ;-) > > Pedro. >
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi; --- On Wed, 10/12/11, Armin Le Grand wrote: > Hi Pedro, > > On 12.10.2011 03:43, Pedro Giffuni wrote: > > Hi; > > > > I committed it as revision 1182166, and noted it in > > the bug report, but I admit the patch was too big to do > > a review on it. > > Thanks for comitting. I think - as i wrote - for someone > knowing the core it would have been possible to read the > diffs. This is not too big from my POV, I have bigger > changes in the pipeline. > Oh yes, it was not that big, but it touched a lot of files which made it difficult to get the context. In any case big patches are sometimes necessary and I was confident this wouldn't go bad: it was my way of saying "this guy should be a committer so he can fix the stuff he breaks" :), Another thing is that we should be focusing on removing copyleft components and perhaps some cleanups before doing enhancements. I specifically want to avoid the situation in LO where the code and the configuration options keep growing and growing without control to the point where patches occasionally make gcc run out of memory. I am very likely to commit stuff in these lines if I get good patches: - Removal of libegg. - Use of OpenSSL instead of nss for AES encryption. - replacement of glibc (already discussed in the list) - Updates to the scanner (sane and twain) headers. - Updating ICC. - Bring back Xalan. - Replace Rhino with V8 ! And the list will probably grow as ideas keep coming in ;-) Pedro.
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi Pedro, On 12.10.2011 03:43, Pedro Giffuni wrote: Hi; I committed it as revision 1182166, and noted it in the bug report, but I admit the patch was too big to do a review on it. Thanks for comitting. I think - as i wrote - for someone knowing the core it would have been possible to read the diffs. This is not too big from my POV, I have bigger changes in the pipeline. At least I'm here to fix tasks regarding this change if there should be some. I was very careful (similar to the big Geometry/AntiAliasing change I made), but You never know :-) It was evidently a lot of work that I would hate to see ignored and, if I understand well, this was like *really* broken (3 issues) but in the future I will try to avoid committing these big patches without someone else reviewing it first. Pedro. --- On Tue, 10/11/11, Armin Le Grand wrote: ... Hi *, I took some days to fix that long missing OLE-Attribute feature/bug. It is on one hand a missing feature (no reason to not apply attributes and transformations to OLE which contains the same as graphical object, a MetaFile) and on the other a compatibility issue with a big competitor which is able to add attributes to OLEs for a long time. This fix was already prepared in #67705# but could not be activated due to a missing part of #108221#. Thanks to ORW (aka Oliver-Rainer) which helped to solve that. The patch adds LineStyle, FillStyle, Text, Shadow, Shear and Rotate to OLE objects in Draw/Impress and Calc. It adds Shear to graphic objects. It also fixes some long existing not detected bugs to make all this work. It leaves OLEs and graphical objects for Writer (SW) untouched due to the fact that SW uses it's own implementations for those (one more argument for the long missing consolidation in SW to use DrawingLayer objects for this). Details are documented in https://issues.apache.org/ooo/show_bug.cgi?id=118485, but here is a list: - Added LineStyle, FillStyle, Text, Shadow, Shear, Rotate to OLE - Added Shear to GraphicObjects - Adapted context menus in Draw/Impress, Calc - Adapted UNO API to allow these attribute families for those object types - Adapted interactors to show a correct preview for interactions - Adapted ConvertTo to take set attributes into account (was completely missing for GraphicObjects, a bug on it's own). - Adapted Text edit activation (press any key to start typing), activation on Return stays untouched - Adapted OLE activation to be centered to the now eventually rotated/sheared object bounds - Adapted MetaFile-ToSdrObject converter, transformations are now applied to the created SdrObjects. Deactivated one erroneous Item in text attribute creation which leads to bad errors in text generation, wrote f'up #118498# for it (HDU) - Adapted Import/Export to take care of added text - Added correction for earlier written OOo ODF files at load time - Activated the prepared attribute visualization in the OLE Primitive - Corrected attribute generation for newly created OLEs I checked all changes again and added the patch to #118485#. Now I'm looking for someone volunteering to add the patch, build AOOo and play around with OLEs a little bit, reading the patch will also help in this case, it's not too big to do so. The change looks big, but it touches no too critical parts. It is also necessary to bring it in AOOo3.4, this change relies on a version change (here: 3.3 to 3.4) to be able to correct files written by OOo up to 3.3 (and only those). Some background: The root problem here was that older versions straight ignored attributes set at OLE objects by just not painting them. This means that in files generated the attributes are written and in plain ODF OLEs are filled default (blue8) and have line on default (black hairline). Questions/Comments are welcome, Armin -- ALG Sincerely, Armin -- ALG
Re: [PATCH] Fix for #118485#, #108221#, #67705#
Hi; I committed it as revision 1182166, and noted it in the bug report, but I admit the patch was too big to do a review on it. It was evidently a lot of work that I would hate to see ignored and, if I understand well, this was like *really* broken (3 issues) but in the future I will try to avoid committing these big patches without someone else reviewing it first. Pedro. --- On Tue, 10/11/11, Armin Le Grand wrote: ... > Hi *, > > I took some days to fix that long missing OLE-Attribute > feature/bug. It is on one hand a missing feature (no reason > to not apply attributes and transformations to OLE which > contains the same as graphical object, a MetaFile) and on > the other a compatibility issue with a big competitor which > is able to add attributes to OLEs for a long time. > > This fix was already prepared in #67705# but could not be > activated due to a missing part of #108221#. Thanks to ORW > (aka Oliver-Rainer) which helped to solve that. > > The patch adds LineStyle, FillStyle, Text, Shadow, Shear > and Rotate to OLE objects in Draw/Impress and Calc. It adds > Shear to graphic objects. It also fixes some long > existing not detected bugs to make all this work. It > leaves OLEs and graphical objects for Writer (SW) untouched > due to the fact that SW uses it's own implementations for > those (one more argument for the long missing consolidation > in SW to use DrawingLayer objects for this). > > Details are documented in > https://issues.apache.org/ooo/show_bug.cgi?id=118485, > but here is a list: > > - Added LineStyle, FillStyle, Text, Shadow, Shear, Rotate > to OLE > - Added Shear to GraphicObjects > - Adapted context menus in Draw/Impress, Calc > - Adapted UNO API to allow these attribute families for > those object types > - Adapted interactors to show a correct preview for > interactions > - Adapted ConvertTo to take set attributes into account > (was completely missing for GraphicObjects, a bug on it's > own). > - Adapted Text edit activation (press any key to start > typing), activation on Return stays untouched > - Adapted OLE activation to be centered to the now > eventually rotated/sheared object bounds > - Adapted MetaFile-ToSdrObject converter, transformations > are now applied to the created SdrObjects. Deactivated one > erroneous Item in text attribute creation which leads to bad > errors in text generation, wrote f'up #118498# for it (HDU) > - Adapted Import/Export to take care of added text > - Added correction for earlier written OOo ODF files at > load time > - Activated the prepared attribute visualization in the OLE > Primitive > - Corrected attribute generation for newly created OLEs > > I checked all changes again and added the patch to > #118485#. Now I'm looking for someone volunteering to add > the patch, build AOOo and play around with OLEs a little > bit, reading the patch will also help in this case, it's not > too big to do so. > > The change looks big, but it touches no too critical parts. > It is also necessary to bring it in AOOo3.4, this change > relies on a version change (here: 3.3 to 3.4) to be able to > correct files written by OOo up to 3.3 (and only those). > > Some background: The root problem here was that older > versions straight ignored attributes set at OLE objects by > just not painting them. This means that in files generated > the attributes are written and in plain ODF OLEs are filled > default (blue8) and have line on default (black hairline). > > Questions/Comments are welcome, > Armin > -- > ALG > >
