[Libreoffice-bugs] [Bug 130973] FILEOPEN DOCX Transparency setting from schemeClr is unhandled during import(comment 6)

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=130973

Justin L <jluth at mail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=11
                   |                            |1622
            Summary|FILEOPEN DOCX Transparency  |FILEOPEN DOCX Transparency
                   |setting for font effect in  |setting from schemeClr is
                   |paragraph style is not      |unhandled during
                   |displayed                   |import(comment 6)
           Severity|normal                      |enhancement

--- Comment #6 from Justin L <jluth at mail.com> ---
I'm using Word 2016 to look at this document and it is VERY confusing, because
depending on where my cursor was, I was getting different results when viewing
the character style's text effects. So it is extremely important to look at the
actual style definitions themselves to get a good picture of what should be
happening here, and not base any conclusions on what the UI suggests.

There are many errors in OP's description.

The character style is actually "Style1" and it has no definition of any text
effect for transparency, no w14:alpha etc. The interesting bits are:
<w:style w:type="character" w:styleId="Style14" w:customStyle="1">
  <w:name w:val="Style1"/>
  <w:basedOn w:val="DefaultParagraphFont"/>
  <w:rPr>
    <w:rFonts w:ascii="Calibri" w:hAnsi="Calibri"/>
  </w:rPr>
</w:style>

There are two paragraph styles. Style2 which defines 49% transparency and a
black colour, and Style3 which inherits from Style2, but redefines a colour and
a transparency using w14:schemeClr instead of w14:srgbClr.
<w:style w:type="paragraph" w:styleId="Style21" w:customStyle="1">
  <w:name w:val="Style2"/>
  <w:basedOn w:val="Normal"/>
  <w:rPr>
    <w:color w:val="000000"/>
    <w14:textFill>
      <w14:solidFill>
        <w14:srgbClr w14:val="000000">
          <w14:alpha w14:val="49000"/>
        </w14:srgbClr>
      </w14:solidFill>
    </w14:textFill>
  </w:rPr>
</w:style>
<w:style w:type="paragraph" w:styleId="Style31" w:customStyle="1">
  <w:name w:val="Style3"/>
  <w:basedOn w:val="Style21"/>
  <w:rPr>
    <w:color w:val="203864" w:themeColor="accent1" w:themeShade="80"/>
    <w14:textFill>
      <w14:solidFill>
        <w14:schemeClr w14:val="accent1">
          <w14:lumMod w14:val="50000"/>
          <w14:alpha w14:val="49000"/>
        </w14:schemeClr>
      </w14:solidFill>
    </w14:textFill>
  </w:rPr>
</w:style>

Also important is to look at the direct formatting in the document. Obviously
the character Style1 is completely irrelevant since it doesn't define
transparency. So that transparency all comes from direct formatting.

The line "This text formatted from a character style with transparency." is
actually formatted with PARAGRAPH Style2 to get it's transparency.

The problem comes with line "This is a paragraph style with transparency.",
which is formatted with paragraph Style3's strange schemeClr. Writerfilter
basically doesn't handle schemeClr yet.

So let's redefine this report as an enhancement request to handling schemeClr
and its relatives
@Miklos: still interested?  (I'm not).


[At first I questioned why Style2's transparency setting wasn't passed down to
Style3? The answer must be because a Color() contains both the colour and the
alpha value, and since there was a colour change, the transparency is also
reset to zero. (LO UI agrees with this. If you change the colour, the
transparency value doesn't immediately change, but when you modify it again, it
has reset to zero.)]

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201110/11acd4dc/attachment.htm>