Hi Andi,
First results:
- Replacing poi-ooxml-schemas with ooxml-schemas didn't show any difference.
- Didn't figure out how the xmlbeans debugging works. I add the following,
XBeanDebug.enable(XBeanDebug.TRACE_SCHEMA_LOADING);
XBeanDebug.log("Starting with " + outputName);
but this just emits the single log message without tracing much of anything.
I added these lines before creating the XMLSlideShow.
The netbeans module class paths looks identical for both cases - as reported by
org.netbeans.core.startup.Main.getModuleSystem().getModuleJars()
and all the jars are available:
{path}/modules/org-marko.jar
{path}/modules/ext/poi-ooxml-3.12-20150511.jar
{path}/modules/ext/xmlbeans-2.6.0.jar
{path}/modules/ext/poi-3.12-20150511.jar
{path}/modules/ext/ooxml-schemas-1.1.jar
{path}/modules/ext/poi-scratchpad-3.12-20150511.jar
I can't actually figure out how to interrogate the class-loaders directly to
find out what it can possibly resolve.
However, using a basic printf-style debugging, I was able to find this
interesting behaviour.
The tables' CTTable representation are in both cases (good and bad table
generation) identical, but their CTGraphicalObjectFrame are radically different.
In the bad generation, the table graphic representation is empty - it appears
to only be getting the prototype information.
Digging some more, it looks like some variant of the bug 49934 is hitting (saw
the comment in XSLFTable) ... despite using the full ooxml-schemas.
With some more printf-debugging:
for (XmlObject rs :
table.getXmlObject().getGraphic().getGraphicData().selectPath("declare
namespace a='http://schemas.openxmlformats.org/drawingml/2006/main' ./a:tbl")) {
System.out.println("class: " + rs.getClass());
System.out.println(rs.toString());
}
Reveals the bad table (called via macro):
class: org.apache.xmlbeans.impl.values.XmlAnyTypeImpl
<xml-fragment
xmlns:main="http://schemas.openxmlformats.org/drawingml/2006/main";>
<main:tblPr/>
<main:tblGrid/>
</xml-fragment>
Whereas the good table (called directly from action) has
class: org.openxmlformats.schemas.drawingml.x2006.main.impl.CTTableImpl
with the appropriate content.
I still can't figure if this is truly a caller issue, or if bug 49934 is still
partly the culprit.
In the XSLFTable constructor, there is a hack to catch exactly this case
(XmlAnyTypeImpl being returned).
In this case a new XmlObject is created from the factory to manage the CTTable,
but it looks to me that this xml-fragment is not being re-associated with the
graphic object frame, which should be its parent.
This could explain why the CTTable looks fine for both cases, but the final
output doesn't.
Maybe the getXmlObject() itself need to know about the hack? Ie,
if (hackedTable)
{
orig = super.getXmlObject()
// replace table element with CTTable fragement
}
Cheers,
/mark
This electronic transmission (and any attachments thereto) is intended solely
for the use of the addressee(s). It may contain confidential or legally
privileged information. If you are not the intended recipient of this message,
you must delete it immediately and notify the sender. Any unauthorized use or
disclosure of this message is strictly prohibited. Faurecia does not guarantee
the integrity of this transmission and shall therefore never be liable if the
message is altered or falsified nor for any virus, interception or damage to
your system.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
