Download it now!
Bug 130973 - FILEOPEN DOCX Transparency setting from schemeClr is unhandled during import(comment 6)
Summary: FILEOPEN DOCX Transparency setting from schemeClr is unhandled during import(...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: DOCX-Styles DOCX-Character
  Show dependency treegraph
 
Reported: 2020-02-27 04:49 UTC by Drew Jensen
Modified: 2020-11-10 11:07 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
example file with styles created using WPS 2019 (9.88 KB, application/wps-office.docx)
2020-02-27 04:49 UTC, Drew Jensen
Details
Comparison MSO 2010 and LibreOffice 7.0 master (57.19 KB, image/png)
2020-03-17 10:29 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2020-02-27 04:49:06 UTC
Created attachment 158218 [details]
example file with styles created using WPS 2019

test system Ubuntu 18.04
Version: 7.0.0.0.alpha0+
Build ID: be81807aa201887935a19006c77005747f53bdb1

To reproduce:

Open attached docx file which includes text lines with character direct, character style (Style2) and paragraph style (Style3) utilizing font effect transparency setting.

The lines in the file explain which is using which type of formatting.

LibreOffice retains the information for paragraph styles, you can apply it to new lines of text export back out to docx with the setting in tact. 

Only the lines with Style3 (paragraph style) fail to properly display in LibreOffice.
Comment 1 Xisco Faulí 2020-03-17 10:29:44 UTC
Created attachment 158742 [details]
Comparison MSO 2010 and LibreOffice 7.0 master
Comment 2 Xisco Faulí 2020-03-17 10:31:07 UTC
Reproduced in

Version: 7.0.0.0.alpha0+
Build ID: 4ee7ee1c4a515479bc174543af4dbc400035c0ba
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threade
Comment 3 Xisco Faulí 2020-03-17 10:31:43 UTC
@Miklos, I thought you might be interested in this issue since it's related to text transparency
Comment 4 Justin L 2020-04-08 11:36:01 UTC
It seems like transparent character properties are a new feature in LO 7.

DOCX import support came in 7.0's https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-4&id=3a749d7278bbe65cfc063e64460df8af6bc2af47

In the character properties font-effects UI there is a setting for it, added in 7.0's https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-6-4&id=6d6e80435fd7f71342c429a67759a7b7b280cc55

However, in the character and paragraph STYLE properties, that setting is missing.
Comment 5 Miklos Vajna 2020-05-26 08:23:35 UTC Comment hidden (obsolete)
Comment 6 Justin L 2020-11-10 09:44:35 UTC
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.)]
Comment 7 Miklos Vajna 2020-11-10 11:07:08 UTC
> @Miklos: still interested?

I'm not short on problems right now.