[xliff-comment] Thoughts about Reformat

[Yves Savourel <ysavourel@translate.com>]

Some thoughts about reformat:


-- Need for reformat for all coordinates?

For coordinates I would argue that we don't really need reformat information
for each instance of x, y, cx, and cy. Are there that many cases where we
would want to resize one of the items without others? The only case I could
think of is when resizing a dialog box defined with relative coordinates
(e.g. 0,0,100,200), but I would think the tools would be able to behave
properly.

In my view, I would think that having a reformat information for the whole
set of coordinates is enought, if a tool resize something it better know
what are the constraints for that specific type of data. The only
information it would need (I think) is whether or not it can actually
proceed to do the modifications.

So maybe something 'lighter' like the following would be ok?
  <coord reformat='yes' x='1' y='2' cx='3' cy='4'/>
or
  <coord reformat='yes'>1;2;3;4</coord>


-- Different types of coordinates

It has been talked about the possibility to have two types of coordinates:
one for the x/y/cx/cy type and one for the x1/y1/x2/y2 type. I would think
this may be too much. I would rather see a uniform way to code all
coordinates. Data from systems that use the x1/y1/x2/y2 can be stored in
x/y/cx/cy (with a simple calulation: cx=x2-x1, cy=y2-y1), or conversely.
This would be in line with standardizing representation in XLIFF.

I would also add that having coordinates stored in their original form is
nugatory since a tool may have a different way to represent coordinates than
the resource where they are coming from, and therefore may have to convert
them anyway. For example: a Windows tool showing a Mac dialog box, or a Mac
tool showing a Windows dialog box.


-- Elements versus attributes

There are certainly some positive aspects in moving data to elements as it
was proposed. The main concern is backward compatibility. One thing I would
be worried about is to have an ackward new solution for the shake of a shaky
backward compatibility. In this specific case, in my view, we probably need
to either keep it really close to what we have, or make a big change.

One issue I can see is how using elements will carry into defining those
properties for <group>? For example how would we use <coord> or <font> at
the group level?


Just thinking aloud.
-yves