Hello,<br><br>a comment from filters point of view:<br><br>> In regards to the test sets: I would really prefer to have a test set that<br>
> easily calculates a score for each product. That is however quite some work.<br>> We have some tests in calligra, that would be better to have outside Calligra.<br>
<br><a href="http://websvn.kde.org/trunk/tests/calligratests/interoperability/">http://websvn.kde.org/trunk/tests/calligratests/interoperability/</a><br>
<br>Each of those files is meant to test a single feature or a set of related features.  Only a few of those have an accompanying test file, which should ensure that the corresponding filter is intact.<br>From my experience, files we use for cstester are not representative enough which results in undetected broken filter outputs or incorrect layout of very simple files located in the interoperability directory.    <br>
It would be beneficial to prepare the missing XSL templates to test filter outputs and use those files with cstester.<br><br>Wasn't there a plan to merge the interoperability content with test files from the LO community?<br>
<br>btw. Who prepared those interoperability files (the Wipro team)?  <br><br>-matus <br><br><div class="gmail_quote">On Fri, Apr 20, 2012 at 12:03 PM, Jos van den Oever <span dir="ltr"><<a href="mailto:jos.van.den.oever@kogmbh.com">jos.van.den.oever@kogmbh.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Thursday 19 April 2012 13:48:52 PM Friedrich W. H. Kossebau wrote:<br>
> so here my list of issues that I have had with ODF so far. Please consider<br>
> putting them on the table for the plugfest as well as for the TC call :)<br>
<br>
</div>I have brought up some points in the discussion.<br>
<div class="im"><br>
> A) no official test suite<br>
> B) spec vs. reality: how to handle files from broken ODF producers<br>
> C) no feedback on office-comment list<br>
> D) handling of custom shapes just a hack ATM?<br>
> E) things I would have posted to the office-comment list if it felt live<br>
><br>
><br>
> A) No official test suite<br>
><br>
> As discussed on the ml, would be really good to have that, similar to what<br>
> there is for SVG at least.<br>
> The "OpenDocument Fellowship Test Suite" as used e.g. for<br>
> <a href="http://officeshots.org/galleries/view/opendocument-fellowship-test-suite" target="_blank">http://officeshots.org/galleries/view/opendocument-fellowship-test-suite</a><br>
> might be a start.<br>
<br>
</div>This is a common problem. KDE has a repository. There are some collections of<br>
files. A common repository would be a good idea. I've grilled the plugfest<br>
organizers on creating a repository. The reaction to this, which is the same<br>
for a long time, is to bring up a lot of potential problems instead of<br>
actually starting something. Currently the plugfest uses 'scenarios' which are<br>
not automated but require people to go through them. This is very inperfect<br>
and should be upgraded and I will continue to press for a plugfest-NG which<br>
has more automated scenarios.<br>
<div class="im"><br>
> B) Spec vs. reality: how to handle files from broken ODF producers<br>
><br>
> E.g. LO (and so might OOo) do not meet the ODF 1.2 spec, section 19.228<br>
> draw:transform, where it says skewX/skewY should be given in degrees.<br>
> Instead they store the angle value as radian (and in clockwise direction)<br>
> (bug filed for LO as <a href="https://bugs.freedesktop.org/show_bug.cgi?id=48342" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=48342</a>).<br>
> And Calligra follows that behaviour.<br>
><br>
> Things like this screw the ODF spec. It needs to be handled.<br>
> But how?<br>
> * Fix ODF producers to produce spec-complying documents, and have consumers<br>
> detect the producer version and handle the read values by the version?<br>
> * Adapt the spec to reflect reality?<br>
><br>
> Anyway, the current behaviour of the spread ODF producers IMHO should be<br>
> added as note to the spec, so implementors of ODF consumers know what to<br>
> expect.<br>
<br>
</div>I did not get a chance to bring this up.<br>
<div class="im"><br>
> C) No feedback on office-comment list<br>
><br>
> The official comment mailing list feels like writing to /dev/null. While<br>
> there is an automated monthly reminder which has this section<br>
> --- 8< ---<br>
> 3)  The TC has agreed to consider all submitted comments, regardless of<br>
> when they were submitted.  Although you may not receive an immediate<br>
> response from the TC, be assured that your comments have been archived on<br>
> the list, and you can track their resolution via JIRA, as explained below.<br>
> --- 8< ---<br>
> there has not been any official reply from the TC or any JIRA related<br>
> follow- up, at least visible in the the archives for the emails since Jan.<br>
> 1st 2011 and personally on the emails I posted there the last months.<br>
<br>
</div>We had a long discussion on this topic. Within ODF the workflow is such that<br>
publicly discussing the comments is discouraged. This means that there is a<br>
large delay between submitting a comment and it being handled by the TC<br>
members and even getting a reply back to the commenter.<br>
<div class="im"><br>
> D) Handling of custom shapes just a hack ATM?<br>
><br>
> The current storage looks like a hack to me, it is no-where specified in<br>
> the spec, is it? And it does not survive a round-trip to a ODF<br>
> consumer/producer which does not support that custom shape. Which I<br>
> consider a fail :(<br>
<br>
</div>Custom object types is a recurring problem that comes up as a scenario every<br>
time and never works properly across all the products. How to save unknown<br>
objects back when saving is indeed not specified. The storage in a zip file is<br>
documented, that is not a hack.<br>
<div><div class="h5"><br>
> E) Things I would have posted to the office-comment list if it felt live<br>
><br>
> 1. line end markers are shitty<br>
> * no support for markers which are not centered at the Y-axis<br>
>   (think half-headed spear arrows)<br>
> * markers do not adapt to the stroke width -> ugly unless certain width<br>
>   while it's nice to be able to freely define the shape of a marker<br>
>   this does not work with the typical arrows.<br>
>   given that there is a set of commonly used arrow types it would be better<br>
> to hardcode identifiers for these types and have the ODF consumers care<br>
> for the actual rendering themselves, so being able to take care of nicely<br>
> integrating with the line stroke<br>
>   would also solve the problem with translations of the arrow/marker types<br>
>   the free definition of marker shapes should be still available of course<br>
>   or the stroke width should be available as parameter somehow to<br>
>   automatically the marker width, thus the marker fits<br>
> * only width stretching of markers possible, but not independently of<br>
> length * not possible to use multiple colors or fillings, i.e. complex<br>
> shapes e.g. the markers with "holes" in it are ideally filled with e.g.<br>
> white, not transparent. Or think of a pointing hand as arrow. Why not make<br>
> this possible?<br>
><br>
> 2. fillings do not support complex patterns, like SVG does<br>
><br>
> 3. spec misses to define for angle parameters the direction of the angle<br>
>    (clockwise or counter-clockwise)<br>
><br>
> 4. no parameter to say if fillings should be below or above outer line<br>
><br>
> In general it might also be a good idea to provide coders of import filters<br>
> a way to collect all things from other formats that cannot be mapped to<br>
> ODF. I would have guessed office-comment list is for that, but well, if it<br>
> is it needs improvements to encourage people to commit there.<br>
<br>
</div></div>The comments mailing list is only for comments about the contents of the ODF<br>
standard. It is not meant to discuss interoperability with other standards.<br>
Thre is a separate TC for interopability:<br>
  <a href="http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=oic" target="_blank">http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=oic</a><br>
