Trouble with curved*Arrow shapes
rb.henschel at t-online.de
Wed May 4 13:59:11 UTC 2022
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
>>> code. Perhaps provide a macro to repair a shape for those users, who are
>>> 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.
More information about the LibreOffice