So? Isn't that what the <META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=windows-1252"> tag in the saved file says then? Do we document that it would save in UTF-8? I fail to see how this is a bug. Sure, it would be more "cool" and modern to save as UTF-8, but unless I miss something this is just a low priority enhancement request.
To avoid confusion, let me add that the initial title of this bug report was "HTML files are saved in local encoding (e.g. cp1251) instead of utf8"
Created attachment 47177 [details] screenshot of Options - Load-Save - HTML Compatibility You can choose any encoding in Options - Load-Save - HTML Compatibility settings.
OK, so clearly NOTABUG then.
(In reply to comment #3) > Created an attachment (id=47177) [details] > screenshot of Options - Load-Save - HTML Compatibility > > You can choose any encoding in Options - Load-Save - HTML Compatibility > settings. Then why not enable UTF8 in that HTML Compatibility menu by default? Can it be a small enhancement request? Thanks.
OK, sure.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
This bug persist in LO 3.5.0 RC1 on Windows XP SP3
I've just did fresh install LO 4.0.4.2 with new user profile on PCLinuxos KDE. Unicode (UTF-8) has been applied as default character set (same as screenshot).
This bug happens only on Windows platform. Proof of the bug happening see in attachment.
Created attachment 86016 [details] an HTML file saved after fresh install of v4.1.1.2 on Win7 proof of the bug
Should stop calling it a bug - it works as expected. It's an enhancement request which might never be implemented if no developer wants to volunteer to tackle it. Moving to NEW as REOPENED is incorrect.
This can be solved in various ways, and atm I am not sure which is the best approach: - The easiest way to solve this is to just change the encoding to UTF8 for all plattforms in https://opengrok.libreoffice.org/xref/core/cui/source/options/opthtml.cxx?r=da9bba7c#62 (m_xCharSetLB->SelectTextEncoding(RTL_TEXTENCODING_UTF8);) - The best way however should to check, if the function SvxTextEncodingBox::FillWithMimeAndSelectBest and SvtSysLocale::GetBestMimeEncoding can be changed to always show the utf8 charset. However, these functions retrieve the charset from the Windows code page, and it contains the windows-1252 charset on Windows. You may change the charset on Windows to UTF8 as well. - Maybe also the SvxTextEncodingBox::FillWithMimeAndSelectBest can be adjusted in order to get always the UTF8 charset on every platform. Opinions?
*** This bug has been marked as a duplicate of bug 148413 ***