Created attachment 46492 [details]
test document

started

hbrinkm->cmc:

I tried to fix this in Read_F_Macro by calling ReadTextAttr at the CP of the
macro buttons text - no success. Do you have an idea how to fix this without a
nasty global variable hack?

s/buttons/button's/

I don't have a solution right now, not even a working copy of msword :-), but
for some hacking possibilities, if you experimentally make
SwWW8ImplReader::Read_F_Macro return FLD_TEXT instead of FLD_OK does the macro
button text appear inline in the document with the correct font then ?, with the
field text visible as plaintext.

Changing the module

.

hb->cmc: The approach to return FLD_TEXT does not change the result. Further
investigation reveals that there is no field result and the font sprms span only
over the button text. So what needs to be done is to first analyze that all the
button text is attributed with exactly one set of sprms. Second you have to
apply the according SfxItemSet to the PAM of the inserted field. Is there a
function that reads the sprms like ReadTextAttr but returns an SfxItemSet
instead of applying the sprms in the SwDoc? If so, I could save the SfxItemSet
for the button text and apply it after the field was inserted to the SwDoc.

Maybe setting pAktItemSet to a temporary itemset at the right place, and
deleting it when done with it might help accumulate what you need. Search for
pAktItemSet, it is used for the "dropcap" hack which might be similar enough in
needs to be helpful.

hb->cmc: 

I tried something like this:

struct WW8PostProcessAttrsInfo
{
    WW8_CP mnCpStart;
    WW8_CP mnCpEnd;
    SwPaM mPaM;

    WW8PostProcessAttrsInfo(WW8_CP nCpStart, WW8_CP nCpEnd, SwPaM & rPaM);
};

void SwWW8ImplReader::PostProcessAttrs()
{
    if (mpPostProcessAttrsInfo != NULL)
    {
        WW8_CP nOldCp = pPlcxMan->Where();

        printf("PostProcessAttrs: %d\n", nOldCp);

        SfxItemSet * pTmpItemSet = pAktItemSet;
        pAktItemSet = new SfxItemSet( rDoc.GetAttrPool(), RES_CHRATR_BEGIN, 
                                      RES_PARATR_END - 1 );                

        printf("PostProcessAttrs before ReadAttrs: %d\n", pPlcxMan->Where());
        bool bStartLine = false;
        WW8_CP nCpStart = mpPostProcessAttrsInfo->mnCpStart;
        WW8_CP nCpEnd = mpPostProcessAttrsInfo->mnCpEnd;
        ReadAttrs(nCpStart, nCpEnd, bStartLine);

        printf("PostProcessAttrs after ReadAttrs: %d\n", nOldCp);
        printf("%d, %d, ", mpPostProcessAttrsInfo->mnCpStart, 
               mpPostProcessAttrsInfo->mnCpEnd);
        DBG_OUT(mpPostProcessAttrsInfo->mPaM);
        DBG_OUT(*pAktItemSet);

        rDoc.Insert(mpPostProcessAttrsInfo->mPaM, *pAktItemSet, 0);

        delete pAktItemSet;
        pAktItemSet = pTmpItemSet;

        delete mpPostProcessAttrsInfo;
        mpPostProcessAttrsInfo = NULL;
    }
}

mpPostProcessAttrsInfo is generated in Read_F_Macro and PostProcessAttrs is
called after ReadAttrs is finished. I double-checked with the dumping service of
the new writerfilter, that I get the right CPs in mpPostProcessAttrsInfo to
catch the font attributes over the macro button text. But, the temporary
pAktItemSet resulting from the ReadAttrs in PostProcessAttrs is empty. :-( I
have no clue why that is, do you? 

The theory looks good, I guess you'll have to debug a sample property like bold
or something simple and break on Read_BoldUsw when pAktItemSet is true to see if
it's getting parsed at all.

Things are sort of designed (I use that word loosely) for streaming through a
document in order of ascending logical character position, not generally for
jumping around the place in logical character position space, because it's
really hard to do "complex format" word document parsing. So the typical model
of use is to go through the document in order of the text and push data on event
start and pop it and use it on event end.

So it *might* be that you need to save the stage of "pPlcxMan" and seek it back
to the starting cp, do your work and restore it. So maybe something like this
might be needed...

WW8PLCFxSaveAll aSave;
pPlcxMan->SaveAllPLCFx( aSave );

pPlcxMan->SeekAll(nCpStart);

...

pPlcxMan->RestoreAllPLCFx( aSave );

or alternatively, a new pPlcxMan constructed to start at nCpStart. Hope that helps.

fixed:
/cvs/sw/sw/source/filter/ww8/ww8par.hxx,v  <--  ww8par.hxx
new revision: 1.149.92.2; previous revision: 1.149.92.1
done
Checking in ww8par.cxx;
/cvs/sw/sw/source/filter/ww8/ww8par.cxx,v  <--  ww8par.cxx
new revision: 1.177.82.1; previous revision: 1.177
done
Checking in ww8par5.cxx;
/cvs/sw/sw/source/filter/ww8/ww8par5.cxx,v  <--  ww8par5.cxx
new revision: 1.102.50.1; previous revision: 1.102
done
Checking in ww8par6.cxx;
/cvs/sw/sw/source/filter/ww8/ww8par6.cxx,v  <--  ww8par6.cxx
new revision: 1.174.86.2; previous revision: 1.174.86.1
done

ready for QA

Verified in CWS swqbf100.

Checked fix in SRC680m222.