<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaParaStyle" type="text/css">P {margin-top:0;margin-bottom:0;}</style>
</head>
<body ocsi="0" fpstyle="1">
<div style="direction: ltr;font-family: Tahoma;color: #000000;font-size: 10pt;">Hi again,<br>
<br>
>2. I can send you one more file with same kind of structure which Stage is not able to parse and open.  Come  >on.. I have seen structures in mso.xml which are not compliant with MS-ODRAW spec :)
<br>
<br>
Yes, that's true.  I just don't want you to waste time playing with workarounds for the containers order.  Especially in such a corrupt file.<br>
<br>
The order of containers MUST strictly follow the corresponding MS-* specification and the ABNF  grammar (specified in [RFC5234]) referenced at many places therein.  However real world documents produced by older versions of MS Office and other office suites
 do NOT follow the rules.   I have a bunch of documents like yours, which require us to look for a specific container at some other place or contain unknown containers.  The correct approach would be to re-design the parser to NOT expect the containers in the
 predefined order.<br>
<br>
I already pointed to the fact that mso.xml is becoming messy because unknown/known containers are added to places where they occurred in a single test file.<br>
<div><br>
Please upload all your test files to the calligratests repository so we can test for regressions later.  I'm using the corresponding folder in calligratests/import.  Maybe we should have a separate corrupt_files folder.<br>
<br>
>I guess our final goal is to make Stage as robust as possible.<br>
Yes, our goal is to have robust filters by improving POLE and msoscheme first.  Then we have to improve the filters and relax a bit checks against invalid files in the parser.<br>
<br>
br,<br>
<br>
-matus<br>
<br>
<div style="font-family: Tahoma; font-size: 13px;"><font size="2">-- <br>
Matus Uzak<br>
Software Designer<br>
Ixonos Slovakia s.r.o.<br>
Sturova 27, 040 01 Kosice, Slovakia<br>
mobile 0421 918 718 958<br>
email: matus.uzak@ixonos.com<br>
http://www.ixonos.com</font></div>
</div>
<div style="font-family: Times New Roman; color: rgb(0, 0, 0); font-size: 16px;">
<hr tabindex="-1">
<div style="direction: ltr;" id="divRpF69559"><font color="#000000" face="Tahoma" size="2"><b>From:</b> calligra-devel-bounces@kde.org [calligra-devel-bounces@kde.org] on behalf of Mani N C [maninc@gmail.com]<br>
<b>Sent:</b> Tuesday, January 10, 2012 6:22 AM<br>
<b>To:</b> Calligra Suite developers and users mailing list<br>
<b>Subject:</b> Re: Patch for msoscheme<br>
</font><br>
</div>
<div></div>
<div>Hi Matus,
<div><br>
</div>
<div>Thanks for reviewing my patch. </div>
<div><br>
</div>
<div>I got this file in internet and saved it in my Google Docs folder and downloaded it from Google docs. I did not try out this file with 2007 but in 2010  was able to open this file with some extra blank slides added to it. BTW LibreOffice  opened this file
 without any error. </div>
<div><br>
</div>
<div>1. I first tried to add TextContainerInteractiveInfo to TextContainer, but this did fix the parsing issue. So I moved it to Parent structure, similar to what we have done for TextRulerAtom. I do agree, It should have been TextContainerInteractiveInfo instead
 of  MouseClickTextInfo. Since this was with some corner cases I thought MouseClickTextInfo would be sufficient. </div>
<div><br>
</div>
<div>2. I can send you one more file with same kind of structure which Stage is not able to parse and open.  Come on.. I have seen structures in mso.xml which are not compliant with MS-ODRAW spec :) </div>
<div><br>
</div>
<div>I guess our final goal is to make Stage as robust as possible. We can throw an error saying this is not as per specs but finally we should open the document. While saving a document we should stick to the specification but we should be flexible while reading
 it. </div>
<div><br>
</div>
<div>If you have a better fix, feel free to update my patch or let me know I will fix it. </div>
<div><br>
</div>
<div>Thanks & Regards,</div>
<div>Mani</div>
<div><br>
<div class="gmail_quote">On Mon, Jan 9, 2012 at 10:22 PM, Uzak Matus <span dir="ltr">
<<a href="mailto:matus.uzak@ixonos.com" target="_blank">matus.uzak@ixonos.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi Mani,<br>
<br>
I'm not happy about that patch (check the reasons below).  Do you know which application produced that file?<br>
<br>
PowerPoint 2007 classified your test file as corrupt and displayed only a number of slides.  PowerPoint 2003 did not complain (it usually does not complain ) but I don't know if the file was displayed properly.  After re-save in PowerPoint 2003 the file was
 displayed identically by Stage.<br>
