[dev] Re: Drawing Porblem about the OLE-Object (line, fill, shadow, ...)
Hi Merlin (and limerlin, same person?), thanks for the bugdoc, I just confounded the state of the task (so many different ones :-)). Task http://openoffice.org/bugzilla/show_bug.cgi?id=67705 is the correct one to look at. bBehaveCompatibleToPaintVersion is there since I prepared the task's solution. It's currently true since after some discussion with ODF guys there was no way to detect if older ODF files were saved (as explained) with wrong attributes for fill and line attributes. So the current state is that everything is prepared in the code, but suppressed currently to stay compatible with old behaviour. As described in the task this will have to wait until ODF1.2 and a safe possibility to detect at load times if attributes for OLE SdrObjects need to be corrected. Thus, currently it is by purpose and line and fill style for OLEs is not supported. The bool is there to activate the enhancement easily when that distinction will be possible, so it's true to 'be compatible with the paint version' intentional. It's a static bool to be able to switch it for test purposes in debug code, this often comes handy when working on the code. When You would switch it to false it will work for your case, but all ODF files which were created (or will be as people use older OOo versions, too) will show OLEs filled with Blue7 and with black hairlines (what was the default), so this is no option. In your case it's a PPT import and it would be nice to switch on that feature early since the problem is not there in that case (no old ODF loaded). This would require to detect that the document in memory was a PPT import and no loaded ODF. This may be possible, but I would suggest to wait until the feature is completely finished with ODF1.2 at some time. Currently,fill and line style for OLEs is simply not supported, but prepared. Sorry, no solution currently. Ah, and the OLE content is shown in both cases, with true and false. I initially thought we might have a problem with missing OLE content, but this works for me. Am 13.07.2011 04:27, schrieb limerlin: hi ALG Thanks for your help. The bugdoc is in the annex. Best regards, Merlin To: dev@openoffice.org From: armin.le.gr...@me.com Date: Tue, 12 Jul 2011 16:52:33 +0200 Subject: [dev] Re: Drawing Porblem about the OLE-Object (line, fill, shadow, ...) Am 12.07.2011 08:23, schrieb limerlin: Hi When i opened a MS PowerPoint file with OpenOffice,the fillings and lines of OLE-Object's area does not display. Following is what I found after error checking: http://openoffice.org/bugzilla/show_bug.cgi?id=67705 then i read the source code and made following changes to see if it works. http://svn.services.openof fice.org/opengrok/xref/Current%20(trunk)/svx/source/sdr/primitive2d/sdrole2primitive2d.cxx http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/svx/source/sdr/primitive2d/sdrole2primitive2d.cxx at line 86 86 //*static* *bool* bB ehaveCompatibleToPaintVersion http://svn.services.openoffice.org/opengrok/s?defs=bBehaveCompatibleToPaintVersionproject=/Current%20(trunk)(*true*);//delete bool bBehaveCompatibleToPaintVersion http://svn.services.openoffice.org/opengrok/s?defs=bBehaveCompatibleToPaintVersionproject=/Current%20(trunk) = false //add It work well! Hi limerli n, the static bool bBehaveCompatibleToPaintVersion is there to enable/disable adding graphical fill/line attributes if wanted. The background is that OLE SdrObjects in the old paint version (before changing to primitives) ignored the line and fill attributes which are commonly defined for all SdrObjects. Sice these were ignored at paint time but set in the ItemSet of the SdrObject (and saved in ODF over the UNO API) switching this on was critical for a period of time, especially for files saved before these attributes were corectly initialized for OLE SdrObjects. I'm not sure anymore when this was done, but you should not set it to false, this will ruin functionality. When e.g. you define a new OLE and use the fill/line attributes (also shadow), this will be ignored when switching the bool to false. As can be seen some lines after this: br // add graphic content appendPrimitive2DSequenceToPrimitive2DSequence(aRetval, getOLEContent()); the OLE graphic content is added after the line and fill primtives, so it should be painted above line and fill anyways. So: I cannot explain why the content is missing when you switch the bool, but it is wrong to do so. It will ruin used functionality. I would try to go in the direction to find out if getOLEContent() is empty in your case and why. Is the bugdoc available somewhere? I would like to take a look... Regards, Armin How ever the limited knowledge of openoffice confused me
[dev] Re: Drawing Porblem about the OLE-Object (line, fill, shadow, ...)
Am 12.07.2011 08:23, schrieb limerlin: Hi When i opened a MS PowerPoint file with OpenOffice,the fillings and lines of OLE-Object's area does not display. Following is what I found after error checking: http://openoffice.org/bugzilla/show_bug.cgi?id=67705 then i read the source code and made following changes to see if it works. http://svn.services.openof fice.org/opengrok/xref/Current%20(trunk)/svx/source/sdr/primitive2d/sdrole2primitive2d.cxx http://svn.services.openoffice.org/opengrok/xref/Current%20(trunk)/svx/source/sdr/primitive2d/sdrole2primitive2d.cxx at line 86 86 //*static* *bool* bB ehaveCompatibleToPaintVersion http://svn.services.openoffice.org/opengrok/s?defs=bBehaveCompatibleToPaintVersionproject=/Current%20(trunk)(*true*);//delete bool bBehaveCompatibleToPaintVersion http://svn.services.openoffice.org/opengrok/s?defs=bBehaveCompatibleToPaintVersionproject=/Current%20(trunk) = false //add It work well! Hi limerlin, the static bool bBehaveCompatibleToPaintVersion is there to enable/disable adding graphical fill/line attributes if wanted. The background is that OLE SdrObjects in the old paint version (before changing to primitives) ignored the line and fill attributes which are commonly defined for all SdrObjects. Sice these were ignored at paint time but set in the ItemSet of the SdrObject (and saved in ODF over the UNO API) switching this on was critical for a period of time, especially for files saved before these attributes were corectly initialized for OLE SdrObjects. I'm not sure anymore when this was done, but you should not set it to false, this will ruin functionality. When e.g. you define a new OLE and use the fill/line attributes (also shadow), this will be ignored when switching the bool to false. As can be seen some lines after this: // add graphic content appendPrimitive2DSequenceToPrimitive2DSequence(aRetval, getOLEContent()); the OLE graphic content is added after the line and fill primtives, so it should be painted above line and fill anyways. So: I cannot explain why the content is missing when you switch the bool, but it is wrong to do so. It will ruin used functionality. I would try to go in the direction to find out if getOLEContent() is empty in your case and why. Is the bugdoc available somewhere? I would like to take a look... Regards, Armin How ever the limited knowledge of openoffice confused me that i dont know is it approiate to make those changes. Anyone can help me ? -- Best regards, Merlin -- ALG -- - To unsubscribe send email to dev-unsubscr...@openoffice.org For additional commands send email to sy...@openoffice.org with Subject: help
Re: [dev] How to include inter-module headers
Hi Stephan, Stephan Bergmann schrieb: Hi all, A Should inter-module includes generally be module/header instead of just header? Then the current hedaburemove01 changes would be a pragmatic hack---instead of changing tons of include lines in tons of source files, change a single line that magically extends the search path wherever necessary (and also where not necessary). If this is the ideal state, the drawback of the hedaburemove01 changes is that they potentially move us further away from that state---new code can introduce sloppy includes of just header that should be module/header, even in modules where this would have been caught before. Others? Definitely A. I alraedy did that with new code for a while (using module/header) and it make life much easier. It's not only clearer, but also allows migration of module parts to other or new modules much simpler. Actually, i am surprised that the header - module/header transition was not part of the change already. I see that a script doing this is not trivial, but still non-ambigous with the knowledge about the current include structure... -- -- Regards, Armin Le Grand (AW) Armin.Le.Grand(at)sun.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Kay, Kay Ramme - Sun Germany - Hamburg wrote: FYI Matthias Huetsch, Malte Timmermann, Michael Brauer and I recently had a discussions regarding how to deal with binfilter in case of incompatible changes of modules used by binfilter. I am still wondering why nobody invited me to this discussion as i surely would have been able to add some background and initial thoughts to the whole theme. Anyways, i am pretty happy with the direction it is taking. We came up with the following recipe: For every request of an additional module for / change of binfilter the following steps are to be tried in the following order: 1. Check if the dependency could not be removed / avoided completely. - For the above change this means, to verify that basctl is indeed needed for loading / storing documents. 2. Copy the code which is needed only. - For the above change this means, that the serializers (import / export) may just be copied out of basctl to binfilter (respectively they may be just reimplemented if this is easier :-) . 3. Copy the whole module. - If the target module is reasonable small, the whole module may be copied to binfilter. For the above change this would mean to copy basctl to binfilter. 4. Adapt binfilter to the incompatible changes done in the dependent module. - For the above change this would mean, to adapt binfilter to the changes done in basctl. 5. Do not change the dependent module incompatible. - For the above change this would mean, not to change basctl incompatible. That's the right way to go. Please take in mind what kind of code is/will be moved to binfilter: - code that is no longer used in the 'living' office modules, but needed by the old binary filter mechanisms - code that is completely rearranged and cannot be adapted to also keep up the needed (C++) APIs and functionalities for binfilter Both cases happen, BECAUSE binfilter allows us to do things like that at all and to enhance the 'living' office modules, not to expand binfilter. The expansion of binfilter is the price to pay to keep the old binary filters running, and that price was intended and is accepted ATM. Do not forget that it is even DANGEROUS to change functionality/code without noticing that binfilter is still using it. Binfilter may well need controlled fixes from time to time in shared code regions which may also enhance the living modules, but the other way around You risk to break binfilter functionality which cannot/is rarely tested anymore. That's (one of the reasons, there were many others) why my initial plan always was to freeze binfilter on a defined state. Defined state means: Let it rest on a published version, this is never deleted and stays buildable (if fixes are needed). Freeze means: Add all still missing and urgently necessary C++ dependencies methodically: Link without the standard modules and add missing code. Yes, this might take a while and is not easy but might have been done by one person methodically, not costing man-years of bandwidth, service, maintaining, bulding, adapting, developer time, ... With the suggested steps we move to that target, so i am happy about them. Comparing the costs spent up to now by all and that will be spent until the goal is reached, i again have to suggest (as years ago) to do it once, by one person and for the next public release. The resulting binfilter module will be an UNO-API only module, independent of 'living' C++ code and can then rest on that version. I created a module page for the binfilter module in the OOo wiki and copied the receipt to this page as well: http://wiki.services.openoffice.org/wiki/Framework/Modules/binfilter Hope that helps Kay - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Rüdiger, Rüdiger Timm wrote: Armin Le Grand wrote: [...] I haven't read that restriction anywhere. Kays proposal was about any incompatible change below binfilter. It's not a restriction, it's logic. Why else should code be moved to binfilter ATM? Kay is right because incompatible changes below binfilter are a good indication for such cases. See above: i understand Kays recipe as not to do so. And that I consider wrong. That's why I wrote about duplicating code, not just moving it. Duplicating ATM is always a necessity when the original code changes so much that it cannot be used/shared with binfilter anymore. When we would have made it independent, all the necessary code would have been duplicated (most already is), but potential changes would just not need to take notice about binfilter and may be changed in the living modules as required... I do not think that we would save so much. We still would need binfilter on our master workspace just to get part in all changes to linker switches, baseline, and so on. So, everyone doing full builds would still have to check out and build binfilter, it just would be bigger. Of course, costs for adapting and maintaining would vanish. But would that outweigh the initial transformation work? It would. With original plans, binfilter would be a module in the 8.0 release and be link-incompatible from the other modules. It is used as a UNO component anyways, so it would be usable with offices up to today, how incompatible and changed they may ever be (thatÄs the UNO API definition). Think about it: All the compiler changes, environment stuff, includes, incompatible builds, adding to CWSes, would not have happened. This is what i call man-Years and ressources... Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] Extending the binfilter Module
Hi Malte and Kay, i will also answer Kay's reply here, he was just asking for the amount of work, too... Malte Timmermann wrote: I also prefer making binfilters completely independent from any other OOo code. Constrain is to keep it as small as possible. It might be difficult to duplicate ( or better get rid of) VCL. Right, it will not be easy. In theory, only font and output device code should be in use if you can really throw away everything not needed for a filter. For a converter even that should not be needed, because there shouldn't be any layout calculation. But to get all of that done, you need more than one person, or a lot more time than you estimate. I do not think so. All estimations can only be guesses, but i would just do a methodical approach: (a) do not link against other C++ modules (b) look at the unresolved externals (c) take one block (c1) check if it's needed at all or the usages may be stripped (c2) reduce to the needed, add to binfilter (d) repeat This will allow the task to be done from someone extern who does not know too much about the modules. We had some ressources for something like that at that time. Maybe there are even 'tricks' someone can use who has deep experience with linking processes. At a minimum approach, it would also be okay to do something like linking binfilter statically against the modules of the release version we keep it at. This may produce something like a binfilterstatic680mi.dll containing all the static linkages without copying any code to binfilter. Maybe we should investigate in that direction, we need someone with experience in that field. Even with the first methodical approach i think a good engineer - with build boxes like Pavel has one - may handle that task in 3-6 months. And my suggestion would be to start with throwing away all unused code in binfilters, to avoid unnecessary dependencies. That's where amout of work was already put and would be goot to put more, but since this is th task You need experienced engineers for, it was seen as expensive, and i agree. This is IMHO not the job for one person alone, but for one person of each application who knows what can be removed. Probably also someone for DrawingEngine code - hey, that IMHO would be you ;) Yes, if we decide to do it that way. I was already commited to do something like that years ago to prevent those man-years of work for others and i am still. We just need to evaluate if there is not a methodical approach which can be handled by someone not deeply involved. If You ask me, this is possible. We just would need ressources to throw on it, and from my point of view they could do it methodically (we need to define that, though) without deep module knowledge. Ongoing changes in the DrawingLayer OTOH REQIRE that knowledge and can not be done methodically from someone else. We just need to weight the costs, real and implied ones... Malte. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
