Thanks! It's in XSSFBuiltinTableStyle.init() and TestTableStyles.testBuiltinStyleInit()
tests it. The issue is having to do something custom in the first place, since the specification XML isn't quite the same format as styles.xml. I documented it in the init() method. I parse the whole file at once into a Document, and then iterate on the child element nodes. For each one, we need a CTDxfs and a CTTableStyles built from the immediate child nodes of those types. When I tried it it didn't throw any errors, and the toString() values for the objects showed the right XML, but none of the getters returned any values from that XML, so the factory didn't actually parse the node tree. Thus my hack to convert those nodes back to XML text, wrap them in boilerplate, and parse it as a styles.xml. Would save time and memory at least if I went to the trouble of just streaming the XML or even text and checking for style boundaries, but I went with faster and easier to start with. Greg On Fri, May 12, 2017 at 12:12 PM Nick Burch <apa...@gagravarr.org> wrote: > On Fri, 12 May 2017, Greg Woolsey wrote: > > Argh, fat fingered it before I could type my comment. > > No worries! We all do it eventually... Don't forget you can edit the > message later: > > http://stackoverflow.com/questions/2184317/change-svn-commit-message-retroactively > > > My implementation is really ugly imho, but it works. I couldn't figure > > out a way to get XMLBeans factories on the CT classes to initialize the > > full objects from an XML fragment, only top-level documents, so I fake > > up a styles.xml for each built-in style found, and parse those. Takes > > about 2.5 seconds on my system, which is why I made it lazy. > > I *think* I got that working in the past elsewhere. If you let me know > which class has the faking in, and the best unit test to use to check > with, I can try and have a go! > > Nick > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
