[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: Formula Shape - Inferred rows
From: Alfredo Beaumont <alfredo.beaumont () gmail ! com>
Date: 2007-07-12 16:13:58
Message-ID: 200707121813.59266.alfredo.beaumont () gmail ! com
[Download RAW message or body]
Az, 2007eko Uztren 11a(e)an, Martin Pfeiffer(e)k idatzi zuen:
> > See section 3.1.3.1 titled "Inferred mrows". As it's said there, msqrt,
> > mstyle, merror, menclose, mpadded, mphantom, mtd and math may have
> > inferred mrows.
>
> Good we talk about it because the spec says:
> 3.1.3.1 Inferred mrows
> The elements listed in the following table as requiring 1* argument (msqrt,
> mstyle, merror, menclose, mpadded,mphantom, mtd, and math) actually accept
> any number of arguments. However, if the number of arguments is 0,
> or is more than 1, they treat their contents as a single inferred mrow
> formed from all their arguments. Although the math element is not a
> presentation element, it is listed below for completeness.
>
> I understand it that they behave like row elements and there is nothing
> written about elements that are allowed to have inferred rows as their
> children.
Nothing written about elements allowed to have inferred rows as
children ? "However, if the number of arguments is 0, or is more than 1, they
treat their contents as a single inferred mrow"
> So in fact, as inferred means the same as derived, we should just
> derive from RowElement which inherits all the interesting functionality.
Well, that's actually what we do! InferredRow just inherits everything from
RowElement, it just only adds an extra check to see wether it has an inferred
mrow or not. I don't really see the whole point of this discussion, you have
to check whether you have an inferred mrow at some point, so what's wrong
with my solution ? I have already explained several times why I did this, it
works nice and I have yet not seen any reason not to do this way.
> > I think we need some good 'native' constructs. Letting the users define
> > their own ones sounds nice, if we have time to develop it :-)
>
> You are right! And to be honest I don't really like what OO offers, or
> better say I partly dislike it. Do you know where to look for a sensefull
> set of "templates" ?
Not really, but I guess we could take a look at kile, abiword, oomath and such
applications.
> > > elementType() == Basic gives the information if there is already an
> > > element existing that is worth interacting with, just as example:
> > >
> > > Loading code of FractionElement with BasicElements as "empty" :
> > > forEachElement( tmp, parent ) {
> > > if( m_numerator->elementType() == Basic )
> > > m_numerator->readMathML( tmp );
> > > else
> > > m_denominator->readMathML( tmp );
> > > }
> > >
> > > and with RowElements ( there is a counter ):
> > > int counter = 0;
> > > KoXmlElement tmp;
> > > forEachElement( tmp, parent ) {
> > > if ( counter == 0 ) {
> > > if ( ! m_numerator->readMathMLChild( tmp ) ) return false;
> > > }
> > > else if( counter == 1 ) {
> > > if ( ! m_denominator->readMathMLChild( tmp ) ) return
> > > false; }
> > > else
> > > return false;
> > > counter++;
> > > }
> >
> > Well, there's an important difference. In the second case, we can say
> > whether we have read valid MathML. We cannot say the same with the first
> > code.
>
> Yeah I missed the validation but the validation has nothing to do with the
> counter. The counter has to be used because you can not use elementType().
> This was the point I wanted to make.
Wrong. Counter is used because you wrote a loop. I'd have done it without it:
{
KoXmlElement e = parent.firstChildElement();
if ( e.isNull() || ! m_numerator->readMathMLChild( e ) ) return false;
e = e.nextSiblingElement();
if ( e.isNull() || ! m_denominator->readMathMLChild( e ) ) return false;
return true;
}
>
> > > Depends on how you generate the tree: If you walk the element classes
> > > then you will have
> > >
> > > FractionElement
> > > RowElement
> > > OperatorElement
> > > RowElement
> > > NumberElement
> > >
> > > instead of
> > > FractionElement
> > > OperatorElement
> > > NumberElement
> > > what I consider to the thing you loaded.
> >
> > Well, the thing you loaded is both the first and the second, since they
> > are equivalent. Do you want to provide different code for both ? I don't
> > think that's very useful.
>
> I never said I want to provide code for both. I just wanted to show the
> differences that are made through this. That you get a tree with additional
> mrows if you use RowElements for "empty elements"
Right. But that's fine with me because it's equivalent notation.
> > I don't really understand how are you going to handle two (or more)
> > different cases without any conversion and without writing code to handle
> > those different cases.
> >
> > About the conversion... Consider you start with:
> >
> > <mfrac>
> > <mi>x</mi>
> > <mi>y</mi>
> > </mfrac>
> >
> > that is: x/y. Now the user inserts +3 in the numerator, having: x+3/y.
> > How are you going to do that ? You have to cut your identifier, create a
> > row element, and insert the identifier you cut plus the operator and
> > number. In markup:
> >
> > <mfrac>
> > <mrow>
> > <mi>x</mi>
> > <mo>+</mo>
> > <mn>3</mn>
> > </mrow>
> > <mi>y</mi>
> > </mfrac>
> >
> > Now, the user decides he was wrong and deletes +3. Now you would have to
> > remove the '+' and the '3'. Now you have a RowElement with just one
> > element, and you end up with my second markup:
> >
> > <mfrac>
> > <mrow>
> > <mi>x</mi>
> > </mrow>
> > <mi>y</mi>
> > </mfrac>
> >
> > Of course, you could convert this to the first markup again, adding some
> > extra checking: you would have to check that you have a RowElement with
> > one element and check whether that row element may be removed. Not to say
> > what would happen if the user decides to remove that single element
> > aswell, create an empty mrow ?
>
> On how to do inserting look in my previous mails, that is absolutly no
> problem, and removing the same. You are right, I would check for empty row
> elements and replace them with BasicElements.
> Perhaps I will code my solution and send you a patch for review. Than we
> dont talk about vapour ware.
You can code it if you wish, but it's not that hard to see that it's going to
be a more complex solution than what we currently have.
>
> > Now the user can add or remove whatever she wants, RowElement will
> > automagically take care of it. If the user adds +3, rowelement will add
> > an operator and a number. If the user removes +3, rowelement will remove
> > the operator and the number. If the user removes 'x' too, we would just
> > have and empty row.
>
> An empty row for you is not different to a basic element for me ^^
It is, since an empty element must be a mrow element. These are invalid:
<mfrac>
</mfrac>
<mfrac>
<mi>x</mi>
<mfrac>
And of course, current output generated with BasicElement saving is also
invalid:
<mfrac>
</>
</>
</mfrac>
Correct output would be:
<mfrac>
<mrow></mrow>
<mrow></mrow>
</mfrac>
To be fair, I don't really understand why we are investing time in such
discussions about rewritting code that already works, for little or no gain,
when we are so delayed in our release schedule. Thus, I would like to end
this discussion. If you are really convinced it's going to be a simpler and
easier to understand and maintain, and you are going to write all of it, just
do it and commit.
Cheers.
--
Alfredo Beaumont Sainz
http://www.alfredobeaumont.org/blog.cgi
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic