Bugdoc to evaluate is missing.

Created attachment 12657 [details]
This is a document that is causing some of the problems.

Created attachment 12658 [details]
This is a document that is causing some of the problems.

I attached the bug document as requested.

Reassigned to MRU

Hm, cannot see that in the attached file. Perhaps it happens only in your
original file where you have all the 255 numberings...?

Created attachment 12662 [details]
Here is the Doc, must open in Open Office, it looks fine in MS Word.

I have attached a new copy of the problem.doc  You will notice when you open it
in OO Write that the number 5 is not the same font type as the others. 
Originally 3,5,and 7 all had problems, but each time I copy them into a new
document and save the fonts change.

MRU->CMC: The last attachment has a small glitch. Number 5 (only the number, not
the rest of the para) is formatted TNR instead of Arial. 

cmc->fme: Bear with me on this one, its not possible to provide a native format
document which can do this, but it is possible from the UI. So, in a version
SRC680m21 at least and probably for a long time before...

Document 1, the expected result
1) New text document
2) type AB
3) select all characters together and format->character->font->e.g. Academy
Engraved LET
4) select all characters together and format->character->font->e.g. Arial
5) format bullets->numbering->numbering type, anything, ok

the result is that (as expected) all characters including numbering characters
share the Arial font formatting.

6) save as .sxw/reload, no change

Document 2, the surprising results
1) New text document
2) type AB
3) select all characters together and format->character->font->e.g. Academy
Engaved LET
4) select 'A' seperately and format->character->font->Arial
5) select 'B' seperately and format->character->font->Arial
6) format bullets->numbering->numbering type, anything, ok

result, AB remain formatted in Arial, numbering takes original "Academy Engraved
LET" font formatting :-(

7) save as .sxw/reload, now formatted like original correct document

Perhaps the numbering takes the font from the nodes pSwpHints ?, so that when
the characters are formatted seperately this is unchanged and the formatting
takes the original shared character formatting, and on a save and reload cycle
the xml export/import strips out the redundancy of shared hints which are unused ?

cmc->ama: Perhaps this is behind at least some of the strange formatting for
numbering we have seen, if so then a save as .sxw and reload cycle should
workaround the problem.

cmc->nafai: Until we have this fixed you could try saving your documents as .sxw
format and reload and see if the formatting of the number gets "fixed"

FME->CMC: [...] Perhaps the numbering takes the font from the nodes pSwpHints ?,
so that when the characters are formatted seperately this is unchanged and the
formatting
takes the original shared character formatting, and on a save and reload cycle
the xml export/import strips out the redundancy of shared hints which are unused
? [...]

Yes, this is correct. But I don't have a clue what to do with this issue.

Thanks for working on this.  Unfortunately, I can't use the quick fix because my
co-workers all use MS-Office so I have to keep it in .doc format.  Thanks though.

FME->DVO: In InsAttr() in docfmt.cxx, there is some code like 

		if( pStt->nContent.GetIndex() != 0 || aCntEnd.GetIndex() != nLen )

which causes the attribute to be handled like a paragraph attribute. Could you
please have a look?

dvo: I think FME is correct; what happens is this: If a character attribute that
spans the entire paragraph is inserted, it is automatically turned into a
paragraph attribute. This _only_ happens when the attribute is inserted, _not_
when a suitable character attribute is created through a number of editing
steps. One could count this as an optimization since a paragraph attribute and a
character attribute over the whole paragraph are pretty much the same, except
that the former affects the numbering bullet, while the latter doesn't.

An additional problem is that programmatically there is no way to enforce or
suppress this behaviour, since it is done automatically at InsAttr(..), and
pretty much nowhere else. Thus the import filters have no way of importing this
correctly, even if they can tell the difference between the two. Hence, save +
load (.sxw) may change numbering bullets, since save correctly wrote out para +
char attributes, but during load some char attribute turned into para
attributes. Similar for WW8 import, I suppose.

I can see three ways of solving this:

1) We declare the conversion of char attribute over the complete paragraph to an
paragraph attribute as correct and desirable. Then all code must be changed to
obey this and the problem with load+save would go away. If this differs from
what other programs do, then those documents couldn't be fully represented.

2) We declare said conversion to be a superflous optimization and undesirable,
and remove the conversion from InsAttr(..). Filters would have to be changed to
do the conversion themselves, if their source formats would require it.

3) We declare current behavior to be correct at the UI level, but change the
code so it will not get done automatically (for filters, andAPI?). Filters would
then have to be changed to do the conversion themselves.

dvo->ama: I can't determine what is correct in this case. What needs to be done
(and by whom) depends on this decision.
Please also observe that this might be a problem in our already rather tight
schedule, and adjust target/priority if necessary.

Target OO later now.