Re: How to write OOXML attribute 'vert' of element to ODF?

[Mark Hung]

Hi Regina,


>
>
> > I found that I was confused with the name "loext:text-direction", and
> > connected it to writing-mode. > In different context direction may mean
> writing direction in Bidi text,
> > as in [1].
>
> You are right, the name is indeed misleading, probably
> "loext:text-vertical" is better?
>
>
I was thinking text-orientation, but I found it has different meaning some
where ( see below. )
Naming is hard. :-) Apology for not being able to give useful advice on
this.


> > Is that new "loext:text-direction" attribute only intended to rotate
> > text for RL_TB writing mode?
> > ( wordArtVert and wordArtVertRtl should also be excluded in that case? )
>
> "wordArtVer" and "wordArtVertRtl" would be included in principle. But
> both are not yet implemented.
>
> I am not sure if I should go this way at all. My knowledge is enough to
> extend the "extended-geometry" with an additional attribute for "vert"
> and "vert270". And it can be extended to the values "wordArtVert" and
> "wordArtVertRtl" if that is implemented. However, another option would
> be to enable the text in shapes to use WritingMode2 and extend its
> values similar to the current loext:writing-mode="bt-lr". This looks
> better to me for future development. Only I certainly need help for the
> implementation.
>
>
The real use cases might be mixed depending on content,
as described in CJK text layout requirement[1]:
Western text keeps upright as CJK text for single alphabet, digit, or
abbreviation ( ex, GDP ).
Western text rotated 90 degrees for numbers more than 4 digits, longer
phrases, or sentences.
There is a CSS property called text-orientation[2].

Since you're mapping ooxml values to CustomGeometry property, I guess it's
not wrong to include them.

[1]
https://www.w3.org/TR/clreq/#mixed_text_composition_in_vertical_writing_mode
[2]https://developer.mozilla.org/en-US/docs/Web/CSS/text-orientation


Kind regards,
> Regina
>


-- 
Mark Hung

Re: How to write OOXML attribute 'vert' of element to ODF?

[Regina Henschel]

Hi all,

Regina Henschel schrieb am 20.06.2022 um 01:05:

However, another option would 
be to enable the text in shapes to use WritingMode2 and extend its 
values similar to the current loext:writing-mode="bt-lr". This looks 
better to me for future development. Only I certainly need help for the 
implementation.


Using a way with WritinMode2 has the additional advantage, that is can 
be used not only for custom shapes but for text boxes too.


Kind regards
Regina

Re: How to write OOXML attribute 'vert' of element to ODF?

[Regina Henschel]

Hi Mark,

Mark Hung schrieb am 19.06.2022 um 03:04:
[..]

I found that I was confused with the name "loext:text-direction", and 
connected it to writing-mode. > In different context direction may mean writing direction in Bidi text,

as in [1].


You are right, the name is indeed misleading, probably 
"loext:text-vertical" is better?


Is that new "loext:text-direction" attribute only intended to rotate 
text for RL_TB writing mode?

( wordArtVert and wordArtVertRtl should also be excluded in that case? )


"wordArtVer" and "wordArtVertRtl" would be included in principle. But 
both are not yet implemented.


I am not sure if I should go this way at all. My knowledge is enough to 
extend the "extended-geometry" with an additional attribute for "vert" 
and "vert270". And it can be extended to the values "wordArtVert" and 
"wordArtVertRtl" if that is implemented. However, another option would 
be to enable the text in shapes to use WritingMode2 and extend its 
values similar to the current loext:writing-mode="bt-lr". This looks 
better to me for future development. Only I certainly need help for the 
implementation.


Kind regards,
Regina

Re: How to write OOXML attribute 'vert' of element to ODF?

[Mark Hung]

Hi Regina,


> > My idea is to introduce a new loext:text-direction attribute of the
> >  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".
>
> Both "eaVert" and "mongolianVert" are not pure geometrical, but consider
> east asian scripts, so that such characters are excluded from the rotation.



