Talk:TextAlignment

Simplify Tables

Planning for the solution may be simplified if we observe that in the two large tables (both preceded by "Conversion for a certain paragraph or table cell:") the writing direction of the document (first column) is irrelevant, having no effect on the outcome case (last column). Thus, the first column and the entire last half of the tables can be omitted.

Likewise, the origin ("Inherited from style") of the direction attribute seems irrelevant, and need not be called out. This eliminates a couple of rows. --TJ (Talk | Contribs) 18:33, 27 July 2010 (UTC)

Thank you very much for your feedback.

Yes, the tables could be simplified, but not as far as you proposed.

The first column makes the difference for the cases in which the writing direction of the document and the paragraph/table cell differs and the text alignment value is inherited from the style.

I will update the tables today.

Looking forward to further feedback/comments/improvements/...

Then perhaps there are rows missing? I have added Row 3 (here, not on the main page):

text alignment value	writing direction of paragraph/table cell	writing direction of document	maps to UNO-API text alignment value
LEFT	left-to-right	left-to-right OR right-to-left	START
LEFT inherited from a style	left-to-right	right-to-left	START
LEFT inherited from a style	left-to-right	left-to-right	???

If the "???" value should be START, then Rows 2 and 3 (and the document-direction column) are irrelevant; that is, if all three cases result in LEFT -> START then only one case (Row 1) should be shown.

Likewise, if changing only the value in the document-direction column makes no difference in the outcome, then the column is irrelevant; the Row 3 example above (and the three other similar entries) is the only place I see where it might have any effect.

Sorry if I'm being a pain about this, but this is obviously a complex problem. Simplifying it as much as possible at this stage should make the remaining work much easier. --TJ (Talk | Contribs) 10:05, 28 July 2010 (UTC)

Now, I see which information I had not given.

In general when an attribute value is inherited, the object does provide the value, but also states that it inherits it. A conversion of inherited attribute values is not necessary, because the conversion already takes place at the style. This is used, when collecting the attributes for a certain paragraph in order to create its ODF automatic paragraph styles containing its hard set attributes inherited. Such a collection does not contain attributes whose values are inherited from a style. The second row indicates such a case. In this case the object has to overrule the inheritance, because the LEFT inherited from its style is converted to END - see the conversion table for styles. But, the object has to provide value START. Thus, inherited text alignment values LEFT and RIGHT needs to be provided as hard set text alignment values START respectively END, if the writing direction from the object differs from the writing direction of the style/document. --Od 07:34, 29 July 2010 (UTC)