Description: Existing borders are substituted for different ones because the imported style names are not properly stored in the reserved names. Thus duplicates are created, and existing styles are replaced with the new ones which likely have different border attributes. Steps to Reproduce: 1. In Calc, create a border pattern in B2:F3 2. Save (as ods is fine), close, and re-open 3. create a different border pattern (change color to make it obvious) in B5:C6 4. Save, close, and reopen. Notice that the border in B2:F3 has been affected. Actual Results: The border pattern is different since some cells now have colored borders in different places. Expected Results: The untouched border in B2:F3 should be unaffected by borders added elsewhere in the document. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
Created attachment 128745 [details] borderStyle.ods. Add another border and reload to replicate the issue
Created attachment 128747 [details] borderStyle.pdf: B2:F3 should be all black, with top-middle borders only. Regression in 5.3 development branch. Used linux daily 5.3 dbgutil bibisect to isolate to the changes made on Sept 24, the most likely problem commit being author Markus Mohrhard <markus.mohrhard@googlemail.com> 2016-09-26 19:37:12 commit 89804c14ee99721d252e30468342384fbc8926b2 implement prototype for more stable calc cell style names
Confirmed in Version: 5.3.0.0.alpha1+ Build ID: 8dc495c93239739629683bb29e4110f5c57c94f0 CPU Threads: 4; OS Version: Linux 4.8; UI Render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); Calc: group and confirmed that this regression was caused by 89804c14ee99721d252e30468342384fbc8926b2 author Markus Mohrhard <markus.mohrhard@googlemail.com> 2016-09-24 18:41:52 (GMT) committer Markus Mohrhard <markus.mohrhard@googlemail.com> 2016-09-26 19:37:12 (GMT) commit 89804c14ee99721d252e30468342384fbc8926b2 (patch) tree a543fb27fe9333b4a204aabba4ef984a2cb09f57 parent f626fd5f897796451685c06ce5f397a90aeaa8e6 (diff) implement prototype for more stable calc cell style names This should ensure that as long as the style does not change the cell style name is the same after an import export cycle. Each ScPatternAttr stores a unique ID and we store the ID to name mapping during import. During export if we find a ScPatternAttr that has a key that is also stored in the map we write back the style name from the map. To avoid name collisions we block the style names from the import for the export. The missing piece to make this completely awesome is now to make sure that styles are sorted by name during export. That way we can reduce the diff between import and export even more. Adding Cc: to Markus Mohrhard
Created attachment 128780 [details] reservedNames.diff: debug output and code pointing to key concern areas. The problem is that the reserved names end their life before they are used as seen by this line from the AutoStyleFamily destructor: warn:DEBUG:11022:1:xmloff/source/style/impastpl.cxx:59: ?????? ~XMLAutoStyleFamily[table-cell] DTOR reserved.size[8] ??????? Markus: best if you take over from here.
This is a fairly nasty bug to be allowed to hit shipping code.
fixed: target:5.4.0 target:5.3.0.1 *** This bug has been marked as a duplicate of bug 104097 ***