[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] gxditview
Re: [Groff] gxditview
Mon, 10 Mar 2003 15:51:33 +0100 (CET)
> Running `diff -u GXditview.ad /etc/X11/app-defaults/GXditview' in the
> actual Debian stable results in
> +GXditview*fontMap: \
> +M -misc-fixed-medium-r-normal--*-100-*-*-*-*-jisx0208.1983-0\n\
> +G -misc-fixed-medium-r-normal--*-100-*-*-*-*-jisx0208.1983-0
These last two lines are due to Debian's groff extension for Japanese.
> This shows that the default font map is not mentioned in
> GXditview.ad. We could add this.
Yes, we could :-)
> Moreover, the Debian configuration file includes the additional
> fonts M and G. These two lines could be added at the end of the
> definition of `static char default_font_map' in `Dvi.c':
> M -misc-fixed-medium-r-normal--*-100-*-*-*-*-jisx0208.1983-0\n\
> G -misc-fixed-medium-r-normal--*-100-*-*-*-*-jisx0208.1983-0\n\
Definitely not, see above.
> Finally, we should think about making gxditview a normal part of
Are you volunteering? Here the steps:
. Move the common code for gxditview and xtotroff into a library,
. Create a new directory src/utils/xtotroff and move the
corresponding stuff to it.
. Add proper Makefile.sub files, update the top-level Makefiles, and
remove the Imakefile stuff. It may be necessary to add some
autoconf tests to properly handle X11.
> For installing it in /usr/bin/X11/gxditview will overwrite the
> system default, so the normal installation in /usr/local/bin will be
You are hitting a weak point of X. While it is easy to have multiple
locations for binaries, there is just one central directory for
application resources (usually X11/lib/X11/app-defaults) -- no support
for local trees a la TeX's kpathsea, only some environment variables
(see the documentation of XFILESEARCHPATH, XUSERFILESEARCHPATH, and
XAPPLRESDIR in the X(7) man page). While it is possible (to a certain
degree) to have a local X tree for resources, I doubt that many users
have set up X in this way (and Linux distributions also don't do this
IMHO it makes no sense to have the binary in /usr/local and the
resource in /usr.
Comments welcome, especially who this problem can be solved.