<div dir="ltr"><div dir="ltr">Hi Regina,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Regina Henschel <<a href="mailto:rb.henschel@t-online.de">rb.henschel@t-online.de</a>> 於 2022年6月16日 週四 晚上8:49寫道：<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
Currently the "vert" attribute of <bodyPr> element is connected to <br>
TextPreRotateAngle property. vert="vert" produces TextPreRotateAngle=-90 <br>
and vert="vert270" produces TextPreRotateAngle=-270. When converting it <br>
to ODF it produces draw:text-rotate-angle="-90" and <br>
draw:text-rotate-angle="-270".<br>
<br>
That approach does not work, because the ODF attribute <br>
draw:text-rotate-angle produces a rotation of the text area rectangle, <br>
same as the 'rot' attribute of element <bodyPr> in OOXML. Try with <br>
attached file the export to ODF and reload to see the problem.<br>
<br>
For using draw:text-rotate-angle attribute it would be necessary to <br>
change the values of the draw:text-areas attribute in addition. But this <br>
requires introducing additional equations and it conflicts with the <br>
definitions of the predefined shapes of the presets.<br>
<br>
My idea is to introduce a new loext:text-direction attribute of the <br>
<draw:enhanced-geometry> element, which can carry each of the values of <br>
the OOXML attribute 'vert'. "Each" needs to be discussed, perhaps better <br>
to exclude values eaVert and mongolianVert, which in fact are writing <br>
modes TB_RL and TB_LR. Possible values would be ("eaVert"), "horz", <br>
("mongolianVert"), "vert", "vert270", "wordArtVert" and "wordArtVertRtl".<br>
<br></blockquote><div><br></div><div>It's not clear to me why you think eaVert, and mongolianVert should be excluded here.</div><div>Maybe you can explain further.</div><div><br></div><div>It seems to me that:</div><div>- horz, vert, vert270 are effectively horizontal (LR_TB or RL_TB) with different rotation angles.</div><div>CJK text ( along its upright axis ) is perpendicular to the run direction.</div><div><br></div><div>- eaVert, wordArtVertRtl : TB_RL. CJK text is parallel to the run direction.</div><div><br></div><div>- mongolianVert, wordArtVert: TB_LR. CJK text is parallel to the run direction.<br></div><div><br></div><div>Both wordArtVertRtl and wordArtVert don't apply rotation to Latin scripts - which I think is something missing in LibreOffice.</div><div>We don't have the attribute to keep the state. We always render Latin script text in vertical writing as same as in horizontal writing, only rotate the whole run.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The CustomShapeGeometry property, which is a sequence, would get a new <br>
property "TextDirection". Import from OOXML or from ODF-extended would <br>
put the value into it without any rotate-angle calculations. Evaluation <br>
of the attribute would be at rendering time in <br>
ViewContactOfSdrObjCustomShape::createViewIndependentPrimitive2DSequence(). </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The current used attribute TextPreRotateAngle would be removed. <br>
Currently it can be used in the CustomShapeGeometry sequence via macro, <br>
but is not published in the API and has no UI.<br>
<br>
Currently we have a confusion of attribute 'vert' and attribute 'rot' <br>
resulting in bug 124437 (assigning the angle of the 'rot' attribute to <br>
TextPreRotateAngle, which produces sheared text) and bug 127457 (value <br>
of attribute 'vert' overwrites value of 'rot'). Therefore I prefer an <br>
enum (or constants in API or string?) so that such errors cannot happen.<br>
<br>
What do you think?<br>
<br>
Kind regards,<br>
Regina<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Mark Hung<br></div></div></div></div>