Hi!

I've already mentioned the problem with project files chopped at the end in the other thread (Export/rendering failure), but it turns out it's a completely unrelated, different problem.

I've also pinpointed the cause - it's UTF-8, which is used in XML by default and is a variable length encoding.

If I place a text clip in the project, and use non-ASCII characters (in my case, either polish diacritical characters or cyryllic), the resulting project file is cropped at the end and the more non-ASCII characters, the larger part of the file is gone.

I believe that the problem is because when writing project files, KDEnlive calculates the size of the file to be written and assumes one byte per character, whch would only be correct if the text was encoded in plain ASCII. The calculation is correct if there are no non-ASCII characters anywhere in the project file, because UTF-8 is backward-compatible with ASCII.

However, characters outside the ASCII range are encoded with two, three or even more bytes in UTF-8.

So with such characters in place KDEnlive gets the output file size wrong and doesn't write the whole file.

Here's an example of a non-ASCII contect extracted from KDEnlive project file:

The solution would be to use a proper function to determine the byte size of the XML data when writing the project file instead of simply taking {number_of_characters} bytes.

I've wrote a simple patch that seems to fix the problem:

Index: kdenlive/saveprojectnativefilter.cpp
===================================================================
--- kdenlive/saveprojectnativefilter.cpp        (wersja 1592)
+++ kdenlive/saveprojectnativefilter.cpp        (kopia robocza)
@@ -120,8 +120,8 @@
        westley.appendChild(playlist);
     }
 
-    QString save = doc.toString();
-    file.writeBlock(save.utf8(), save.length());
+    QCString save = doc.toString().utf8();
+    file.writeBlock(save, save.length());
 
     return true;
 }

The problem was that we were calling length() before the conversion of the XML document to UTF-8 so we got it wrong.

I've just tested my patch quite extensively and it doesn't cause any problems while it fixes the bug - I think that someone with write access to SVN repository can safely commit it.

Fix committed, thanks for your patch

regards