https://bz.apache.org/ooo/show_bug.cgi?id=128356

--- Comment #16 from Arrigo Marchiori <[email protected]> ---
Fun fact: in comment #15 I thought I had a stack trace just before the moment
the wrong XML tag was emitted... but it was not!
In fact, if I understood correctly, that is the "autostyle collection" phase,
that consists of parsing the text as for exporting it... but not emitting any
tags (bAutoStyles is set to true, that translates to "do nothing" for XML
element emitters).

Because bAutoStyles de-activated the generation of the tag, the attribute set
for the element to be emitted remains full (instead of being emptied, as it
would happen if the tag was emitted), and causing the name clash later.

The XML element is emitted later, according to the following stack trace:

#1  0x00007fffedb08d5d in SvXMLExport::StartElement(rtl::OUString const&,
unsigned char)
    (this=0x7fffcc0fd420, rName=..., bIgnWSOutside=bIgnWSOutside@entry=1
'\001')
    at main/xmloff/source/core/xmlexp.cxx:2351

#2  0x00007fffedb08f1e in SvXMLElementExport::StartElement(unsigned short,
rtl::OUString const&, unsigned char)
    (this=this@entry=0x7fffffff81e0, nPrefixKey=nPrefixKey@entry=1, rLName=...,
bIgnoreWhitespaceOutside=bIgnoreWhitespaceOutside@entry=1 '\001') 
    at main/xmloff/source/core/xmlexp.cxx:2654

#3  0x00007fffedb0902e in SvXMLElementExport::SvXMLElementExport(SvXMLExport&,
unsigned short, rtl::OUString const&, uns
igned char, unsigned char)
    (this=0x7fffffff81e0, rExp=<optimized out>, nPrefixKey=<optimized out>,
rLName=..., bIWSOutside=<optimized out>, bIWSInside=<optimized out>)
    at main/xmloff/source/core/xmlexp.cxx:2683

#4  0x00007fffedbe252f in SvXMLAutoStylePoolP_Impl::exportXML(int,
com::sun::star::uno::Reference<com::sun::star::xml::sax::XDocumentHandler>
const&, SvXMLUnitConverter const&, SvXMLNamespaceMap const&,
SvXMLAutoStylePoolP const*) const
    (this=<optimized out>, nFamily=nFamily@entry=32767,
pAntiImpl=pAntiImpl@entry=0x7fff97b6f510)
    at main/xmloff/source/style/impastp4.cxx:477

#5  0x00007fffedbed974 in SvXMLAutoStylePoolP::exportXML(int,
com::sun::star::uno::Reference<com::sun::star::xml::sax::XDocumentHandler>
const&, SvXMLUnitConverter const&, SvXMLNamespaceMap const&) const
    (this=this@entry=0x7fff97b6f510, nFamily=32767, nFamily@entry=100)
    at main/xmloff/source/style/xmlaustp.cxx:434

#6  0x00007fffedc6b912 in XMLTextParagraphExport::exportTextAutoStyles()
(this=0x7fff9c3bd050)
    at main/xmloff/source/text/txtparae.cxx:3537

#7  0x00007fffa2d13c14 in SwXMLExport::_ExportAutoStyles()
(this=0x7fffcc0fd420)
    at main/sw/source/filter/xml/xmlfmte.cxx:237

#8  0x00007fffedb0d48e in SvXMLExport::ImplExportAutoStyles(unsigned char)
(this=this@entry=0x7fffcc0fd420)
    at main/xmloff/source/core/xmlexp.cxx:1252

The common frames are no. 8 here and no. 25 in the previous comment.
In other words, we are still in SwXMLExport::_ExportAutoStyles() and we
advanced from line 218 from line 237.

At this point, it seems that the previous phase ("autostyle collection") has
prepared an XML tag without emitting it, but setting its attributes. This phase
consists of analyzing those attributes and emitting another tag (<style:style>)
using... other? or maybe the same? attributes.

This system is flawed because the previous phase tried to duplicate an
attribute, and this phase blindly outputs the duplication.

In order to fix this, we need to understand very well what each one of the
plethora of involved classes does. I am afraid it's not going to be a short
trip.

-- 
You are receiving this mail because:
You are the assignee for the issue.

Reply via email to