office-collab — archive

[Andreas Guelzow]

On Wed, 2011-10-26 at 08:37 -0600, Robin LaFontaine wrote: > Yes, some confusion here I think, we have drifted off the original > topic which was to do with the need to diff data to find out what has > changed. Ben asserted that in ECT this diffing of draw:frame was > needed to establish that only the ct:id attribute had changed, but in > GCT the change to that specific attribute was explicit. > > Ben's assertion is true: he says that it is necessary with the ECT > representation to compare the old cached draw:frame with the current > one to work out if the ct:id has changed or perhaps the caption, it > could be either or both (or something else, perhaps the svg:width > attribute etc). The point is that with a cached element you do not > know which bit has changed, you need to work it out. > > Andreas points out that the attribute change may not be a 'real' > change, which is a fair point and the (producing) application would > need to work that out and not indicate a false change. (I don't think > we have ever discussed how to show a change in the situation where > the .jpg file (in your example) has been edited but has the same name > and size, i.e. the draw:frame XML has not changed at all. I think that > is outside the scope of what either ECT or GCT is trying to achieve.) But this really should not be outside the scope! The first image in a Gnumeric generated ODS file is always Image1.xxx. So replacing a jpg with another jpg will always retain the image name in the package. In ECT this would be marked as a draw:frame change I would think. What would be happening under GCT? Andreas -- Andreas J. Guelzow, PhD, FTICA Concordia University College of Alberta