Package: openjade
Version: 1.4devel1-14
Followup-For: Bug #138924
Hello.
As a user who has been wary of openjade, due to how very long it seems to
take to process even a simple file, then as a user of the Debian BTS I
had noticed the bug report, about the excessive catalog parsing.
I thought I would mention that there is at least a partial workaround, such
that may be of relevance. (This matter is, furthermore, derived after the
nice Debian SGML catalog policy -- another pip for broad, practical
standardization of the OS, there.)
The workaround: The user can limit the set of catalogs that OpenJade will
access.
Here's an exampe with jw. Of particulary import are the --nostd and -c
arguments
jw --parser $(which openjade-1.4devel) --nostd \
-c
/etc/sgml/sgml-data.cat:/etc/sgml/openjade.cat:/etc/sgml/docbook.cat:/etc/sgml/docbook-dsssl.cat
\
[other args...] file.sgml
More directly about OpenJade:
Also directly with OpenJade, the -c argument is one means for having catalogs
become known to OpenJade.
I'm not sure if the openjade command will accept multiple system identifiers
in the value to the -c argument, but I'd presume it would -- e.g. when the
catalogs' system identifiers would be separated with the colon (:) character,
as with the call to jw, demonstrated above.
I'm not exactly sure how OpenJade would use SGML_CATALOG_FILES, either. Yet,
that environment variable appears to be related to this.
Looking at some of the contents of the 'jw' script, it appears that
SGML_CATALOG_FILES is afffected within the environment for OpenJade --
affected, when by way of jw, then according to the -c and --noestd arguments
on jw.
Regarding jw, by the looks of the shell-script of it: Ordinarily, jw will
set SGML_CATALOG_FILES according to a pretty broad-covering default. That
is, unless the --nostd argument is provided to jw, in which case, only those
catalogs specified with the -c argument will be loaded (as far as I can tell)
Regarding OpenJade, I'd like to suggest they'd use a hash-table for stroing
the catalog contents, all, after *one* parsing.
I'm not greatly familiar with C or C++, however. I could suggest it, though
pretty obliquely, and with no clear means for to patch it.
Regardless, I'm glad to know what was the hangup in openjade. I'd like to
thank you, honestly, for having explained the matter -- and you know, there
is credit due to the designers/implementors of the Debian BTS and QA system.
In some comparison, with the limited catalog set: Here's a time report, with
the limited-catalogs jw call, above, made on another very simple document
real 6m39.860s
user 4m30.661s
sys 0m34.700s
It's not as rosy as with jade, sure, but it's better than an eon -- and
before this matter of your bug report, I hadn't known if OpenJade ever
would stop processing.
My being unable to patch it, myself, but I hope they will find some time, to
get around to resolving this matter of excessive catalog parsing.
Regardless, I like OpenJade's features. So, to end this with: OpenJade is
some good work, yah?
and thank you.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i586)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.11.8
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages openjade depends on:
ii libc6 2.3.5-3 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.1-4 GCC support library
ii libosp4c2 1.5.1.0-4 Runtime library for OpenJade group
ii libostyle1c2 1.4devel1-14 Runtime libraries for OpenJade
ii libstdc++6 4.0.2-2 The GNU Standard C++ Library v3
ii sgml-base 1.26 SGML infrastructure and SGML catal
openjade recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