<br>
In short: I a equally frustrated with the abundance of talk and a lack of<br>
actual work. The best thing to do is the common KDE approach: who codes<br>
decides. To move the TC forward, it is best to join and make things happen.<br>
<br>
In regards to the test sets: I would really prefer to havea test set that<br>
easily calculates a score for each product. That is however quite some work.<br>
We have some tests in calligra, that would be better to have outside Calligra.<br>
<br>
A good idea might be to organize a sprint to make such a system. The sprint<br>
should have coders that are involved in the unit testing of the different<br>
products and the goal should be to make a repository of tests that can be<br>
automatically evaluated, for example by convering documents to pdf and<br>
analyzing the picture or round-tripping and evaluating the result. For<br>
calligra, I already made some tests like this written in a way that is<br>
calligra-independent for document import [1]. We could make similar tests for<br>
round<br>
<br>
Cheers,<br>
Jos<br>
<br>
[1] <a href="http://websvn.kde.org/trunk/tests/calligratests/import/powerpoint/" target="_blank">http://websvn.kde.org/trunk/tests/calligratests/import/powerpoint/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Jos van den Oever, software architect<br>
<a href="tel:%2B49%20391%2025%2019%2015%2053" value="+4939125191553">+49 391 25 19 15 53</a><br>
074 3491911<br>
<a href="http://kogmbh.com/legal/" target="_blank">http://kogmbh.com/legal/</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br><br clear="all"><br>-- <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: <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>