refdb-devel — List for RefDB developers

[Refdb-devel] backend-bibtex.c + runbib

[Markus H. <mar...@mh...>]

Hi,

Damien Jade Duff writes:
 >        strcmp(type, "RPRT") == 0 || strcmp(type, "CONF") == 0 )

I've checked in this one.
 >          {
 > /*djd 20060101 It may be that we want to put "HEAR" in here too???*/
 > 

I'm not sure about this one though. Is "HEAR" really treated like a
book rather than like an article? I have to admit that I don't have
the faintest idea what a "HEAR" really looks like and how it is
published. Are there any examples available online?

 > 
 >    else if (strcmp(type, "CONF") == 0 || strcmp(type, "HEAR") == 0) {
 >      strcat(*(ptr_rendinfo->ptr_ref), "@INPROCEEDINGS{ ");
 > /* djd 20060101    strcat(*(ptr_rendinfo->ptr_ref), "@PROCEEDINGS{ "); */
 >    }
 > 

You know bibtex far better than me so I assume this change is correct.

 > (3)
 > in runbib:
 > 
 >    $mysort $filename | $myuniq | $myrefdbib $databaseopt $encodingopt
 > $useropt $passwdopt $iparg -S $style -t bibtex > $basename.bib
 >          if [ $? -ne 0 ]; then
 > #want to be able to deal with empty .aux file and keep on processing
 > #remaining aux files
 > #for case of linked (multiple) tex files
 > #              exit 1
 > echo No references retrieved from $filename
 >          fi
 > 

This makes sense to me.

Thanks for providing these improvements. I'm glad someone stress-tests
the bibtex support as I can't do this myself.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] backend-bibtex.c + runbib

[Damien J. D. <D.J...@cs...>]

Dear Markus

I've made 3 changes to programs in my refdb installation and I thought I
should let you know about them before the next release proper. They're
just simple changes where something wasn't working as I should like it.

I'm sending to the refdb-devel list because it's all written in lingua
programming.

Regards
Damien Jade Duff


(1)
in backend-bibtex.c:

   if (strcmp(type, "BOOK") == 0 || strcmp(type, "CHAP") == 0 ||
       strcmp(type, "SER") == 0 || strcmp(type, "THES") == 0 ||
/* djd20060101      strcmp(type, "RPRT") == 0) {*/
       strcmp(type, "RPRT") == 0 || strcmp(type, "CONF") == 0 )
         {
/*djd 20060101 It may be that we want to put "HEAR" in here too???*/


     /*----------------------------------------------------------------*/
     /* book title */
     item = get_refdb_booktitle_copy(ptr_rendinfo->dbires);
     if (item != NULL) {
       if ((new_ref = mstrcat(*(ptr_rendinfo->ptr_ref), "  BOOKTITLE =
{", ptr_rendinfo->ptr_ref_len, 0)) == NULL) {



(2)
in backend-bibtex.c:

   else if (strcmp(type, "CONF") == 0 || strcmp(type, "HEAR") == 0) {
     strcat(*(ptr_rendinfo->ptr_ref), "@INPROCEEDINGS{ ");
/* djd 20060101    strcat(*(ptr_rendinfo->ptr_ref), "@PROCEEDINGS{ "); */
   }

(3)
in runbib:

   $mysort $filename | $myuniq | $myrefdbib $databaseopt $encodingopt
$useropt $passwdopt $iparg -S $style -t bibtex > $basename.bib
         if [ $? -ne 0 ]; then
#want to be able to deal with empty .aux file and keep on processing
#remaining aux files
#for case of linked (multiple) tex files
#              exit 1
echo No references retrieved from $filename
         fi

[Refdb-devel] refdb-elisp build changes

[Markus H. <mar...@mh...>]

Hi,

this is mainly for package builders: I've added an info version of the
manual which is built from the DocBook XML file. You'll need
docbook2texi which is a part of the docbook2X package available at:

http://docbook2x.sourceforge.net/

The tool appears to be available in Debian unstable. It does not seem
to be available on FreeBSD, but I've installed it after manually
installing a missing Perl module.

Let me know if you have any problems with this change.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] CVS build problem: doc build fails on debian because no batik-rasterizer script

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > A simple fix might be to have the configure script look for 
 > 'batik-rasterizer' and 'convert' in that order.
 > 

I've changed RefDB along these lines, and fixed a couple of other
problems which made it hard to build RefDB on Debian. I didn't try
starting from a fresh CVS checkout, but I managed to build the
prerelease I've uploaded today on Debian including the
documentation. I hope it'll be easier for you now to build some .debs.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] CVS: strange script happenings

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > The build does not install a manpage for 'refdb-ms', although it 
 > installs the script itself.
 > 

I cannot verify this. I've removed /usr/local/man/man1/refdb-ms.1 and
ran "gmake install" in man/. This installed the file properly.

 > On the other hand, the manpages for 'refdb-backup' and 'refdb-restore' 
 > *are* installed, while the scripts themselves are *not*.
 > 
 > I'm guessing the backup and restore scripts miss out because they are 
 > not included in the relevant makefile variables, e.g. 'client_scripts'.
 > 

This is correct. My bad. I'll fix configure.in to include these
scripts.

 > I'm more unclear when it comes to the 'refdb-ms' manpage.  The relevant 
 > manpage infrastructure appears to be in place: the 'refdb-ms.1.in' file 
 > is present, as are the appropriate entries in '/man/Makefile.am'.
 > 
 > Does the same thing happen on your BSD box?  If so, how do we fix it?
 > 

There must be a simple explanation. Is the file refdb-ms.1 built at
all? Do you get any spurious warnings or error messages during
building or installing?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] CVS build problem: doc build fails with missing dependency

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > It's slightly spooky the way you pick the exact nature of my error from 
 > so far away.  That was indeed the problem.  Fixing it also fixed a 
 > number of other problems.
 > 

The simplest explanation is the correct one in this case: I've fooled
myself this way a couple of times :->

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] CVS build problem: doc build fails on debian because no batik-rasterizer script

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > A simple fix might be to have the configure script look for 
 > 'batik-rasterizer' and 'convert' in that order.
 > 

Unfortunately it's not that simple as both tools use different command
lines. batik-rasterizer infers the output name from the requested type
which is passed as an option. convert infers the output type from the
output filename which is passed as an argument. I'll try to find a way
to handle this cleanly.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] Doc error: all master index dtd links are indentical

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > Please note all DTD links point to the risx dtd documentation.
 > 

Wouldn't have happened with a typewriter. I've fixed this in CVS.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] CVS: strange script happenings

[David N. <dav...@sw...>]

Hi Markus,

Some weird things are occurring on my machine with scripts in the 
current cvs build process.

The build does not install a manpage for 'refdb-ms', although it 
installs the script itself.

On the other hand, the manpages for 'refdb-backup' and 'refdb-restore' 
*are* installed, while the scripts themselves are *not*.

I'm guessing the backup and restore scripts miss out because they are 
not included in the relevant makefile variables, e.g. 'client_scripts'.

I'm more unclear when it comes to the 'refdb-ms' manpage.  The relevant 
manpage infrastructure appears to be in place: the 'refdb-ms.1.in' file 
is present, as are the appropriate entries in '/man/Makefile.am'.

Does the same thing happen on your BSD box?  If so, how do we fix it?

Regards,
David.

[Refdb-devel] Doc error: all master index dtd links are indentical

[David N. <dav...@sw...>]

Hi Markus,

Here is the complete master index file from the /doc subdirectory:

--------------------------------------------------------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
  <head>
    <title>RefDB Documentation</title>
  </head>
  <body>
    <h1>RefDB Documentation</h1>
    <p>RefDB is a reference/notes database and bibliography tool for 
SGML, XML, and LaTeX documents. The following local documentation is 
available:</p>
    <ul>
      <li><a href="refdb-manual/index.html">RefDB manual</a></li>
      <li><a href="risx/index.html">risx DTD documentation</a></li>
      <li><a href="risx/index.html">citestylex DTD documentation</a></li>
      <li><a href="risx/index.html">xnote DTD documentation</a></li>
      <li><a href="risx/index.html">citationlistx DTD documentation</a></li>
    </ul>
    <p>Additional information is available on the web. Please visit <a 
href="http://refdb.sourceforge.net">RefDB on the web</a> for all 
available information.</p>
    <hr>
    <p>$Id: index.html,v 1.1.2.1 2005/10/21 19:43:13 mhoenicka Exp $ (c) 
<a href="mailto:mho...@us...">Markus Hoenicka</a> 
2005</p>
  </body>
</html>
--------------------------------------------------------------------------------------------

Please note all DTD links point to the risx dtd documentation.

Regards,
David.

Re: [Refdb-devel] CVS build problem: doc build fails on debian because no batik-rasterizer script

[David N. <dav...@sw...>]

Hi Markus,

> > Have you considered using 'convert' in 
> > the makefile instead of 'batik-rasterizer'?
>
>actually I thought I'd get away with using convert in the first place
>because it is the most widely utility used for image
>conversion. However, on FreeBSD the SVG conversion comes out garbled
>with both PDF and PNG output. Text strings are at the wrong places,
>the image is cropped at the left and the overall impression is
>blurred. I had to use batik-rasterizer in order to obtain satisfactory
>results. I'm right now updating my ImageMagick installation in order
>to see whether this problem has been fixed. I'd be more than happy to
>use convert instead of the arcane but good batik-rasterizer.
>


A simple fix might be to have the configure script look for 
'batik-rasterizer' and 'convert' in that order.

Regards,
David.

Re: [Refdb-devel] CVS build problem: absent man subdirectory

[David N. <dav...@sw...>]

Hi Markus,

> > In current CVS refdb there are references to the (now absent) /man 
> > subdirectory in configure.in (line 378) and Makefile.am (line 3) which 
> > cause compilation to fail.  If these references are removed to problem 
> > is fixed.
>
>I'm not sure how this comes about.
>

As always, don't overlook the possibility of stupidity as an 
explanation.  The failure to use '-d' in my update script meant my local 
repository drifted out of sync with that on sf despite regular cvs updates.

>BTW I'm in the middle of exploring a switch to XML for the manual. I'd
>like to build the man pages from DocBook sources which I can reuse in
>the manual, thus avoiding code duplication. I've tested doclifter for
>a few manpages with good results. I need an XSL customization layer to
>transform the manual, but the result seems to be ok. I use xsltproc
>for the transformation. Is there anything that I should watch for
>regarding compatibility issues with Debian?
>

Nothing that is readily apparent at this stage.  All of the tools you've 
mentioned are readily available on debian.  The compatibility problems 
that have occurred in the past are almost always associated with 
java-based tools.  These can be implemented radically differently on 
different platforms.  None of the tools you mentioned fall into this 
category.

Regards,
David.

Re: [Refdb-devel] CVS build problem: doc build fails with missing dependency

[David N. <dav...@sw...>]

Hi Markus,

> > With workarounds for the earlier problems, the build now fails due to a 
> > missing dependency on 'citestylex/ele-desc/*':
>
>The files citestylex/ele-desc/* are in CVS. Maybe you did not use the
>-d switch when cvs-updating your sources?
>


It's slightly spooky the way you pick the exact nature of my error from 
so far away.  That was indeed the problem.  Fixing it also fixed a 
number of other problems.

This is what happens when you use tools without fully understanding them.

Regards,
David.

[Refdb-devel] CVS build problem: absent man subdirectory

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > Hi Markus,
 > 
 > In current CVS refdb there are references to the (now absent) /man 
 > subdirectory in configure.in (line 378) and Makefile.am (line 3) which 
 > cause compilation to fail.  If these references are removed to problem 
 > is fixed.
 > 

I'm not sure how this comes about. The man directory is in my local
sources and I see it in the web cvs. Do you use HEAD instead of the
stable branch by any chance?

BTW I'm in the middle of exploring a switch to XML for the manual. I'd
like to build the man pages from DocBook sources which I can reuse in
the manual, thus avoiding code duplication. I've tested doclifter for
a few manpages with good results. I need an XSL customization layer to
transform the manual, but the result seems to be ok. I use xsltproc
for the transformation. Is there anything that I should watch for
regarding compatibility issues with Debian?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] CVS build problem: doc build fails on debian because no batik-rasterizer script

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > As a temporary fix I've altered the /doc makefile to use ImageMagick's 
 > 'convert' utility which is able to convert SVG to PDF and PNG.  This 
 > suite is available in BSD (port=ImageMagick) and contains the same 
 > utility called by the same name.  Have you considered using 'convert' in 
 > the makefile instead of 'batik-rasterizer'?
 > 

actually I thought I'd get away with using convert in the first place
because it is the most widely utility used for image
conversion. However, on FreeBSD the SVG conversion comes out garbled
with both PDF and PNG output. Text strings are at the wrong places,
the image is cropped at the left and the overall impression is
blurred. I had to use batik-rasterizer in order to obtain satisfactory
results. I'm right now updating my ImageMagick installation in order
to see whether this problem has been fixed. I'd be more than happy to
use convert instead of the arcane but good batik-rasterizer.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] CVS build problem: doc build fails with missing dependency

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > Hi Markus,
 > 
 > With workarounds for the earlier problems, the build now fails due to a 
 > missing dependency on 'citestylex/ele-desc/*':
 > 
[...]
 > As near as I can tell from the makefile, it truly is missing a rule for 
 > that target.
 > 

The files citestylex/ele-desc/* are in CVS. Maybe you did not use the
-d switch when cvs-updating your sources?

regards,
Markus


-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] CVS build problem: doc makefile uses incorrect wildcards

[Markus H. <mar...@mh...>]

Hi David,

David Nebauer writes:
 > citationlistx_DATA = citationlistx/*
 > ---------------------------------------------------------------------------------------------
 > 
 > This appears to be incorrect wildcard usage.  Here is an extract from 
 > the GNU 'make' info document:

[...]
 > citationlistx_DATA = $(wildcard citationlistx/*)
 > ---------------------------------------------------------------------------------------------
 > 
 > then that variable is processed correctly.

I'll test this on FreeBSD, but the change looks reasonable to me. I
just wonder why we didn't run into this problem with the libdbi and
libdbi-drivers docs as they use the same old hack. To the best of my
knowledge this hack was introduced by the original libdbi developers
who were avid Debian users.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] CVS build problem: doc build fails with missing dependency

[David N. <dav...@sw...>]

Hi Markus,

With workarounds for the earlier problems, the build now fails due to a 
missing dependency on 'citestylex/ele-desc/*':

--------------------------------------------------------------------------------------------
Creating HTML manual...
rm -rf refdb-manual/*
mkdir -p refdb-manual && cd refdb-manual && openjade -t sgml -d 
../../doc/include/doc-html.dsl /usr/share/refdb/declarations/docbook.dcl 
../../doc/refdb-manual.sgml
cp manual.css refdbmanualfig1.png refdbmanualfig2.png 
refdbmanualfig3.png refdbmanualfig4.png refdb-manual/
SGML_CATALOG_FILES=""  dtdparse --title "citestyle XML DTD" --output 
citestylex.xml --declaration ../declarations/xml.dcl --system-id 
"http://refdb.sourceforge.net/dtd/citestylex.dtd" ../dtd/citestylex.dtd
Public ID: unknown
System ID: http://refdb.sourceforge.net/dtd/citestylex.dtd
SGML declaration: ../declarations/xml.dcl
Parse complete.
Writing citestylex.xml...
Done.
make[2]: *** No rule to make target `citestylex/ele-desc/*', needed by 
`citestylex/elements.html'.  Stop.
make[2]: Leaving directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210'
make: *** [build-stamp] Error 2
-------------------------------------------------------------------------------------------

As near as I can tell from the makefile, it truly is missing a rule for 
that target.

Regards,
David.

[Refdb-devel] CVS build problem: doc build fails on debian because no batik-rasterizer script

[David N. <dav...@sw...>]

Hi Markus,

When the wildcard problem is fixed, the refdb build fails on debian at 
document generation because there is no 'batik-rasterizer' script on 
debian systems:

------------------------------------------------------------------------------------------
make[2]: Entering directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210/doc'
batik-rasterizer -m application/pdf refdbmanualfig1.svg
make[2]: batik-rasterizer: Command not found
make[2]: *** [refdbmanualfig1.pdf] Error 127
make[2]: Leaving directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210'
make: *** [build-stamp] Error 2
------------------------------------------------------------------------------------------

I have the debian batik package (libbatik-java) installed and up-to-date 
but it does not include *any* scripts.  I've tried running the 
rasterizer directly:

------------------------------------------------------------------------------------------
$ java -cp 
/usr/share/java/batik.jar:/usr/share/java/xerces.jar:/usr/share/java/js.jar 
org.apache.batik.apps.rasterizer.Main
java.security.AccessControlException: permission not granted
   at java.security.AccessControlContext.checkPermission 
(AccessControlContext.java:122)
   at java.security.AccessController.checkPermission 
(AccessController.java:76)
   at java.lang.SecurityManager.checkPermission (SecurityManager.java:343)
   at java.lang.System.setProperty (System.java:396)
   at 
org.apache.batik.util.ApplicationSecurityEnforcer.installSecurityManager 
(Unknown Source)
   at org.apache.batik.util.ApplicationSecurityEnforcer.enforceSecurity 
(Unknown Source)
   at org.apache.batik.apps.rasterizer.Main.execute (Unknown Source)
   at org.apache.batik.apps.rasterizer.Main.main (Unknown Source)
   at java.lang.VirtualMachine.invokeMain (VirtualMachine.java)
   at java.lang.VirtualMachine.main (VirtualMachine.java:108)
------------------------------------------------------------------------------------------

but either I am invoking the wrong class or there is some environmental 
variable set incorrectly.  The FreeBSD rasterizer script uses JPackage's 
java-utils to set variables and invoke the java rasterizer.  The 
java-utils infrastructure is not available in debian so the method used 
by the BSD rasterizer script to invoke the rasterizer can't be adapted 
for use on the debian platform.

As a temporary fix I've altered the /doc makefile to use ImageMagick's 
'convert' utility which is able to convert SVG to PDF and PNG.  This 
suite is available in BSD (port=ImageMagick) and contains the same 
utility called by the same name.  Have you considered using 'convert' in 
the makefile instead of 'batik-rasterizer'?

Regards,
David.

[Refdb-devel] CVS build problem: doc makefile uses incorrect wildcards

[David N. <dav...@sw...>]

Hi Markus,

I'm using the inbuilt documentation building recently incorporated into 
refdb.  Using the '--enable-docs' flag causes the build process to fail 
with the following feedback:

---------------------------------------------------------------------------------------------
make[2]: Entering directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210/doc'
make[2]: *** No rule to make target `citationlistx/*', needed by 
`all-am'.  Stop.
make[2]: Leaving directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210'
make: *** [build-stamp] Error 2
---------------------------------------------------------------------------------------------

This error appears to be in line 28:

---------------------------------------------------------------------------------------------
citationlistx_DATA = citationlistx/*
---------------------------------------------------------------------------------------------

This appears to be incorrect wildcard usage.  Here is an extract from 
the GNU 'make' info document:

---------------------------------------------------------------------------------------------
Wildcard expansion does not happen when you define a variable.
Thus, if you write this:

     objects = *.o

then the value of the variable `objects' is the actual string `*.o'.
However, if you use the value of `objects' in a target, prerequisite or
command, wildcard expansion will take place at that time.  To set
`objects' to the expansion, instead use:

     objects := $(wildcard *.o)
---------------------------------------------------------------------------------------------

In this case the variable citationlistx_DATA is literally being set to 
'citationlistx/*' with an unexpanded asterisk.

If the variable declaration is changed to use the 'wildcard' function as 
instructed in the 'make' info page:

---------------------------------------------------------------------------------------------
citationlistx_DATA = $(wildcard citationlistx/*)
---------------------------------------------------------------------------------------------

then that variable is processed correctly.  The build process then fails 
on the next variable with incorrect wildcard usage:

---------------------------------------------------------------------------------------------
make[2]: Entering directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210/doc'
SGML_CATALOG_FILES=""  dtdparse --title "citationlistx XML DTD" --output 
citationlistx.xml --declaration ../declarations/xml.dcl --system-id 
"http://refdb.sourceforge.net/dtd/citationlistx.dtd" 
../dtd/citationlistx.dtd
Public ID: unknown
System ID: http://refdb.sourceforge.net/dtd/citationlistx.dtd
SGML declaration: ../declarations/xml.dcl
Parse complete.
Writing citationlistx.xml...
Done.
make[2]: *** No rule to make target `citationlistx/ele-desc/*', needed 
by `citationlistx/elements.html'.  Stop.
make[2]: Leaving directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210/doc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory 
`/home/david/data/computing/projects/refdb/packages/refdb/custom/pkg/debianise/source/refdb-0.0-cvs-20051210'
make: *** [build-stamp] Error 2
---------------------------------------------------------------------------------------------

Regards,
David.

[Refdb-devel] CVS build problem: absent man subdirectory

[David N. <dav...@sw...>]

Hi Markus,

In current CVS refdb there are references to the (now absent) /man 
subdirectory in configure.in (line 378) and Makefile.am (line 3) which 
cause compilation to fail.  If these references are removed to problem 
is fixed.

Regards,
David.

Re: [Refdb-devel] refdb-elisp

[Markus H. <mar...@mh...>]

Hi,

David Nebauer writes:
 > 1.  Manual xml source file missing from cvs
 > 

My fault. I've checked in that file.

 > 
 > 2.  Paper size of PDF manual
 > 
 > This one is nitpicky.  The docbook stylesheets default to US letter 
 > size.  Can I suggest you add '--stringparam paper.type A4' to the 
 > Makefile xsltproc command for the refdb-mode-manual.pdf target to force 
 > production of an A4 pdf file.
 > 

I really don't know what to use here. I absolutely agree that A4 is
preferable over the weird formats used in the US. However, it is
possible to print a letter-sized document on both letter and A4 paper,
but if you try to print an A4-formatted document on letter paper, the
printouts often lack the page numbers. So if I switched to A4, I'd
have to fix the page margins too. I'll see what I can do.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] refdb-elisp

[David N. <dav...@sw...>]

Hi Markus,

>I suspected there is some automatism for this. I don't know whether it
>makes things more complicated, but I've changed Makefile.am to install
>refdb-mode-config.el as a configuration file in sysconfdir (usually
>/etc or /usr/local/etc). This is probably the most logical place as it
>now contains the locations of the viewing programs. If the Debian
>policy allows this, you could simply create a symlink in
>/etc/emacs/site-start.d pointing to that file.
>
>  
>

Not sure about the policy, but I did it anyway.  With the new package 
you will see it initially installs the startup file as a regular file.  
In post-processing this file is deleted and re-created as a symlink to 
/etc/refdb-mode-manual.el.

The package is now built from cvs source rather than the downloadable 
archive.  The main difference this causes is in the html manual.  Rather 
than the single page html file included in the archive, the html help 
files built from cvs are modular.  This makes for a rather messy 
document directory (/usr/share/doc/refdb-elisp) as the html files are 
mixed in with the AUTHOR, NEWS, changelog, pdf help and other document 
files.  It would be nicer if the html files were collected in their own 
subdirectory but it's not a major problem, especially since the html 
help index file and help pdf file are directly linked from the Debian 
documentation system (e.g. dwww).

I'll send the updated deb off list.

Regards,
David.

Re: [Refdb-devel] refdb-elisp

[David N. <dav...@sw...>]

Hi Markus,

Two points:

1.  Manual xml source file missing from cvs

The cvs repository for elisp doesn't contain refdb-mode-manual.xml.  
When building from the cvs download, 'make' complains it has no rule for 
refdb-mode-manual.xml.


2.  Paper size of PDF manual

This one is nitpicky.  The docbook stylesheets default to US letter 
size.  Can I suggest you add '--stringparam paper.type A4' to the 
Makefile xsltproc command for the refdb-mode-manual.pdf target to force 
production of an A4 pdf file.

Regards,
David.

Re: [Refdb-devel] refdb-elisp

[Markus H. <mar...@mh...>]

David Nebauer writes:
 > Don't forget Ted <http://www.nllgg.nl/Ted/> for those who want to edit 
 > RTF without the bloat of a full-fledged office suite.
 > 

Thanks for the hint. I've had a look at Ted years ago but it slipped
my mind.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de