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.
Created attachment 158742 [details] Comparison MSO 2010 and LibreOffice 7.0 master
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
@Miklos, I thought you might be interested in this issue since it's related to text transparency
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.
Is this a duplicate of bug 130456?
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.)]
> @Miklos: still interested? I'm not short on problems right now.
This appears to be fixed in LO 7.6 thanks to commit 585f65738270ba8ab2fdc4c49063c3b5663fe768 Author: Regina Henschel on Thu Jan 5 18:33:46 2023 +0100 tdf#152884 import alpha too for schemeClr *** This bug has been marked as a duplicate of bug 152884 ***