transparency <-> opacity in import from MS Office

[Miklos Vajna]

Hi Regina,

On Thu, Dec 15, 2022 at 08:25:29PM +0100, Regina Henschel <rb.henschel at t-online.de> wrote:
> if a MS Office user sets 80% Transparency for a stroke, MS Office writes
> this as
>    <a:alpha val="20000" />.
> That means, that MS Office writes it out as opacity (which corresponds to
> the OOXML spec).

Yes, this matches my understanding.

> But if a MS Office user sets 80% Transparency for the fill or outline of a
> character, MS Office writes this as
> <w14:alpha val="80000" />.
> That means, that the value means transparency.
> 
> Up to now there was no problem as the character outline cannot be rendered
> at all in LibreOffice and character fill transparency could be rendered but
> is not imported yet.

Hmm, this may be supported partially, at least I think it worked for me
for one case in commit 3a749d7278bbe65cfc063e64460df8af6bc2af47 (sw: add
DOCX import for semi-transparent text, 2020-01-15).

> But with implementing Fontwork this <w14:alpha> element will be rendered as
> stroke transparency. So somewhere a conversion from transparency to opacity
> has to be done.
> 
> I could do this in Color::addTransformation() in general or I could do this
> isolated in my new Fontwork import.
> 
> I would like to do this in Color::addTransformation().  What is your opinion
> on this?

In general, I think oox::drawingml::Color is meant to represent OOXML's
idea about a color. So converting the value there looks a bit odd, but
recording if the value means transparency or opacity (depending on if it
comes from the "a" or "w14" namespaces) is fine.

And then once you arrive to the point where you would copy the value to
an UNO API property, there you can decide if the value in
oox::drawingml::Color needs a conversion or not.

At least that's how I would do it, if you ask me. :-)

Regards,

Miklos