Trouble with curved*Arrow shapes
mst at libreoffice.org
Thu May 5 12:15:10 UTC 2022
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
>>>> 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
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
> 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!
More information about the LibreOffice