Bug 158903

This problem is really gcc#19870#, but I can work around it by horribly hacking
the source java to the xstlfilter implementation to seding private/protected to
public. So should work in 106-1

but still no, odd.

I tried doing this in the recently released openoffice.org-1.9.112.1.1.0.fc4,
but no luck.  I opened up a new untitled file, typed the words: "This is a
test".  Went to "Test XML Filter: DocBook File", selected "Current document",
and I see no output in the validate window and the warning: 

Warning: Could not get charToByteConverterClass!

output to the console.

Another time I did the same thing, I got the following backtrace:

0x6f7b0a: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1db0a
0x6f8358: /usr/lib/openoffice.org2.0/program/libuno_sal.so.3 + 0x1e358
0xe2f420:  + 0x420 (__kernel_sigreturn + 0x0)
0x67fa948: /lib/libc.so.6 + 0x29948 (abort + 0xf8)
0xb1cb72c9: /usr/lib/libgcj.so.6 + 0x5cc2c9 (_Jv_Throw + 0x51)
0xb1cabb66: /usr/lib/libgcj.so.6 + 0x5c0b66 (_Jv_NewPrimArray + 0x0)
0xb1caa828: /usr/lib/libgcj.so.6 + 0x5bf828
0xf592e3: /usr/lib/openoffice.org2.0/program/libcomphelp4gcc3.so + 0x842e3
0xf58a66: /usr/lib/openoffice.org2.0/program/libcomphelp4gcc3.so + 0x83a66
(comphelper::OSLOutputStreamWrapper::writeBytes(com::sun::star::uno::Sequence<signed
char> const&) + 0x32)
0x2948dea: /usr/lib/openoffice.org2.0/program/libgcc3_uno.so + 0x4dea
0x294914c: /usr/lib/openoffice.org2.0/program/libgcc3_uno.so + 0x514c
0x29495ac: /usr/lib/openoffice.org2.0/program/libgcc3_uno.so + 0x55ac
0x3320735: /usr/lib/openoffice.org2.0/program/libjava_uno.so + 0x10735
0x3320da3: /usr/lib/openoffice.org2.0/program/libjava_uno.so + 0x10da3
(Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call + 0x49f)
0xb204e847: /usr/lib/libgcj.so.6 + 0x963847 (ffi_call_SYSV + 0x17)
0xb204e809: /usr/lib/libgcj.so.6 + 0x963809 (ffi_raw_call + 0x63)
0xb1cb5565: /usr/lib/libgcj.so.6 + 0x5ca565 (_Jv_JNIMethod::call(ffi_cif*,
void*, ffi_raw*, void*) + 0xf3)
0xb204e6bc: /usr/lib/libgcj.so.6 + 0x9636bc
0xb204e847: /usr/lib/libgcj.so.6 + 0x963847 (ffi_call_SYSV + 0x17)
0xb204e809: /usr/lib/libgcj.so.6 + 0x963809 (ffi_raw_call + 0x63)
0xb1cc0654: /usr/lib/libgcj.so.6 + 0x5d5654 (_Jv_InterpMethod::run(void*,
ffi_raw*) + 0x13f2)
0xb1cc3f2d: /usr/lib/libgcj.so.6 + 0x5d8f2d
(_Jv_InterpMethod::run_normal(ffi_cif*, void*, ffi_raw*, void*) + 0x2b)
0xb204e6bc: /usr/lib/libgcj.so.6 + 0x9636bc
0xb1ce7241: /usr/lib/libgcj.so.6 + 0x5fc241 (_Jv_ThreadRun(java::lang::Thread*)
+ 0x27)
0xb1fa11a4: /usr/lib/libgcj.so.6 + 0x8b61a4
0xb205e7cf: /usr/lib/libgcj.so.6 + 0x9737cf (GC_start_routine + 0x9a)
0x57ab80: /lib/libpthread.so.0 + 0x5b80
0x689bdee: /lib/libc.so.6 + 0xcadee (__clone + 0x5e)

Hmm, I just tried it again after the first time (before quitting OOo) and it
worked (this time saving directly to DocBook rather than running an XSLT
tranformation test).  I'll restart OOo and investigate further.

OK, it seems that it can save the simple DocBook file, but it does not survive
the round trip if I attempt to reopen again my saved file docbook.xml with contents:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
<article lang="en-US"><sect1><title>Heading1</title>
<para>A paragraph</para></sect1></article>

This file is valid DocBook:

$xmllint --noout --valid docbook.xml

produces no output.

When the file is opened (either specifically the file type as "DocBook" or
letting OOo choose the file type automatically) the text is displayed without
the correct style, i.e. Heading1 is not used for the <title>Heading1</title>.  

Then if I resave that, it loses title information, docbook-roundtrip.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd">
<article lang="en-US">
<para>Heading1</para>
<para>A paragraph</para>
</article>

Perhaps this is a new bug and needs to be filed separately or an upstream bug.

I've been getting consistent success (i.e. docbook filter doesn't spew errors)
with 1.9.122 under fc5. So I think the "docbook doesn't work" is fixed.

On the issue that on re-load the docbook doesn't have a heading style applied I
can see on a sunjava varient of OOo that the sunjava docbook filter is behaving
the same way. So that's not fedora specific, I think it's this bug
http://qa.openoffice.org/issues/show_bug.cgi?id=51180