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