Bug 158903 - DocBook XML/XSLT filters no longer work
DocBook XML/XSLT filters no longer work
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Depends On:
  Show dependency treegraph
Reported: 2005-05-26 14:01 EDT by Paul W. Frields
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.9.122
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-06-29 08:41:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 19870 None None None Never
OpenOffice.org 51180 None None None Never

  None (edit)
Description Paul W. Frields 2005-05-26 14:01:23 EDT
Description of problem:
In openoffice.org-1.9.100-1 (shipped with FC4t3 base), I could create a simple
OpenOffice.org Writer document using Title, Heading<N>, and Paragraph styles,
and export it correctly as DocBook XML.  This function no longer works with
openoffice.org-1.9.104-2 (newest devel updates).

Version-Release number of selected component (if applicable):

How reproducible:
Every time.

Steps to Reproduce:
1. Open Writer
2. Create simple document using only Heading 1 and a small Paragraph of text.
3. Choose either File -> Save as... or Tools -> XML Filter -> Test XSLTs.
Actual results:
XSLT test does not work, and save fails with an error dialog "The file could not
be written."

Expected results:
Output of XML either to screen (Test XSLTs) or to file (Save as).

Additional info:
If this is merely a packaging problem, having this fixed for FC4 would be a big
boost for the Fedora Docs Project.
Comment 1 Caolan McNamara 2005-06-02 05:36:54 EDT
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
Comment 2 Caolan McNamara 2005-06-14 19:42:27 EDT
but still no, odd.
Comment 3 Alex Lancaster 2005-06-29 08:00:29 EDT
I tried doing this in the recently released openoffice.org-,
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
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)

Comment 4 Alex Lancaster 2005-06-29 08:06:48 EDT
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.
Comment 5 Alex Lancaster 2005-06-29 08:20:10 EDT
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"
<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"
<article lang="en-US">
<para>A paragraph</para>

Perhaps this is a new bug and needs to be filed separately or an upstream bug.
Comment 6 Caolan McNamara 2005-06-29 08:41:15 EDT
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

Note You need to log in before you can comment on or make changes to this bug.