Trouble with curved*Arrow shapes

[Michael Stahl]

On 04.05.22 15:59, Regina Henschel wrote:
> 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.

i don't understand this fully ... your commit only changes what path 
some "type" string like "mso-spt102" maps to, but doesn't change how a 
path attribute is read from an ODF file?

is it only intended to have an effect on MSO format import?

ah, now i see another commit 8ad4fdb1687e705e31d9a4f30b385d50b91def08 
for the ODF import...

okay so it's checking for a type "mso-spt102" and applying the fix in 
that case... so the assumption is that no other application than OOo/LO 
would produce such type attributes, which may well be the case.

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

"import from a slide" would involve the ODF import, so it should apply 
such a bugfix; i don't know about galleries but most likely these are 
not real ODF files (with meta.xml) so the generator is likely useless there.

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

your fix checks for Count = 2, so it will also be applied only once.

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

sounds good :)

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

i guess for the fix it doesn't matter much what other applications do, 
as long as they don't produce something with these magic type strings 
but a completely different purpose; i suspect the risk for that is quite 
low.

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

yep, definitely a good reason!