Apache OpenOffice (AOO) Bugzilla – Issue 21960
WW8: Allow sublevels to override numbering type of inherited levels
Last modified: 2017-05-20 11:19:42 UTC
Should be '2.1.1' -> OO shows '2.a.1' and instead of '2.1.2' -> '2.a.2'.
Created attachment 10840 [details] MS Word file which demonstrates defect on import to OO1.1
reassigned to mru
I can Reproduce the problem on OpenOffice 1.1 (default Install, US), Win XP Pro Sp1. (And MS Office XP Sp2). It is real problem I will attach the screenshot on word xp Change Os to all, I can confirm on win xp
Created attachment 10862 [details] screenshot at word XP numbering is wrong on OOo 1.1
MRU->CMC: As far as I can see there are three diffenrent numberings in this doc. The second one has a different numbering type for its second level than it has in Word. When I have a look with Word to the properties of this numbering, it looks VERY odd (the preview shows something like 1.0.8388608); maybe there are stored some invalid values inside the .doc.
Wrong assignment... should have gone to cmc@openoffice
cmc->priitr@openoffice.org: This is another very very odd document, the other document submitted by you was very strange as well. Can you tell me more about the version of word you are using to create these ? Is there anything unusual about it at all ?, an alpha/beta or a third party application ?
Seems it's a Word97 document loaded and re-saved by Word XP Estonian Edition.
Created attachment 11611 [details] An example
sigh: As in the last attached example. The four paragraphs all have a single numbering rule applied. Level 1 starts at 2 and is arabic, level 2 does not include level1 and is roman. Level 3 includes level 1 and 2 and is arabic, *but* includes level 2 as an arabic number. i.e. level 3 overrides the formatting of the number inherited from level 2. cmc->ama: Again this is something that we just cannot do as far as I know :-(
No, OOo isn't able to do this numbering. But to be honest I don't see the need for this strange numbering?! We won't fix this for OOo2.0.
Well, creator of this document most certainly didn't do anything exotic to create this kind of numbering, after all, Word shows 'correct' (expected) numbering and the issue was created strictly because OOo didn't. Still I agree, different Word versions do strange things to the documents not created by themselves and seems like localized MSO versions are especially 'good' doing this.
Caolan, I agree, we're not able to import a numbering like 1. 1.1 1.b 1.c 1.4 and I don't see any need for this. But the original bug document has a numbering like 2.1 2.1.1 2.1.2 which we import as 2.1 2.a.1 2.b.2. Okay, it looks like 2.a.1 and 2.1 are different numberings. The question is: why does 2.a.1 etc. has a "a,b,c" numbering at level 2?
As noted 2.1 and 2.1.1 are different lists, so the 2.1 line is a red herring. What is missing in the original bugdoc is a standalone usage of level 2 of the 2.1.1 numbering, if there was such a usage it would display 'a' not '2.1', which is what my own attachment demonstrates. The reason we show level 3 as 2.1.1 is because this list has defined using a character for Level 2. If you open the bugdoc in word 97 and place the cursor in "Kaardi taotlemiseks" in the 2.1.1 entry and look at format->bullets and numbering->customize, then Level 1 is a number to start at 2, Level 2 is only a letter to start at 'a' and no inherited number from Level 1, and Level 3 is a number.number.number where the first number inherits from Level 1 as expected, and the third number is at Level 3, and our problem is that the second value to be displayed as a number is to be inherited from Level 2 but its type conflicts with the use of a character in Level 2 for this slot. During importing we build up the list by starting at level 1 and for level 2 adding what is different, and then for Level 3 adding what is different from Level 2. So because level 2 says to use a character, when we get to level 3 we have already decided to use a character for the level 2 value. This discontinuity is probably why later versions of word have some confusion about what to show in the preview window for this list as mru describes. If we have no plans to handle such sublevel overriding of higher level number formatting in our own numbering, we could implement a workaround "voting" system in the filter, so that a given level becomes arabic/roman/etc if the majority of the levels that reference that level's position agree on its display type. Currently we assign its type depending on the format that this level itself assigns, but we could do it the proposed way to workaround this bugdoc. If you agree that this is a suitable filter based solution, then reassign again and we'll give that a try.
Yes, I agree with your proposed solution. I don't think that anybody needs different number formats in a single numbering (2.1, 2.b, 2.3 etc.), so we will not implement this "feature". But if somebody has created this by accident and reformats his numbering until it looks okay like in the bugdoc then your voting idea will work well.
cmc->mmaher: Oky doky then, what we want to do is fairly clear. We'll have to fiddle a little to get this to work though. List import of this is in ww8par3.cxx in WW8ListManager::ReadLVL
mmaher: strange numbering
mmaher->ama: This bug arose because we do not support legal numbering. In outline numbering you can turn on legal numbering for a particular level so that all characters get changed to numbers. I attached a word document to show this. The original document had strange numbering so what was outline numbering actually appeared as plain numbering and the legal numbering option did not show up. We cannot support legal numbering in the filter as we can only control the numbering characteristics of the current level (and not from inherited levels).
Created attachment 12525 [details] Doucmnet demonstrating legal numbering
mmaher: BTW when you customize an outline numbering format you have to press the More button to see the "legal numbering" checkbox.
OpenOffice.org Issue Tracker - Feedback Request. The Issue you raised has the status 'New' pending further action, but has not been updated within the last 4 years. Please consider re-testing with one of the latest versions of OOo, as the problem(s) may have already been addressed. Either use the recent stable version: http://download.openoffice.org/index.html or consider trying the new OOo 3 BETA (still in testing): http://download.openoffice.org/3.0beta/ Please report back the outcome so this Issue may be Closed or Progressed as necessary - otherwise it may be Resolved as Invalid in the future. You may also wish to search for (and note) any duplicates of this Issue that may have advanced further by checking the Issue Tracker: http://www.openoffice.org/issues/query.cgi Many thanks, Andrew Cleaning-up and Closing old Issues as part of: ~ The Grand Bug Squash, pre v3 ~ http://marketing.openoffice.org/3.0/announcementbeta.html
This is now OD's playground.
Reset assigne to the default "issues@openoffice.apache.org".