To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=972
------- Additional comments from [EMAIL PROTECTED] Fri Feb 23 22:55:54 +0000 2007 ------- Hi mba, I think there is (at least) one good solution: > OTOH if we made it a real option for positioning as also requested > in comments in this issue we had to calculate the position of the > formula each time when we load the document. Not if you store the information twice in the file format: - Store the information that the formula is baseline aligned - Store the current value where it was last positioned. The latter will allow quick positioning when the document is loaded, the former will contain the rule for recalculation whenever recalculation becomes necessary. > We also face contradiction in the OASIS TC as this positioning will force > any ODF readers to reimplement the baseline calculation by themselves. Not a good argument imho. Any word processor displaying wanting to display documents has already to do quite a lot of calculations in oder to correctly display a document's layout. I cannot believe adding baseline recalculation makes that much of a difference then. Maybe this issue can be relaxed if the ODF specification contained a proposed calculation algorithm in programming language independent form. Converting this into C, Java, whatever should then not be a big problem. Maybe someone could even write a small utility program that could be used from different software. (Just thinking loud.) ... Or am I misunderstanding the concerns here? My opinion is that any solution, whatever it may be, must always store the information that the formula was aligned by the basemap IN THE DOCUMENT. Quick hacks, e.g. trying to infer this information from, lets say, any static position of the formula as suggested above will only cause us grief later - and they are unreliable. I'd rather have document format change in order to get a CLEAN solution than a quick hack that works in 90% of all cases only (any maybe in OOo, but not KOffice or something like that) > It would be bad for its reputation if only a few months after its > birth we changed it incompatibly. We are not talking about "few months after its birth" any more now. Of course, the number of incompatible file format updates must be kept to a minimum, but how else will there be significant progress in OpenDocument if not by extending the standard. Not that this would not impact backward compatibility, so old documents would not become invalid. ... And you can expect people to update their software from time to time, especially if it is Open Source software like OOo or KOffice. > I'm even afraid that old OOo versions will report an > error on loading documents with a new value for "vertical-pos" (though I'm not > sure). This would be even worse compared to MS Office problems of the past. If so this would be bad indeed, but it would show a general problem that must be solved both in the ODF specification and the software: Any specification compliant software should be required to accept (or ignore) formerly unknown elements in the file format without throwing exceptions!!! It must have a fallback solution in case it doesn't know the value for a known attribute. Just my 2 cents. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
