Re: Problem with reading 'writing-mode' ODF attribute in Impress

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Regina,

On Fri, Aug 26, 2022 at 10:41:06AM +0200, Regina Henschel wrote:
> > The import side is easier, simply the property map has 2 entries and we
> > read all enum values from both namespaces.
> 
> The import part is the problem. loext:writing-mode="bt-lr" is not read, when
> it is used for a shape. When it is used for a frame, there is no problem.
> 
> Which "property map" do you mean?

E.g. the one for Writer TextFrames:

https://github.com/libreoffice/core/blob/95aea41eb9fbb99452097e5b36f09b8782c8dfff/xmloff/source/text/txtprmap.cxx#L871

> Problem is, that style:writing-mode="tb-lr" (OOXML vert="eaVert") and
> style:writing-mode="tb-lr" (OOXML vert="mongolianVert") are correctly loaded
> into 'WritingMode' API-attribute, but loext:writing-mode="bt-lr" (OOXML
> vert="vert270") and my new loext:writing-mode="tb-rl90" (OOXML vert="vert")
> are not loaded. And I have no clue where they are lost.

You could try to see which C++ class implements the setPropertyValue()
member function handling your WritingMode. Perhaps as a start, log the
value of rPropertyValue in SvxShape::setPropertyValue(). If you see
WritingMode there, then you can step in the debugger to see where is
that handled. Possibly the trouble is that we have text::WritingMode and
text::WritingMode2, and these are all sal_Int16 values so implicit
conversion between the two groups is allowed. This means if you write
the value as text::WritingMode2 and later you read it as
text::WritingMode, you won't get a build-time error for that.

Regards,

Miklos



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux