Issue 21960 - WW8: Allow sublevels to override numbering type of inherited levels
Summary: WW8: Allow sublevels to override numbering type of inherited levels
Status: CONFIRMED
Alias: None
Product: Writer
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: PC All
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords: oooqa
Depends on:
Blocks:
 
Reported: 2003-10-31 14:19 UTC by priitr
Modified: 2017-05-20 11:19 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
MS Word file which demonstrates defect on import to OO1.1 (94.00 KB, application/octet-stream)
2003-10-31 14:22 UTC, priitr
no flags Details
screenshot at word XP numbering is wrong on OOo 1.1 (11.19 KB, image/gif)
2003-11-01 03:20 UTC, utomo99
no flags Details
An example (82.00 KB, application/octet-stream)
2003-11-28 10:00 UTC, caolanm
no flags Details
Doucmnet demonstrating legal numbering (19.50 KB, application/msword)
2004-01-16 16:21 UTC, martin_maher
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description priitr 2003-10-31 14:19:55 UTC
Should be '2.1.1' -> OO shows '2.a.1' and instead of '2.1.2' -> '2.a.2'.
Comment 1 priitr 2003-10-31 14:22:44 UTC
Created attachment 10840 [details]
MS Word file which demonstrates defect on import to OO1.1
Comment 2 mci 2003-10-31 16:05:38 UTC
reassigned to mru
Comment 3 utomo99 2003-11-01 03:18:56 UTC
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 
Comment 4 utomo99 2003-11-01 03:20:04 UTC
Created attachment 10862 [details]
screenshot at word XP numbering is wrong on OOo 1.1
Comment 5 michael.ruess 2003-11-03 11:43:31 UTC
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.
Comment 6 michael.ruess 2003-11-03 11:44:24 UTC
Wrong assignment... should have gone to cmc@openoffice
Comment 7 caolanm 2003-11-03 15:27:03 UTC
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 ?
Comment 8 priitr 2003-11-04 10:07:41 UTC
Seems it's a Word97 document loaded and re-saved by Word XP Estonian
Edition.
Comment 9 caolanm 2003-11-28 10:00:36 UTC
Created attachment 11611 [details]
An example
Comment 10 caolanm 2003-11-28 10:45:32 UTC
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 :-(
Comment 11 andreas.martens 2003-12-15 08:50:13 UTC
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.
Comment 12 priitr 2003-12-15 09:55:50 UTC
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.
Comment 13 andreas.martens 2003-12-15 11:37:28 UTC
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?
Comment 14 caolanm 2003-12-15 12:24:47 UTC
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.
Comment 15 andreas.martens 2003-12-15 12:39:49 UTC
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.
Comment 16 caolanm 2003-12-15 12:43:44 UTC
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
Comment 17 martin_maher 2004-01-16 10:48:19 UTC
mmaher: strange numbering
Comment 18 martin_maher 2004-01-16 16:20:22 UTC
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).
Comment 19 martin_maher 2004-01-16 16:21:57 UTC
Created attachment 12525 [details]
Doucmnet demonstrating legal numbering
Comment 20 martin_maher 2004-01-16 16:28:24 UTC
mmaher: BTW when you customize an outline numbering format you have to press the
More button to see the "legal numbering" checkbox.
Comment 21 ace_dent 2008-05-16 02:57:33 UTC
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
Comment 22 michael.ruess 2009-09-28 10:15:55 UTC
This is now OD's playground.
Comment 23 Marcus 2017-05-20 11:19:42 UTC
Reset assigne to the default "issues@openoffice.apache.org".