Bug report in STEPControl_Writer

Hello everybody,

I discovered a bug when using the STEPControl_Writer. I export some BsplineSurface to a step file but when I try to read it back in with OCC it fails saying :
**** StepFile Error : At line 4225, parse error ****
If I look into the Step file at that particular location I find following (line 4225 is indicated with an arrow):

#2406 = B_SPLINE_SURFACE_WITH_KNOTS('',5,1,(
(#2407,#2408)
,(#2409,#2410)
,(#2411,#2412)
,(#2413,#2414)
,(#2415,#2416)
,(#2417,#2418)
,(#2419,#2420)
,(#2421,#2422)
,(#2423,#2424)
,(#2425,#2426
line4225-> )),.UNSPECIFIED.,.F.,.F.,.F.,(6,1,1,1,1,6),(2,2),(0.,5.213808239601E
,0.107179680103,0.396136669348,0.687599837389,1.),(0.,1.),
.UNSPECIFIED.);

If you carefully examine this line, it stops at character 72, which is an 'E'. It should not stop there because it should be followed by -2, the entire line should be:
)),.UNSPECIFIED.,.F.,.F.,.F.,(6,1,1,1,1,6),(2,2),(0.,5.213808239601E-2

but it is too long to fit into 72 characters.
The error occurs several times in my step flie:

#2575 = B_SPLINE_SURFACE_WITH_KNOTS('',5,1,(
(#2576,#2577)
,(#2578,#2579)
,(#2580,#2581)
,(#2582,#2583)
,(#2584,#2585)
,(#2586,#2587)
,(#2588,#2589)
,(#2590,#2591)
,(#2592,#2593)
,(#2594,#2595
)),.UNSPECIFIED.,.F.,.F.,.F.,(6,1,1,1,1,6),(2,2),(0.,5.611909524625E
,0.117791228805,0.425683231324,0.728174249643,1.),(0.,1.),
.UNSPECIFIED.);

While in other cases it works fine:

#912 = B_SPLINE_SURFACE_WITH_KNOTS('',5,3,(
(#913,#914,#915,#916)
,(#917,#918,#919,#920)
,(#921,#922,#923,#924)
,(#925,#926,#927,#928)
,(#929,#930,#931,#932)
,(#933,#934,#935,#936)
,(#937,#938,#939,#940)
,(#941,#942,#943,#944)
,(#945,#946,#947,#948)
,(#949,#950,#951,#952)
,(#953,#954,#955,#956
)),.UNSPECIFIED.,.F.,.F.,.F.,(6,1,1,1,1,1,6),(4,4),(0.,
5.659499438275E-02,0.106331201717,0.281300418172,0.526762189187,
0.769537592724,1.),(0.,1.),.UNSPECIFIED.);

Apparently, when you compare this last case with previous cases, the writer has decided correctly to jump to the next line when writing the second uknot. This didn't happen in the first two cases. The line up to the second uknot in the last example is however 2 characters longer, so I suppose there is a misjudgement of the available place by the writer...
Can someone fix this bug?
Thanks in advance!

Tom