<div>Hi,</div><div><br></div><div>I would like to add that Theme Colors from MSOOXML are causing us big problems (invisible text mostly) because named styles and MasterSlide/SlideLayout styles (PPTX) are based on them.  The color map might change with each slide/section of a document.  At the moment we calculate the color for named styles in order to support automatic colors (inlcudes several methods to calculate the actual color) and styles inheritance.  Otherwise we would need to check all styles after processing section/slide and replace values of color related attributes (set to "lt1 for example) by the color from actual color map.  Then recalculate all automatic colors which includes background/foreground color info and additional MSOOXML specific attributes which we can not map to ODF.</div>
<div><br></div><div>-Matus</div><div><br></div><div>On Tue, Mar 26, 2013 at 8:51 AM, Lassi Nieminen <span dir="ltr"><<a href="mailto:lassniem@gmail.com" target="_blank">lassniem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hola,<br><br><div class="gmail_quote"><div class="im">On Mon, Mar 25, 2013 at 8:12 PM, Inge Wallin <span dir="ltr"><<a href="mailto:inge@lysator.liu.se" target="_blank">inge@lysator.liu.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On Monday, March 25, 2013 17:54:53 <a href="mailto:matus.uzak@gmail.com" target="_blank">matus.uzak@gmail.com</a> wrote:<br>
> Hi,<br>
><br>
> sorry for not discussing earlier, but I did not have much free time last<br>
> two weeks.<br>
><br>
> I think we should continue the parser type discussion in order to also<br>
> improve state of things in libmsooxml.  What we have there is a PULL<br>
> parser. And I identified the following problems (Would be cool is Lassi<br>
> could check those):<br>
><br>
> 1. OOXML sometimes requires us to run the parser twice at one element in<br>
> order to first collect selected information required to convert the content<br>
> of child elements.<br>
><br>
> 2. There are situations when conversion of the 1st child of the root<br>
> element requires information from the last child of the root element.<br>
<br>
</div>It would be interesting to see some examples of these two issues.</blockquote><div><br></div></div><div>As an example : in pptx files, in slides,</div><div>there can be text which is specified to use theme color lt1</div>

<div><br></div><div>Don't remember the exact syntax, but something like</div><div><p></div><div><rPr "color" = "lt1"/></div><div><r>Hejsan</r></div><div></p></div><div>

<br></div><div>Then as the last element of that slide there may or may not be</div><div><clrMap "lt1" = "bg1" ...../> // or something similar</div><div><br></div><div>Which means that lt1 should be interpreted to be bg1 for this particular slide.</div>

<div>Currently what we're doing is that we first read the slide once, skipping everything</div><div>except clrMap. Then we read the slide again (yay!) and start the real conversion.</div><div><br></div><div>There was something similar in xlsx filters too if my memory serves me correctly.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>-Lassi</div></font></span></div>
<br>_______________________________________________<br>
calligra-devel mailing list<br>
<a href="mailto:calligra-devel@kde.org">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></blockquote></div><br>