ppt import(?) bug hunting

["Dr. David Alan Gilbert" <dave@xxxxxxxxxxx>]

Hi,
  I've been poking about trying to understand a pet bug:
https://bugs.documentfoundation.org/show_bug.cgi?id=49856

which is related to bullets in documents that go through
a ppt export->import cycle; I've not yet quite convinced
myself of whether it's an export or import bug, but I'm
down to a couple of lines of code that look suspicious
but I could do with a hand understanding why they exist.

In the test case, you end up where shift-tab'ing the victim
line ends up indenting and switching to a >> bullet rather
than doing a simple unindent and getting a round-blob bullet.
I've followed the import code, found a situation where the
number formats had that >> bullet in the first slot and followed
it back, and got as far as svdfppt.cxx, PPTStyleSheet::PPTStyleSheet
which, near the bottom has:

        for ( sal_uInt16 nCount = 0; nDepth < nLevels; nCount++ )
        {
            const PPTParaLevel& rParaLevel = mpParaSheet[ i ]->maParaLevel[ nCount ];
            const PPTCharLevel& rCharLevel = mpCharSheet[ i ]->maCharLevel[ nCount ];
            SvxNumberFormat aNumberFormat( SVX_NUM_CHAR_SPECIAL );
            aNumberFormat.SetBulletChar( ' ' );
            GetNumberFormat( rManager, aNumberFormat, nCount, rParaLevel, rCharLevel, i );
            aRule.SetLevel( nDepth++, aNumberFormat );
            if ( nCount >= 4 )
            {
                for ( ;nDepth < nLevels; nDepth++ )
                    aRule.SetLevel( nDepth, aNumberFormat );
   >>>>         if ( eNumRuleType == SvxNumRuleType::PRESENTATION_NUMBERING )
   >>>>             aRule.SetLevel( 0, aNumberFormat );
            }
        }

It seems to be that rule that's overwriting the 0th level with
the 4th (?) level - but I don't understand what that line
is intended to do or why it's needed.

That code predates the move of the msfilters into that directory -
is there a tree with history older than that still around so I can
find the bug/history/reasoning of where that pair of lines came from?

If I remove those 2 lines then my bug disappears - but I'm loathed
to submit a patch to do that without understanding why they are there
in the first place.

(The variable usage in general in that loop is a little odd to me;
there's nCount and nDepth but I don't see a situation in which they
diverge).

I'm also a bit confused why this doesn't cause a bigger problem, it doesn't
seem to be level 0 is always wrong, but I've not figured out why.

Thanks in advance,

Dave

-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice