Hi Regina,
Regina Henschel <rb.hensc...@t-online.de> 於 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