<br>
At the moment both the parser and the filter are not prepared to handle such files and I would prefer to revert such a change from msoscheme.<br>
<br>
Reasons:<br>
1.  We invented a number of own structures the keep related information together and make it logically sound to have the filter as readable as possible.  Each of the choices defined therein arrives in a specific scenario or is used by a specific version of
 PowerPoint.  You mixed MouseClickTextInfo into data which specify padding and indent and that is logically unsound.<br>
<br>
<struct name="TextClientDataSubContainerOrAtom"><br>
               <choice name="anon"><br>
                       <type type="OutlineTextRefAtom" /><br>
                       <type type="TextContainer" /><br>
                       <type type="TextRulerAtom" /><br>
+                       <type type="MouseClickTextInfo" /><br>
               </choice><br>
</struct><br>
<br>
<br>
2.  You introduced the following child of OfficeArtSpContainer :<br>
<br>
               <type name="shapeTertiaryOptions2" type="OfficeArtTertiaryFOPT"<br>
                       optional="true" /><br>
+               <type name="shapePrimaryOptions2" type="OfficeArtFOPT" optional="true" /><br>
<br>
This is not compliant with the MS-ODRAW specification, there are no shapePrimaryOptions2!  From my experience MS-ODRAW containers always follow the Primary - Secondary - Tertiary order, so expecting shapePrimaryOptions2 to be saved after shapeSecondaryOptions2
 and shapeTertiaryOptions2 is wrong.<br>
<br>
--<br>
Matus Uzak<br>
Software Designer<br>
Ixonos Slovakia s.r.o.<br>
Sturova 27, 040 01 Kosice, Slovakia<br>
mobile <a href="tel:0421%20918%20718" value="+358421918718" target="_blank">0421 918 718</a> 958<br>
email: <a href="mailto:matus.uzak@ixonos.com" target="_blank">matus.uzak@ixonos.com</a><br>
<a href="http://www.ixonos.com" target="_blank">http://www.ixonos.com</a><br>
<br>
________________________________________<br>
From: <a href="mailto:calligra-devel-bounces@kde.org" target="_blank">calligra-devel-bounces@kde.org</a> [<a href="mailto:calligra-devel-bounces@kde.org" target="_blank">calligra-devel-bounces@kde.org</a>] on behalf of Jos van den Oever [<a href="mailto:jos@vandenoever.info" target="_blank">jos@vandenoever.info</a>]<br>
Sent: Tuesday, January 03, 2012 1:17 PM<br>
To: Calligra Suite developers and users mailing list<br>
Subject: Re: Patch for msoscheme<br>
<div class="HOEnZb">
<div class="h5"><br>
On Tuesday, January 03, 2012 12:43:18 PM Mani N C wrote:<br>
> Hi Jos,<br>
><br>
> mso-patch for mso.xml will allow filters to parse the attached ppt file.<br>
> Though lot of style information are still missing, I can atleast view the<br>
> file.<br>
> I have tested calligrastage with couple of other files and it works<br>
> fine. If the patch is good enough, I will update Stage filter with this<br>
> patch.<br>
<br>
Thank you for the patch. It looks good and applies and compiles fine. I've<br>
pushed it to msoscheme and calligra.<br>
<br>
Only after pushing i saw that you have a branch on gitorious i could have<br>
pulled from.<br>
<br>
<a href="http://gitorious.org/msoscheme/msoscheme/commit/2b6d38010f1953ee96be087f4ec3e428ff2a1c06" target="_blank">http://gitorious.org/msoscheme/msoscheme/commit/2b6d38010f1953ee96be087f4ec3e428ff2a1c06</a><br>
<br>
Cheers,<br>
Jos<br>
_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org" target="_blank">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
<br>
_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org" target="_blank">calligra-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/calligra-devel" target="_blank">https://mail.kde.org/mailman/listinfo/calligra-devel</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
Mani Chandrasekar<br>
<br>
</div>
</div>
</div>
</div>
</body>
</html>