transparency <-> opacity in import from MS Office

[Regina Henschel]

Hi Miklos,

Miklos Vajna schrieb am 16.12.2022 um 15:24:
> 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).

Indeed. It works for "srgbClr". I run into bug tdf#130973. I think the 
case "schemeClr" is missing in 
TextEffectsHandler::GetTextFillSolidFillAlpha.

So w14:alpha ==> CharFillTransparence works and uses transparency,
and a:alpha ==> FillTransparence or LineTransparence works and uses opacity.

> 
>> 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,
You are right. The problem only occurs in switching Fontwork on. So it 
is better to make the change at that place.

  but
> recording if the value means transparency or opacity (depending on if it
> comes from the "a" or "w14" namespaces) is fine.


Color::addTransformation() drops the namespace and Color has no member 
to store a namespace, so the information whether it was a w14:alpha or a 
a:alpha is lost. Currently that seems to be no problem.

> 
> And then once you arrive to the point where you would copy the value to
> an UNO API property,

I do not write to UNO API property directly, but generate LineProperties 
and FillProperties objects and use their pushToPropMap methods. 
Otherwise I would need to duplicate the 300 lines of gradient handling 
which is included in pushToPropMap.

  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. :-)

I have put is now where the Fontwork shape is created. It is now
rColor.addTransformation(
     oox::NMSP_dml | oox::AttributeConversion::decodeToken((*it).Name),
     oox::drawingml::MAX_PERCENT - nNumber);
Previously it was
rColor.addTransformation(
     oox::NMSP_w14 | oox::AttributeConversion::decodeToken((*it).Name), 
nNumber);

You will see it when the next version is uploaded.

BTW: I make progress, dashes are handled now. Now I'm working on unit 
tests. But so short before Christmas there are a lot of other things to do.

Thank you for looking at the problem.

Kind regards,
Regina