>
> > It seems to me that:
> > - horz, vert, vert270 are effectively horizontal (LR_TB or RL_TB) with
> > different rotation angles.
>
> Yes. That makes it possible to render "vert" and "vert270" by
> incorporating the "TextPreRotateAngle" into aTextBoxMatrix in
>
> https://opengrok.libreoffice.org/xref/core/svx/source/sdr/contact/viewcontactofsdrobjcustomshape.cxx?r=b739bdab#160
>
>
I found that I was confused with the name "loext:text-direction", and
connected it to writing-mode.
In different context direction may mean writing direction in Bidi text, as
in [1].
Is that new  "loext:text-direction" attribute only intended to rotate text
for RL_TB writing mode?
( wordArtVert and wordArtVertRtl should also be excluded in that case? )

[1] https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/direction
-- 
Mark Hung

Re: How to write OOXML attribute 'vert' of element to ODF?

[Regina Henschel]

Hi Mark,

Mark Hung schrieb am 17.06.2022 um 17:17:

Hi Regina,

Regina Henschel > 於 2022年6月16日 週四 晚上8:49寫道：


Hi all,

Currently the "vert" attribute of  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  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
 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.


vert="eaVert" in a shape describes the same as WritingMode2::RL_TB and 
WritingMode::RL_TB. vert="mongolianVert" in a shape describes the same 
as WringingMode::TB_LR. Setting the writing mode is already used for 
"eaVert" in 
https://opengrok.libreoffice.org/xref/core/oox/source/shape/WpsContext.cxx?r=adf7d6ef#70
So it might be better to use that too in 
https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/textbodypropertiescontext.cxx?r=486a11ad#117


AFAIK, we can currently not use WritingMode2 in these places. But 
because WritingMode is deprecated, it might be more seminal to improve 
the implementation to use WritingMode2. And then be able to use "TB_LR" 
for "mongolianVert". We are already able to render "TB_LR" in Writer 
text frames, but not for text in custom shapes.


Both "eaVert" and "mongolianVert" are not pure geometrical, but consider 
east asian scripts, so that such characters are excluded from the rotation.




It seems to me that:
- horz, vert, vert270 are effectively horizontal (LR_TB or RL_TB) with 
different rotation angles.


Yes. That makes it possible to render "vert" and "vert270" by 
incorporating the "TextPreRotateAngle" into aTextBoxMatrix in

https://opengrok.libreoffice.org/xref/core/svx/source/sdr/contact/viewcontactofsdrobjcustomshape.cxx?r=b739bdab#160

The same matrix gets later the "TextRotateAngle" incorporated, which 
describes the rotation of the text area rectangle. And only for that one 
a corresponding attribute is available in ODF.



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.


CJK characters are not rotated for eaVert and mongolianVert.



Both wordArtVertRtl and wordArtVert don't apply rotation to Latin 
scripts - which I think is something missing in LibreOffice.


wordArtVertRTL and wordArtVert are currently not implemented in LO, but 
the rendering in PowerPoint is so, that the CJK characters are not rotated.



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.


Not always. We can render WritingMode::TB_RL (=eaVert) in custom shapes, 
both with and without attached text frame. For import from pptx, I think 
the error is in 
https://opengrok.libreoffice.org/xref/core/oox/source/drawingml/textbodypropertiescontext.cxx?r=486a11ad#116. 
But I have not yet tested it, because first I want a clear separation of 
"TextPreRotateAngle" (attribute 'vert' in OOXML) and "TextRotateAngle" 
(attribute 'rot' in OOXML).


Kind regards
Regina

Re: How to write OOXML attribute 'vert' of element to ODF?

[Mark Hung]

Hi Regina,

Regina Henschel  於 2022年6月16日 週四 晚上8:49寫道：

> Hi all,
>
> Currently the "vert" attribute of  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  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
>  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

Re: How to write OOXML attribute 'vert' of element to ODF?

[Miklos Vajna]

Hi Regina,

On Thu, Jun 16, 2022 at 02:49:45PM +0200, Regina Henschel 
 wrote:
> My idea is to introduce a new loext:text-direction attribute of the
>  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".

Yes, I think the idea to use 'vert' only for Writing direction and not
for rotation is a good one. Thanks for looking into this.

PS: the previous mail got back to me with:

: host mx03.t-online.de[194.25.134.73] refused to talk
to me: 554

I wonder if that's a temporary problem and if that's something on my end
or your end. :-)

Regards,

Miklos

How to write OOXML attribute 'vert' of element to ODF?

[Regina Henschel]

Hi all,

Currently the "vert" attribute of  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  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 
 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".


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


vert270.pptx
Description: Binary data