I can confirm a corruption, tested using Windows 8.1 with LibreOffice Version: 4.3.0.0.alpha0+
Build ID: 90dd4320de6ace24e464979630a2c9fbab35f64b
TinderBox: Win-x86@39, Branch:master, Time: 2014-03-19_00:22:53

Looks like both values are multiplied wrongly with 3500.

Kind regards,
Joren

Still reproducible on:
Version: 5.0.0.0.alpha1+
Build ID: a21a0b6dceaf965673ae601318e77991919c8f6a

The exported file has slightly changed, this is the diff of the files before/after roundtrip:
  <                             <a:ds d="105000" sp="35000" />
  ---
  >                             <a:ds d="100000" sp="100000" />

(In reply to Jacobo Aragunde Pérez from comment #3)
> The exported file has slightly changed, this is the diff of the files
> before/after roundtrip:
>   <                             <a:ds d="105000" sp="35000" />
>   ---
>   >                             <a:ds d="100000" sp="100000" />

This is due patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=2211a67cc5e577f8abdcc96c9c63865be5fb988d

We now always read or convert the 'd' and 'sp' to 1000th of a %.
As you can see here: http://opengrok.libreoffice.org/xref/core/oox/source/drawingml/lineproperties.cxx#114

+        nConvertedLen      = aIt->first  / 1000 / 100;
+        nConvertedDistance = aIt->second / 1000 / 100;

we not only divide by 1000, also we now divide by 100 extra.

105000 / 1000 / 100 = rounded to 1
35000 / 1000 / 100 = rounded to 0, but maxed later to 1

Those values are multiplied by the nLineWidth at http://opengrok.libreoffice.org/xref/core/oox/source/drawingml/lineproperties.cxx#387 which is maxed to 35 (first it was 32).

aLineDash.DotLen = 1*35 now
aLineDash.Distance = 1*35 now

At export:
+ XML_d , write1000thOfAPercent( aLineDash.DashLen  > 0 ? aLineDash.DashLen  / nLineWidth * 100 : 100 ),
+ XML_sp, write1000thOfAPercent( aLineDash.Distance > 0 ? aLineDash.Distance / nLineWidth * 100 : 100 ),

d = sp = (35 / 32 * 100) * 1000 = 100000

Following patch exports the right values, but countereffect is that now the line is not shown correctly in LibreOffice (length and distance is factor 100 bigger):

diff --git a/oox/source/drawingml/lineproperties.cxx b/oox/source/drawingml/lineproperties.cxx
index efa1ab8..281fa57 100644
--- a/oox/source/drawingml/lineproperties.cxx
+++ b/oox/source/drawingml/lineproperties.cxx
@@ -111,8 +111,8 @@ void lclConvertCustomDash( LineDash& orLineDash, const LineProperties::DashStopV
     for( LineProperties::DashStopVector::const_iterator aIt = rCustomDash.begin(), aEnd = rCustomDash.end(); aIt != aEnd; ++aIt )
     {
         // Get from "1000th of percent" ==> percent ==> multiplier
-        nConvertedLen      = aIt->first  / 1000 / 100;
-        nConvertedDistance = aIt->second / 1000 / 100;
+        nConvertedLen      = aIt->first  / 1000;
+        nConvertedDistance = aIt->second / 1000;
 
         // Check if it is a dot (100% = dot)
         if( nConvertedLen == 1 )
diff --git a/oox/source/export/drawingml.cxx b/oox/source/export/drawingml.cxx
index 484c90b..3c8b1ee 100644
--- a/oox/source/export/drawingml.cxx
+++ b/oox/source/export/drawingml.cxx
@@ -692,8 +692,8 @@ void DrawingML::WriteOutline( Reference<XPropertySet> rXPropSet )
                     for( i = 0; i < aLineDash.Dashes; i ++ )
                     {
                         mpFS->singleElementNS( XML_a , XML_ds,
-                                               XML_d , write1000thOfAPercent( aLineDash.DashLen  > 0 ? aLineDash.DashLen  / nLineWidth * 100 :
-                                               XML_sp, write1000thOfAPercent( aLineDash.Distance > 0 ? aLineDash.Distance / nLineWidth * 100 :
+                                               XML_d , write1000thOfAPercent( aLineDash.DashLen  > 0 ? aLineDash.DashLen  / ::std::max< sal_Int32 >( nLineWidth, 35 ) : 100 ),
+                                               XML_sp, write1000thOfAPercent( aLineDash.Distance > 0 ? aLineDash.Distance / ::std::max< sal_Int32 >( nLineWidth, 35 ) : 100 ),
                                                FSEND );
                     }
                 }


How to get around this incorrect display in LibreOffice?
(I can't find the correct location where these values are handled in the drawing-backend of LibreOffice).
I see 2 options:
1) devide or factor everything related to this DashLen with 100, so it'll be displayed correctly
2) store these very tiny dots or dashes whom are rounded incorrectly in a kind of grab-bag and call them on export again.

Can someone please help me out and show me the right direction :)?

Thanks!
Joren

After the nice comment 4 posted by Jorendc, I guess it deserve some attention, adding 'needAdvice'

Exported values are not terribly wrong now:

Original:
  <a:custDash>
    <a:ds d="105000" sp="35000"/>
  </a:custDash>

Exported:
  <a:custDash>
    <a:ds d="100000" sp="100000" />
  </a:custDash>

They are still different from original values in the document, though. The bug is still valid.

Version: 5.3.6.1
Build ID: 5.3.6.1-5.fc26
CPU Threads: 4; OS Version: Linux 4.12; UI Render: default; VCL: gtk3; Layout Engine: new; 
Locale: es-ES (en_US.UTF-8); Calc: group

Corrupted message no longer displayed in MSO 2010 after a RT in

Version: 6.0.0.0.alpha1+
Build ID: 60a03d97bc35c02cb1eff0e4a02b6f37fd1a6a34
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

@Jacobo, I guess it's not fixed yet though, isn't it?

@Xisco the situation has improved, there is no corruption message (I think that was caused by values out of range for a:ds attributes) but the original value is still not preserved. The bug is less worrying now, but it should remain open.

Mark Hung committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=34dff8df7b9fc46fed6e6ffbaa8b6847ad6ed1b1

tdf#73547 fix ooxml export / import custom dashes.

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

A polite ping to Mark Hung:
Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing?
Thanks

Fixed with commit https://cgit.freedesktop.org/libreoffice/core/commit/?id=57c9bdab377a00649299d1a4c9ed2f9e5e03b84e

Fix is available in Version: 6.4.0.0.alpha0+ (x64)
Build ID: 61b757f31f25cda6d595f64226181c7a82ce8d7f
CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2019-09-07_17:48:35
Locale: en-US (en_US); UI-Language: en-US
Calc: CL