Bug 54315 - exporting to html with StarWriter filter changes text properties
Summary: exporting to html with StarWriter filter changes text properties
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: HTML-Export
  Show dependency treegraph
Reported: 2012-08-31 09:23 UTC by cristi falcas
Modified: 2019-12-03 14:06 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

odt to html result (71.09 KB, application/x-zip)
2012-08-31 09:23 UTC, cristi falcas
Conversion to HTML and XHTML using v3304 thru v4132. (314.46 KB, application/zip)
2013-12-06 11:22 UTC, Owen Genat (retired)

Note You need to log in before you can comment on or make changes to this bug.
Description cristi falcas 2012-08-31 09:23:43 UTC
Created attachment 66395 [details]
odt to html result

Attached files where generated with this command:

/opt/libreoffice3.6/program/soffice --display :1020 --convert-to "html:HTML (StarWriter)"  --outdir ./ Untitled\ 2.odt

The resulting html file has the following css properties:

P { margin-bottom: 0in; direction: ltr; color: #ff9900; line-height: 119%; text-align: center; widows: 2; orphans: 2 } 

All text will be orange (color: #ff9900) and centered (text-align: center).

Output is correct if using --convert-to html, but in this case all images are embedded (bug 48887), which brings other problems.
Comment 1 Owen Genat (retired) 2013-12-06 11:07:23 UTC
Due to these findings I am confirming this bug, even if only to get a developer to examine the styles in order to determine what should be getting set in the CSS of the HTML for the two filters in question. Status set to NEW. Version set to Inherited From OOo as v3304 through v4132 all exhibit the same problem with the centred+orange list item text for the provided example. Platform set to All/All. Test results to be attached in a following comment.

It is worth noting that the provided ODT in comment #0 has apparently been converted from a Word document and so may not be the best test (or it may be a very good one, depending on viewpoint). The embedded graphic is a Microsoft Visio diagram. The ODT (content.xml) contains:

> <style:style style:name="P1" style:family="paragraph" style:parent-style-name="Standard" style:list-style-name="WW8Num26"/>
> ...
> <text:list xml:id="list36587887" text:style-name="WW8Num26">
>    <text:list-item>
>       <text:p text:style-name="P1">Mobile A starts a new GPRS session</text:p>
>    </text:list-item>
> ...

... and (styles.xml):

> <style:style style:name="Text_20_body" style:display-name="Text body" style:family="paragraph" style:parent-style-name="Standard" style:class="text">
>    <style:paragraph-properties fo:margin="100%" fo:margin-left="0cm" fo:margin-right="0cm" fo:line-height="119%" fo:text-align="center" style:justify-single-word="false" fo:text-indent="0cm" style:auto-text-indent="false" style:text-autospace="none"/>
>    <style:text-properties fo:color="#ff9900" style:font-name="Courier New" fo:font-weight="bold" style:font-weight-asian="bold" style:font-name-complex="Courier New" style:font-weight-complex="bold"/>
> </style:style>
> <text:list-style style:name="WW8Num26">
>    <text:list-level-style-number text:level="1" style:num-suffix="." style:num-format="1">
>       <style:list-level-properties text:list-level-position-and-space-mode="label-alignment">
>          <style:list-level-label-alignment text:label-followed-by="listtab" fo:text-indent="-0.635cm" fo:margin-left="1.27cm"/>
>       </style:list-level-properties>
>    </text:list-level-style-number>
>    <text:list-level-style-number text:level="2" style:num-suffix="." style:num-format="a" style:num-letter-sync="true">
>       <style:list-level-properties text:list-level-position-and-space-mode="label-alignment">
>          <style:list-level-label-alignment text:label-followed-by="listtab" fo:text-indent="-0.635cm" fo:margin-left="2.54cm"/>
>       </style:list-level-properties></text:list-level-style-number>
> ...

Note that the "Text body" style is set to use the #ff9900 colour. This could be the reason for the orange list item text, which I can confirmed as being converted in this manner under Ubuntu 10.04 x86_64 running:

- v3.3.0.4 OOO330m19 Build: 6
- v3.4.6.2 OOO340m1 Build: 602
- v3.5.7.2 Build ID: 3215f89-f603614-ab984f2-7348103-1225a5b
- v3.6.7.2 Build ID: e183d5b
- v4.0.6.2 Build ID: 2e2573268451a50806fcd60ae2d9fe01dd0ce24
- v4.1.3.2 Build ID: 70feb7d99726f064edab4605a8ab840c50ec57a

Examples of commands used for testing conversion (original ODT renamed to a.odt for convenience):

$ soffice --headless --convert-to html:"HTML (StarWriter)" --outdir HTML_StarWriter/v4132/ a.odt

... and:

$ soffice --headless --convert-to html:"XHTML Writer File" --outdir XHTML/v4132/ a.odt
Comment 2 Owen Genat (retired) 2013-12-06 11:22:44 UTC
Created attachment 90350 [details]
Conversion to HTML and XHTML using v3304 thru v4132.

Test results of output to HTML (linked graphics) and XHTML (embedded graphics) are included for the versions of LO listed in comment #1. Screenshots are included for v3304 and v4132 to indicate what I am seeing.
Comment 3 QA Administrators 2015-04-19 03:21:40 UTC Comment hidden (obsolete)
Comment 4 Buovjaga 2015-06-16 17:20:35 UTC
Still same result.

Ubuntu 15.04 64-bit 
Build ID: 9ef671364ff9fbb552a5433053af9283d12d90c7
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-06-16_08:38:45
Locale: en-US (en_US.UTF-8)
Comment 5 QA Administrators 2016-09-20 10:02:19 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2019-12-03 14:06:03 UTC
Dear cristi falcas,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team