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@xxxxxxxxxxx> 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
