Description: Every time paste special is used in LO writer to paste something with formatted clipboard data (such as bold, underline, different colours, etc) the tab stops configuration is reset to its installation default of 1.27cm (or equivalent in inches). When this setting is reset any existing tabs entered in the document are changed in the viewport, wrecking the page layout. Setting the tab stops manually back to the custom value makes the document legible again but this setting should not be reset every time pasting simple formatting documents. This occurs from 6.4.1 upwards including up 7.1alpha (64-bit). Steps to Reproduce: 1. copy some text which has been formatted in some way to the clipboard, eg some text which has bold or underline or different size text in the same sentence. This is happening from all sources with some formatting, including PDF documents (using various non-browser based PDF viewers), web based browsers, and windows wordpad / write.exe 2. paste this text using the paste special function or by it's assigned keyboard shortcut. Select RTF format. Actual Results: - text is pasted as expected - except the tab stop variable is reset from whatever the user has customised it to to the installation default 1.27cm (or equivalent in inches). Tools→Options→LibreOffice Writer tab→General→Tab stops. - this behaviour changes the layout of previously applied tabs within the document, wrecking the text layout. - this prevents reliance on using tab to apply spacing. - having to keep changing the tab stops configuration variable in options back to my custom every time I paste special to maintain correct document layout. Expected Results: - pasting (special) should not alter Libreoffice configuration settings. Reproducible: Always User Profile Reset: Yes Additional Info: - have tried resetting user profile / trying fresh installation on another machine. - do not know if this affects other operating systems. - I have tried many builds from 6.4.1 up to alpha, which I am currently on. Version: 7.1.0.0.alpha0+ (x64) Build ID: 3ad21220992e348ccfc59ce5ffb67ee9dd0e4b88 CPU threads: 16; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-GB Calc: CL
See the ASK article for an alternative description for this. https://ask.libreoffice.org/en/question/250075/writer-paste-of-rtf-text-resets-tab-stop-size-to-install-default/
The 'key' component is buried in the details of the UI string: <[copy/paste]> Version: 7.1.0.0.alpha0+ (x64) Build ID: 3ad21220992e348ccfc59ce5ffb67ee9dd0e4b88 CPU threads: 16; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-GB Calc: CL <[copy/paste]/> The part that is relevant here are the two items : Locale , and UI. In this case the Computer is configured for en-US locale, but the User Interface (UI) is configured for en-GB. [As an aside, LO still does not know how to handle en-US/UI:en-UK with french as an option for Canadian users [fr-CA/fr-FR], but I leave that for someone else to ponder] Will be running with this 'bug' while I test the scenarios presented on an Win10-home machine with 2 threads in both en-US locale, and en-GB. In the mean time , you may wish to lookup "Gimli Glider", to see where US<>UK conversions and what happened in 1973 or so.
Saving as "unconfirmed" from "new", since there has been no confirmation of the error either here(bugzilla) or on Ask.libreoffice.org. I will setup test environment with en-US and en-GB in the latest release, and confirm/deny function (if observation dictates duplication of scenario). Also it is unknown, but there may be other quirks given the locale of the user,(according to AskLO this is N.Korea), but it should not make any difference for keyboard layout etc, vs RTF and ODT/Word compatibility. It also may be the reason no one has ever stumbled onto such a configuration before.
Repro using Version: 7.1.2.2 (x64) / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL The reset of the document default tab stop happens in DomainMapper_Impl::ApplySettingsTable [1], in this call stack: > writerfilterlo.dll!writerfilter::dmapper::DomainMapper_Impl::ApplySettingsTable() Line 7298 C++ > writerfilterlo.dll!writerfilter::dmapper::DomainMapper::lcl_table(unsigned long name, tools::SvRef<writerfilter::Reference<writerfilter::Table>> ref) Line 3707 C++ > writerfilterlo.dll!writerfilter::LoggedStream::table(unsigned long name, tools::SvRef<writerfilter::Reference<writerfilter::Table>> ref) Line 256 C++ > writerfilterlo.dll!writerfilter::rtftok::RTFDocumentImpl::outputSettingsTable() Line 379 C++ > writerfilterlo.dll!writerfilter::rtftok::RTFDocumentImpl::checkFirstRun() Line 389 C++ > writerfilterlo.dll!writerfilter::rtftok::RTFDocumentImpl::text(rtl::OUString & rString) Line 1491 C++ > writerfilterlo.dll!writerfilter::rtftok::RTFDocumentImpl::checkUnicode(bool bUnicode, bool bHex) Line 3633 C++ > writerfilterlo.dll!writerfilter::rtftok::RTFDocumentImpl::resolveChars(char ch) Line 1287 C++ > writerfilterlo.dll!writerfilter::rtftok::RTFTokenizer::resolveParse() Line 140 C++ > writerfilterlo.dll!writerfilter::rtftok::RTFDocumentImpl::resolve(writerfilter::Stream & rMapper) Line 806 C++ > writerfilterlo.dll!`anonymous namespace'::RtfFilter::filter(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & rDescriptor) Line 164 C++ > mswordlo.dll!`anonymous namespace'::SwRTFReader::Read(SwDoc & rDoc, const rtl::OUString & __formal, SwPaM & rPam, const rtl::OUString & __formal) Line 104 C++ > swlo.dll!SwReader::Read(const Reader & rOptions) Line 192 C++ > swlo.dll!SwTransferable::PasteFileContent(TransferableDataHelper & rData, SwWrtShell & rSh, SotClipboardFormatId nFormat, bool bMsg, bool bIgnoreComments) Line 2171 C++ > swlo.dll!SwTransferable::PasteData(TransferableDataHelper & rData, SwWrtShell & rSh, unsigned char nAction, SotExchangeActionFlags nActionFlags, SotClipboardFormatId nFormat, SotExchangeDest nDestination, bool bIsPasteFormat, bool bIsDefault, const Point * pPt, char nDropAction, bool bPasteSelection, RndStdIds nAnchorType, bool bIgnoreComments, SwPasteContext * pContext, PasteTableType ePasteTable) Line 1814 C++ > swlo.dll!SwTransferable::PasteFormat(SwWrtShell & rSh, TransferableDataHelper & rData, SotClipboardFormatId nFormat) Line 3375 C++ > swlo.dll!SwBaseShell::ExecClpbrd(SfxRequest & rReq) Line 334 C++ > swlo.dll!SfxStubSwBaseShellExecClpbrd(SfxShell * pShell, SfxRequest & rReq) Line 2201 C++ This needs a way to disambiguate creating a new document vs pasting into an existing document. [1] https://opengrok.libreoffice.org/xref/core/writerfilter/source/dmapper/DomainMapper_Impl.cxx?r=b802ab69#7293
FTR: this is unrelated to the locale and UI language. Also repro with Version: 7.1.2.2 (x64) / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 12; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL (expectedly, since the code mentioned in comment 4 is not locale-language-specific).
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d7c4d0d4ea83481693af3645a03b03b53e456f60 tdf#136740: Do not initialize document settings when pasting It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
By the way, this was a regression since v.4.0. And it was not platform-specific, also reproducible e.g. on Ubuntu.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a90a324aa590a94a4091fbfadea67e0b0203767c tdf#136740: add unit test It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7fc2cafbba36db25e7d0083cea162d2df08611b5 tdf#136740: reimplement the fix using existing m_bIsNewDoc It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/6d9d8c5a1abaf4ce2672406e2c04d68da5bb2cf7 tdf#136740: Do not initialize document settings when pasting It will be available in 7.1.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/ef7ecb85645c68aeec2585240fa72e322e424020 tdf#136740: reimplement the fix using existing m_bIsNewDoc It will be available in 7.1.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.