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@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?
"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!
