Problem description: Steps to reproduce: [1] Open new text document and write some text. [2] Insert a comment and write some text into comment. [3] Select the comment text and copy it to clipboard (Ctrl+C). [4] Insert a second comment and insert text from clipboard into this comment (Ctrl+V). The text is inserted plus an “A” in front of the inserted Text. Expected: No additional “A”. Comments according this bug: (1) In version 4.0.5 release the bug does not exist. Hence regression. (2) As far as I tested this problem, it only appears if the second comment is empty or if the existing text of the second comment is replaced. (3) It is not possible to delete the “A”. A backspace toggles the display of the “A”. (4) In order to get rid of the “A” either you have to undo the last inputs or you have to delete the comment. (5) If you insert some tabs directly behind the “A” the comment gets mixed up completely. Operating System: Windows 7 Version: 4.1.0.4 release
regression CONFIRMED. reproduced on 4.1.0.4 under Win7 64bit. works fine on 4.0.4.2
regression from: commit a95cce27295f9cd255fa72eaded00972e3efb69b Author: Cao Cuong Ngo <cao.cuong.ngo@gmail.com> AuthorDate: Fri Apr 12 18:42:46 2013 +0200 fix fdo#47018 Impress paste destroy bullet Currently the copy function stores the paragraph attributes to SvStream but the restoration in paste isn't implemented yet! This patch implements the attributes loading from SvStream.
problem is in SvxNumBulletItem::Create, where the newly returned SvxNumBulletItem somehow causes the text to be numbered with an "A"... and when the document is saved it looks like: <office:annotation> <dc:creator></dc:creator> <dc:date>2013-08-28T17:53:08.911535723</dc:date> <text:list text:style-name=""> <text:list-item> <text:p text:style-name="P2"> <text:span text:style-name="T2">adfdfadfadffda</text:span> </text:p> </text:list-item> </text:list> </office:annotation> (note empty list style name) ... it looks like the constructor SvxNumRule::SvxNumRule may initialize aFmts[i] with a format but always sets aFmtsSet[i] to false, and the serialization ignores aFmtsSet[i] and deserialization sets aFmtsSet[i] iff aFmts[i] != 0 so that's how a copy/paste cycle turns on numbering. fixed on master.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4b798d89a55714218dc9a7de161f93f9c4d6fc80 fdo#68648: SvxNumRule: serialize the aFmtsSet flags too The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=09a894477f326af5683a8f5e51038e0c88453806&h=libreoffice-4-1 fdo#68648: SvxNumRule: serialize the aFmtsSet flags too It will be available in LibreOffice 4.1.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Checked with version 5.4.3. Works as expected. Bug closed.