Issue 102797 - Adapted customshape coloring (shaded surfaces & gradients)
Summary: Adapted customshape coloring (shaded surfaces & gradients)
Status: CLOSED FIXED
Alias: None
Product: Impress
Classification: Application
Component: code (show other issues)
Version: recent-trunk
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.2
Assignee: wolframgarten
QA Contact: issues@graphics
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-15 14:20 UTC by thb
Modified: 2017-05-20 10:29 UTC (History)
1 user (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
basegfx section (22.04 KB, patch)
2009-06-15 14:39 UTC, thb
no flags Details | Diff
the intrusive fixes (5.60 KB, patch)
2009-06-15 14:46 UTC, thb
no flags Details | Diff
the general gradient position/coloring fixes (11.33 KB, patch)
2009-06-15 14:47 UTC, thb
no flags Details | Diff
Additional fix (1.45 KB, patch)
2009-08-04 20:05 UTC, thb
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description thb 2009-06-15 14:20:55 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.
Comment 1 thb 2009-06-15 14:39:18 UTC
Created attachment 63003 [details]
basegfx section
Comment 2 thb 2009-06-15 14:46:47 UTC
Created attachment 63004 [details]
the intrusive fixes
Comment 3 thb 2009-06-15 14:47:39 UTC
Created attachment 63005 [details]
the general gradient position/coloring fixes
Comment 4 sven.jacobi 2009-07-03 13:44:06 UTC
the patch has been applied to cws[impress174]...
Comment 5 thb 2009-08-04 20:05:50 UTC
Created attachment 63957 [details]
Additional fix
Comment 6 thb 2009-08-04 20:09:16 UTC
@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)?
Comment 7 sven.jacobi 2009-08-05 10:12:37 UTC
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
Comment 8 sven.jacobi 2009-08-21 12:11:00 UTC
sj->cl: can you please verify this issue
Comment 9 clippka 2009-08-25 13:44:45 UTC
I verified that the patch has been applied
Comment 10 clippka 2009-08-25 13:45:40 UTC
verified
Comment 11 sven.jacobi 2009-08-25 13:52:16 UTC
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.
Comment 12 wolframgarten 2009-08-26 09:50:53 UTC
Verified in CWS.
Comment 13 sven.jacobi 2009-10-08 13:07:15 UTC
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.