Trouble with curved*Arrow shapes

Michael Stahl mst at
Wed May 4 10:07:16 UTC 2022

hi Regina,

sorry i was too distracted to notice your mail last week...

On 04.05.22 08:29, Miklos Vajna wrote:
> On Wed, Apr 27, 2022 at 02:10:14PM +0200, Regina Henschel <rb.henschel at> wrote:
>> A different approach could be to not care about existing documents in the
>> code. Perhaps provide a macro to repair a shape for those users, who are
>> affected.
>> So what to do? Do you have different, better ideas?
> Did you consider fixing the import/export do behave correctly and then
> add an import-time check using the generator string's version to repair
> old documents automatically on import?
> git grep isGeneratorVersionOlderThan xmloff/
> Gives some examples where we do this already.

is it possible to read the path from the file and convert it to 
something that will be interpreted in the same way by old LO versions 
and future fixed LO versions?

it looks like it could be: in a sequence of multiple V commands, the 2nd 
one is replaced by W?

... this would mean that the fix is "idempotent", you can import a file 
written by old LO, import in fixed LO, write the fixed file, open it in 
old LO, and it will write "V...W..." and another import into the fixed 
LO will change nothing (not apply a duplicate fix that would be wrong).

so if i didn't misunderstand things, a generator check + fixing the path 
on import + fixing the painting of V looks like the best approach.

you'll probably need to add a new version number for the generator 
check, and it would be really helpful to know if the next release will 
be 7.4 or 8.0 ... hmm on second thought, if it's checked to be at least 
7.4 then it will work in either case, 8.0 being "larger".

currently we have this in xmlimp.hxx, and some version code that needs 
adapting in xmlimp.cxx:215:

   static const sal_uInt16 LO_7x = 70

>> In XMLEnhancedCustomShapeContext::startFastElement() I could postpone GetEnhancedPath() to after the switch (#1057 to #1134) and pass on Type to it. Then in GetEnhancedPath itself I could correct the segments depending on Type before creating the property (#829). All in /core/xmloff/source/draw/ximpcustomshape.cxx.

is it necessary to check the type? perhaps just checking the generator 
version is enough?


More information about the LibreOffice mailing list