Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 158903 - DocBook XML/XSLT filters no longer work
Summary: DocBook XML/XSLT filters no longer work
Alias: None
Product: Fedora
Classification: Fedora
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-26 18:01 UTC by Paul W. Frields
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version: 1.9.122
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-06-29 12:41:15 UTC

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
GNU Compiler Collection 19870 None None None Never 51180 None None None Never

Description Paul W. Frields 2005-05-26 18:01:23 UTC
Description of problem:
In (shipped with FC4t3 base), I could create a simple Writer document using Title, Heading<N>, and Paragraph styles,
and export it correctly as DocBook XML.  This function no longer works with (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 09:36:54 UTC
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 23:42:27 UTC
but still no, odd.

Comment 3 Alex Lancaster 2005-06-29 12:00:29 UTC
I tried doing this in the recently released,
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/ + 0x1db0a
0x6f8358: /usr/lib/openoffice.org2.0/program/ + 0x1e358
0xe2f420:  + 0x420 (__kernel_sigreturn + 0x0)
0x67fa948: /lib/ + 0x29948 (abort + 0xf8)
0xb1cb72c9: /usr/lib/ + 0x5cc2c9 (_Jv_Throw + 0x51)
0xb1cabb66: /usr/lib/ + 0x5c0b66 (_Jv_NewPrimArray + 0x0)
0xb1caa828: /usr/lib/ + 0x5bf828
0xf592e3: /usr/lib/openoffice.org2.0/program/ + 0x842e3
0xf58a66: /usr/lib/openoffice.org2.0/program/ + 0x83a66
char> const&) + 0x32)
0x2948dea: /usr/lib/openoffice.org2.0/program/ + 0x4dea
0x294914c: /usr/lib/openoffice.org2.0/program/ + 0x514c
0x29495ac: /usr/lib/openoffice.org2.0/program/ + 0x55ac
0x3320735: /usr/lib/openoffice.org2.0/program/ + 0x10735
0x3320da3: /usr/lib/openoffice.org2.0/program/ + 0x10da3
(Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_dispatch_1call + 0x49f)
0xb204e847: /usr/lib/ + 0x963847 (ffi_call_SYSV + 0x17)
0xb204e809: /usr/lib/ + 0x963809 (ffi_raw_call + 0x63)
0xb1cb5565: /usr/lib/ + 0x5ca565 (_Jv_JNIMethod::call(ffi_cif*,
void*, ffi_raw*, void*) + 0xf3)
0xb204e6bc: /usr/lib/ + 0x9636bc
0xb204e847: /usr/lib/ + 0x963847 (ffi_call_SYSV + 0x17)
0xb204e809: /usr/lib/ + 0x963809 (ffi_raw_call + 0x63)
0xb1cc0654: /usr/lib/ + 0x5d5654 (_Jv_InterpMethod::run(void*,
ffi_raw*) + 0x13f2)
0xb1cc3f2d: /usr/lib/ + 0x5d8f2d
(_Jv_InterpMethod::run_normal(ffi_cif*, void*, ffi_raw*, void*) + 0x2b)
0xb204e6bc: /usr/lib/ + 0x9636bc
0xb1ce7241: /usr/lib/ + 0x5fc241 (_Jv_ThreadRun(java::lang::Thread*)
+ 0x27)
0xb1fa11a4: /usr/lib/ + 0x8b61a4
0xb205e7cf: /usr/lib/ + 0x9737cf (GC_start_routine + 0x9a)
0x57ab80: /lib/ + 0x5b80
0x689bdee: /lib/ + 0xcadee (__clone + 0x5e)

Comment 4 Alex Lancaster 2005-06-29 12:06:48 UTC
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 12:20:10 UTC
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 12:41:15 UTC
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.