Trouble with curved*Arrow shapes

[Regina Henschel]

Hi Michael, hi Miklos,

thank you for looking at it.

In the meantime my solution is in commit 4cfe4699. The corresponding bug 
is 148714. But of cause, I will change it, if you have a better solution 
or find another problem with this commit.

Michael Stahl schrieb am 04.05.2022 um 12:07:
> 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 t-online.de> 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.

I have not considered to use the generator string. But thinking about 
it, would it catch the case, that someone has kept these arrows in his 
Gallery or imports it from a slide from older documents? That is, what 
'Generator' is used in those cases?

> 
> 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?
Yes, that is my solution know. I replace V with count 2 by a V with 
count 1 followed by W with count 1 at start of a path.

> 
> ... 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.

Fix painting of V is bug 148707. That will be my next step.

> 
> 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?

The check for Type restricts the change to these arrows created by LO or 
AOO. For these shapes it is sure, that connecting the arcs is intended.
I don't know whether other applications have a similar error than LO or 
AOO. MS Office at least generates correct sequences when exporting such 
arrows to ODF and it renders multiple B and multiple V commands ODF 
conform. I don't know, what Linux specific applications do.

The fact, that MS Office renders multiple B and multiple V ODF conform, 
has been the reason for me starting to fix it for LO.

Kind regards
Regina