Apache OpenOffice (AOO) Bugzilla – Issue 102797
Adapted customshape coloring (shaded surfaces & gradients)
Last modified: 2017-05-20 10:29:12 UTC
Attached patches are an attempt to get OOo a bit closer to MSO12's custom shape filling behaviour; the basegfx one adds a few color space conversion functions to basegfx (something to consolidate also other parts of the code to, like color picker, oox, slideshow), the ppt-surface-shading.diff is probably the meat, making highlighted/darkened surfaces to show the same fill with the same shape-relative alignment (only shaded accordingly), plus using another color space to perform the color change in (HSV now). ppt-customshape-shading-fix.diff is possibly the most controversial, globally changing the way some custom shapes get darkened/brightened sub-surfaces, and also tweaking color swapping in the binary import.
Created attachment 63003 [details] basegfx section
Created attachment 63004 [details] the intrusive fixes
Created attachment 63005 [details] the general gradient position/coloring fixes
the patch has been applied to cws[impress174]...
Created attachment 63957 [details] Additional fix
@sj: ugh, seems I seriously broke fontwork with this change - ok to commit the additional fix in impress174 (avoids messing with the fontwork glyphs)? Also, I could bet I saw this already somewhere, might be good to adapt GetPoint()'s "if ( rPoly.GetSize() )" check to "> 1" (in EnhancedCustomShapeFontWork.cxx)?
Thanks, I didn't notice that the previous change breaks the Fontwork, so I am glad to also apply your latest patch. I also made the FontWork creation more safe by checking for more than 1 point in EnhancedCustomShapeFontwork.cxx
sj->cl: can you please verify this issue
I verified that the patch has been applied
verified
sj->wg: to verifiy this issue you only have to check if our customshapes which uses shading colors such as "smiley, button, cube..." looks still good.
Verified in CWS.
sj: Because of issue 105654 I removed the last patch in cws[impress178], this logic rect hack leads to polygons that are not closed. If we want to fix this, we need to create graphic primitives instead of drawing objects, but the effort to accomplish this is a little bit higher.