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