I will fix it in the traditional way. For details see issue 120604 and discussion on ooo-dev.

Created attachment 79519 [details]
Changing linear and axial gradient for small step counts

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.

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...

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...

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.

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

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.

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.

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...).

ALG: Committed Reginas patch. Thanks Regina!

ALG: Okay, done. Should be complete with changes for #120604#.