Issue 120957 - Export should give same gradient for small step counts as shape in edit mode
Export should give same gradient for small step counts as shape in edit mode
Status: RESOLVED FIXED
Product: Draw
Classification: Application
Component: code
4.0.0-dev
All All
: P3 normal (vote)
: 4.0.0
Assigned To: AOO issues mailing list
:
Depends on: 120604
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-13 14:03 UTC by Regina Henschel
Modified: 2013-07-12 16:23 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: ---
Developer Difficulty: ---


Attachments
Changing linear and axial gradient for small step counts (14.34 KB, patch)
2012-09-16 15:45 UTC, Regina Henschel
rb.henschel: review? (rb.henschel)
Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Regina Henschel 2012-09-13 14:03:53 UTC
Export of gradient style axial to metafile, pdf, flash, and printing results in gradients that are totally different from the gradients in edit mode, if step count is <= 64.
The error is in OutputDevice::ImplDrawLinearGradient.
Comment 1 Regina Henschel 2012-09-14 08:10:44 UTC
I will fix it in the traditional way. For details see issue 120604 and discussion on ooo-dev.
Comment 2 Regina Henschel 2012-09-16 15:45:43 UTC
Created attachment 79519 [details]
Changing linear and axial gradient for small step counts
Comment 3 Regina Henschel 2012-09-16 16:32:34 UTC
This are my suggestions. But I have tested them only on WinXP.

Test suggestions:
In Impress, test it with linear and with axial gradient:
Insert a shape, fill it with gradient, and set the step count to a value <=64.
Copy the shape, insert it and convert it to metafile. OK?
Copy the shape, insert it and convert it to bitmap. OK? (The missing 1 pixel right and 1 pixel bottom occurs with other fillings too.)
Switch to presentation mode. OK? (The white lines between the steps are a problem of the presentation mode and occur in the same way using other gradient styles like rectangle.)
Export whole slide to pdf. Open in pdf-reader. OK?
Export whole slide to flash. Open in browser. OK?
Export only shape to pure bitmap. Open with picture application. OK?
Export only shape to wmf. Open with picture application. OK?
Print slide. OK?

The code has a lot of type conversions between long and double. I'm not sure, how to write those.

Are really min 3 in nSteps needed? I think not, but have set it according to the old comment.

If the solution in issue 120604 implements the gradients in a different way, my solution here has to be adapted. But I thought, I show you my solution, so you can discuss it.
Comment 4 Armin Le Grand 2012-10-01 12:20:41 UTC
ALG: Checked all local cases (AA and no-AA edit view rendering. Checking all mentioned cases:

(a) Copy the shape, insert it and convert it to metafile. OK?

ImplDrawLinearGradient/ImplDrawComplexGradient not used

(b) Copy the shape, insert it and convert it to bitmap. OK? (The missing 1 pixel right and 1 pixel bottom occurs with other fillings too.)

ImplDrawLinearGradient/ImplDrawComplexGradient not used

(c) Switch to presentation mode. OK? (The white lines between the steps are a problem of the presentation mode and occur in the same way using other gradient styles like rectangle.)

OutputDevice::AddGradientActions is used from the current SlideShow mechanism; the polygons get recorded to a metafile

(d) Export whole slide to pdf. Open in pdf-reader. OK?

OutputDevice::AddGradientActions is used from PDFWriterImpl::implWriteGradient; the polygons get recorded to a metafile

(e) Export whole slide to flash. Open in browser. OK?

OutputDevice::AddGradientActions is used from swf::Writer::Impl_writeGradientEx; the polygons get recorded to a metafile

(f) Export only shape to pure bitmap. Open with picture application. OK?

OutputDevice::ImplDrawLinearGradient is used directly from OutputDevice::DrawGradient; no metafile recording

(g) Export only shape to wmf. Open with picture application. OK?

OutputDevice::AddGradientActions is used from tools, metafile is recorded

(h) Print slide. OK?

MetaGradientAction::Execute calls OutputDevice::ImplDrawLinearGradient, no metafile recording

Thus, we have:
- no use of old paints (a,b)
- metafile recording (c,d,e,g)
- direct paint (f,h)

no use of old paints: because the metainfo is used, recorded in the MetaCommentAction 'hacks'.

For the other two I'm thinking about using primitive functionality inside of ImplDrawLinearGradient/ImplDrawComplexGradient to ensure same looking and colors...

P.S.: No doubt, changing the old code is an option, but how safe is it? I know why I am soo careful with touching that old code, it's more than bad readable and does not offer an easy overview.
Looking further...
Comment 5 Armin Le Grand 2012-10-01 15:46:41 UTC
ALG: Experimented with primitives, but I would have to duplicate code since drawinglayer links against vcl, not the other way around. Thus, I cannot easily access the tooling stuff.
Tested deeply the direct changes from Regina. Congratulations, all cases in question look good. Very good work Regina :-)
I will take some more looks at the patch, concerning Regina's comments...
Comment 6 Armin Le Grand 2012-10-01 17:23:06 UTC
ALG: Checked with nSteps==2, works well. Anyways, the minimum on the UI is also set to three steps, looking where this is done...

Double precision: This was urgent for older systems, no need to be too conservative here, except inside small loops with many repeats, maybe.
Comment 7 Armin Le Grand 2012-10-01 17:43:34 UTC
ALG: nSteps ==2 in the UI is in cui/source/tabpages/tabarea.src, the entry NUM_FLD_STEPCOUNT needs to change Minimum and First to '2'. Works well, save/load is okay. Load in former office is okay, too; using the dialog there shows '3' as value, but as long as not changed, nothing bad seems to happen.

@Regina: What do You think, should we go to '2' as minimum steps?
0,1 -> no gradient, use start color
2 .. 255 -> steps as defined
Comment 8 Regina Henschel 2012-10-01 17:49:19 UTC
ODF 1.2 section 20.130 draw:gradient-step-count "A gradient step count of color interpretation shall be 3 or greater." So we may not write values smaller than 3, therefore UI constrain to nsteps>=3 is correct.
Comment 9 Regina Henschel 2012-10-01 18:53:54 UTC
An upper limit is not necessary from point of ODF, "A gradient step count of color interpretation may be above 256." and such large values need to be handled in import or in drawing.
Comment 10 Armin Le Grand 2012-10-02 09:16:27 UTC
ALG: Okay, lets stay at minimum of three. Could you make a not e that this may be changed to 2 in an ODF refinement? I see no reason against it and e.g. would be handy to half-fill rectangles with two colors (think about flags...).
Comment 11 Armin Le Grand 2012-10-02 09:23:58 UTC
ALG: Committed Reginas patch. Thanks Regina!
Comment 12 Armin Le Grand 2012-10-02 12:10:18 UTC
ALG: Okay, done. Should be complete with changes for #120604#.