Bug 89069 - FILESAVE: HTML output removes bold/italic from open-quote characters
Summary: FILESAVE: HTML output removes bold/italic from open-quote characters
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: (X)HTML-Export
  Show dependency tree / graph
 
Reported: 2015-02-03 01:48 UTC by Rev. Bob
Modified: 2023-05-19 03:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Attachments
sample document (9.70 KB, application/vnd.oasis.opendocument.text)
2015-02-04 22:30 UTC, Yousuf Philips (jay) (retired) 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Rev. Bob 2015-02-03 01:48:43 UTC 
(First: I'm new to this community and to Bugzilla. I apologize if lumping the two issues described below into one entry is incorrect. If it is and they need to be split, please feel free to do so; if one needs to be ignored, ignore the latter issue.)

I have two issues with Writer and HTML. I know these go back to at least 4.2.1.1, but I can't speak to earlier versions. I use LibreOffice Writer to create/edit documents as ODT files, then "Save a Copy" with "HTML Document (Writer)" to export an HTML copy, which is intended for use in an XHTML environment. (The "Export as XHTML" code is far messier and harder to clean up, but I should note that it does NOT exhibit these specific bugs. Hence, these are most likely save-as-HTML filter issues rather than Writer bugs.) Furthermore, I am using smart quotes and UTF-8 encoding.

1. When a paragraph begins with an open-single-quote or open-double-quote character, and that character has certain direct formatting applied to it, the character does not retain said formatting in the HTML file. For instance, consider this line of dialogue:

“That seems strange.”

If the first five characters are italicized, the expected output would be:

<p class="western"><i>“That</i> seems strange.”</p>

...but the generated output is:

<p class="western">“<i>That</i> seems strange.”</p>

...with the open-double-quote rendered as plain text, not italicized. Single-quote dialogue shows the same behavior, but this bug does NOT happen with formatted closing quotes at the end of a paragraph, or with any sort of quotes in mid-paragraph. Thus, italicizing the first two words of this line would save correctly:

Oops. “That seems strange.”
<p class="western"><i>Oops. “That</i> seems strange.”</p>

In my testing, only the bold and italic formats are affected by this bug. Applying bold, italic, underline, superscript, and strike to the selection (in that order) results in the following:

<p class="western"><strike><sup><u>“<i><b>That</b></u></i></sup></strike>
seems strange.”</p>

2. Although it's more of a stylistic preference than a true bug, the saved HTML contains hard line breaks (based on about a 70-72 character line, not counting HTML tags) instead of reserving those for breaks between block-level elements. An enhancement to the HTML save filter to allow user configuration of that behavior (no breaks, hard line breaks, breaks between block-level) would be rather helpful. Save a Copy > HTML breaks at every line, Export... > XHTML has no breaks, and I'm advocating something in between.
Comment 1 Urmas 2015-02-03 09:10:08 UTC 
Confirmed in master.
The language attribute also seem not to affect the quote character at the beginning of a paragraph.
Comment 2 Yousuf Philips (jay) (retired) 2015-02-04 22:29:52 UTC 
Hello Rev. Bob,

Thank you for submitting the bug. I can confirm that the bug is available in 3.3, 3.6, 4.0, 4.2, 4.3 daily and master as well as AOO 4.1.1 on Linux.

About the hard line breaks, you should submit that as an enhancement bug.

Version: 4.5.0.0.alpha0+
Build ID: d1c9bd13ec7af93f5368dfda6d6d3c955f0b0816
TinderBox: Linux-rpm_deb-x86@45-TDF, Branch:master, Time: 2015-01-28_00:25:56
Comment 3 Yousuf Philips (jay) (retired) 2015-02-04 22:30:21 UTC 
Created attachment 113133 [details]
sample document
Comment 4 Rev. Bob 2015-02-05 19:15:15 UTC 
(In reply to Jay Philips from comment #2)
> 
> About the hard line breaks, you should submit that as an enhancement bug.

Thanks for the information; I have done so as bug 89143, with a notation linking back here.
Comment 5 QA Administrators 2016-02-21 08:37:34 UTC Comment hidden (obsolete)
Comment 6 Rev. Bob 2016-02-23 02:04:37 UTC 
This behavior is unchanged in LibreOffice 5.x; the bug remains. Tested on LibreOffice Portable 5.1.0.3 under Windows 8.1 (64-bit).
Comment 7 QA Administrators 2017-03-06 15:54:12 UTC Comment hidden (obsolete)
Comment 8 Rev. Bob 2017-03-07 12:14:03 UTC 
This behavior is unchanged in LibreOffice 5.x; the bug remains. Tested on LibreOffice Portable 5.3.0.3 under Windows 10 (32-bit).
Comment 9 QA Administrators 2018-08-22 02:35:54 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2020-08-22 03:50:11 UTC Comment hidden (obsolete)
Comment 11 Rev. Bob 2020-10-04 19:16:42 UTC 
Bug still exists in LibreOffice Portable 7.0.1.2 under Windows 10 (32-bit).
Comment 12 Stéphane Guillou (stragu) 2021-05-18 13:03:15 UTC 
Reproducible in LO 7.2 Alpha0+

Weird bug!

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 6b09276d157abada74e1a4989700139167207778
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-05-14_04:32:30
Calc: threaded
Comment 13 QA Administrators 2023-05-19 03:17:21 UTC 
Dear Rev. Bob,

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 https://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://web.libera.chat/?settings=#libreoffice-qa

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

Warm Regards,
QA Team

MassPing-UntouchedBug