How far can the LO file's contents be stretched?

Johannes Sixt j6t at kdbg.org
Sun Feb 12 12:26:12 PST 2012


Am 07.02.2012 20:36, schrieb Johannes Sixt:
> Am 06.02.2012 23:32, schrieb Michael Stahl:
>>> Now I'm exploring plan B: textual merging of the XML data. For this, I'm
>>> exploding the zip archive into a git tree so that I can use the git
>>> toolbox. Unfortunately, there are many textual conflicts because the
>>> automatic styles are numbered, and as styles come and go between
>>> document versions, many unnecessary conflicts arise at the point where
>>> the styles are used. To work it around, I would rename the styles based
>>> on a hash of the style definition and sort them (to be able to better
>>> merge the <automatic-styles> section).
>>
>> fixing that would perhaps be a good idea; code is somewhere in the
>> "xmloff" module...
> 
> I'll probably have a look at that.

The patch below is how far I got. It computes a CRC from the properties
in the automatic style, which is used in the name. In this version, the
count is still used, just in case the CRC is not unique (this should not
be done in the final version). But the styles are not sorted by their
new names, which makes the whole act moot. I also wanted to include the
name of the parent style, but I do not see how to get to it.

(The patch is licensed under MPL/LGPLv3+, just in case someone wants to
drive this forward from here. That may even be me, if I get some
pointers how to proceed.)

diff --git a/xmloff/source/style/impastp2.cxx b/xmloff/source/style/impastp2.cxx
index 882619d..efb8b46 100644
--- a/xmloff/source/style/impastp2.cxx
+++ b/xmloff/source/style/impastp2.cxx
@@ -27,6 +27,8 @@
  ************************************************************************/
 
 #include <rtl/ustrbuf.hxx>
+#include <rtl/crc.h>
+#include <osl/endian.h>
 #include "impastpl.hxx"
 
 using namespace std;
@@ -50,11 +52,52 @@ SvXMLAutoStylePoolPropertiesP_Impl::SvXMLAutoStylePoolPropertiesP_Impl( XMLFamil
 {
     // create a name that hasn't been used before. The created name has not
     // to be added to the array, because it will never tried again
-    OUStringBuffer sBuffer( 7 );
+    // derive a hash from the property names, types, and values
+    sal_uInt32 crc = 0;
+    for (vector< XMLPropertyState >::const_iterator i = rProperties.begin(), e = rProperties.end(); i != e; ++i)
+    {
+#define my_htonl OSL_NETWORD
+        sal_uInt32 buf[4];
+        buf[0] = my_htonl(i->mnIndex);
+        buf[1] = my_htonl(i->maValue.pType->eTypeClass);
+        if (i->maValue.has<sal_uInt64>()) {
+            sal_uInt64 v;
+            i->maValue >>= v;
+            buf[2] = my_htonl(sal_uInt32(v >> 32));
+            buf[3] = my_htonl(sal_uInt32(v));
+            crc = rtl_crc32(crc, buf, 16);
+        } else if (i->maValue.has<double>()) {
+            union {
+                sal_uInt64 v;
+                double x;
+            } v;
+            i->maValue >>= v.x;
+            buf[2] = my_htonl(sal_uInt32(v.v >> 32));
+            buf[3] = my_htonl(sal_uInt32(v.v));
+            crc = rtl_crc32(crc, buf, 16);
+        } else if (i->maValue.has<OUString>()) {
+            OUString s;
+            i->maValue >>= s;
+            buf[2] = my_htonl(s.hashCode());
+            crc = rtl_crc32(crc, buf, 12);
+        } else {
+            crc = rtl_crc32(crc, buf, 8);
+        }
+#undef myhtonl
+    }
+    OUStringBuffer sCrcBuffer( 8 );
+    for (int i = 0; i < 32; i += 4) {
+        char c = "0123456789abcdef"[(crc >> i) & 0xf];
+        sCrcBuffer.appendAscii( &c, 1 );
+    }
+    OUString sCrc = sCrcBuffer.makeStringAndClear();
+
+    OUStringBuffer sBuffer( 50 );
     do
     {
         pFamilyData->mnName++;
         sBuffer.append( pFamilyData->maStrPrefix );
+        sBuffer.append( sCrc );
         sBuffer.append( OUString::valueOf( (sal_Int32)pFamilyData->mnName ) );
         msName = sBuffer.makeStringAndClear();
     }


More information about the LibreOffice mailing list