Specifying BibTeX engine

Specifying BibTeX engine

[Philipp Reichmuth]

Hi,

texexec has been doing the necessary BibTeX calls for some time now, but 
is there a way to configure which BibTeX engine is being called?  I am 
using BibTeX 8 (because of Unicode in my bibliography) and have been 
renaming the executable so far, but it seems there should be a better way.

(Incidentally, I've been using a Python script to convert BibTeX files 
between Unicode and {\=a}-style accent notation and am currently 
thinking of putting in ConTeXt {\adiaeresis}-style accents as well; 
would this be of interest to anyone?)

Philipp

Re: Specifying BibTeX engine

[Taco Hoekwater]

Philipp Reichmuth wrote:
> Hi,
> 
> texexec has been doing the necessary BibTeX calls for some time now, but 
> is there a way to configure which BibTeX engine is being called?  I am 
> using BibTeX 8 (because of Unicode in my bibliography) and have been 
> renaming the executable so far, but it seems there should be a better way.

The next release will have

	\setupbibtex[bibtex=bibtex8]

(default is the old one, because bibtex8 is not omnipresent).

Greetings, Taco

Re: Specifying BibTeX engine

[Philipp Reichmuth]

Taco Hoekwater schrieb:
> The next release will have
> 
> \setupbibtex[bibtex=bibtex8]

Great, thanks.

Philipp

Re: Specifying BibTeX engine

[gnwiii]

On 11/4/06, Philipp Reichmuth <reichmuth@web.de> wrote:
> Hi,
>
> texexec has been doing the necessary BibTeX calls for some time now, but
> is there a way to configure which BibTeX engine is being called?  I am
> using BibTeX 8 (because of Unicode in my bibliography) and have been
> renaming the executable so far, but it seems there should be a better way.

I've been editing the installprogram line found with:

 $ grep bibtex $(kpsewhich t-bib.tex)
%D \item bibtex is now registered as a program to be run by texexec (8/8/2006)
%D \item support mlbibtex
    2: file -- not found, waiting for bibtex
\def\setupbibtex{\dosingleempty\dosetupbibtex}
\def\dosetupbibtex[#1]%
     \installprogram{bibtex \jobname}}}
%D This is the result of bibtex's `language' field.

to replace "bibtex" with "ctxbibtex", which is a shell script I can edit
to use bibtex8, etc. with appropriate arguments (e.g., for very
large .bib files) as well as encoding tricks.  A dirty hack is to put an

       \installprogram{ctxbibtex \jobname}}}

line in your file (after the other setup).  The job runs bibtex and
then ctxbibtex, so you end up with the results of whatever is in your
script.
In MiKTeX-2.5 this works using "ctxbibtex.cmd" scripts.

> (Incidentally, I've been using a Python script to convert BibTeX files
> between Unicode and {\=a}-style accent notation and am currently
> thinking of putting in ConTeXt {\adiaeresis}-style accents as well;
> would this be of interest to anyone?)

I use GNU recode for this, but not with ConTeXt, where
"\enableregime[utf]" has been working with my utf8 bibliography, so
I haven't needed ConTeXt {\adiaeresis}-style accents.  My main concern
is searchable .pdf files, where the default Adobe Reader configuration
at work (Win32) seems to use plain old "a" in searches when I enter á,
etc. (search for xáy finds xay, xày, etc.).

I'd prefer to see a context encoding added to GNU recode for the
benefit of future archeologists trying to decipher ancient documents.

-- 
George N. White III <aa056@chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia

Unicode stuff (was: Re: Specifying BibTeX engine)

[Philipp Reichmuth]

gnwiii@gmail.com schrieb:
> to replace "bibtex" with "ctxbibtex", which is a shell script I can edit
> to use bibtex8, etc. with appropriate arguments (e.g., for very
> large .bib files) as well as encoding tricks.  A dirty hack is to put an
> 
>        \installprogram{ctxbibtex \jobname}}}
> 
> line in your file (after the other setup).  The job runs bibtex and
> then ctxbibtex, so you end up with the results of whatever is in your
> script.

OK, that's not pretty, but it would do the job, assuming that regular 
7-bit BibTeX doesn't bail out on Unicode files (which it sometimes does 
here).

>> (Incidentally, I've been using a Python script to convert BibTeX files
>> between Unicode and {\=a}-style accent notation and am currently
>> thinking of putting in ConTeXt {\adiaeresis}-style accents as well;
>> would this be of interest to anyone?)
> 
> I use GNU recode for this, but not with ConTeXt, where
> "\enableregime[utf]" has been working with my utf8 bibliography, so
> I haven't needed ConTeXt {\adiaeresis}-style accents.

Yes, the main reason I've been bothering with a custom script is that my 
bibliography program (Citavi) produces buggy export files with Unicode 
characters in BibTeX record keys, so I have to distinguish between 
Unicode in keys and in data and treat them differently.  Also not all of 
the characters I need are covered by ConTeXt-style accents.  (I could 
add them, of course, since I have the TeX code for them anyway; Hans, is 
there a canonical way to do this?)  Since I need to do some other fixes 
anyway, I've put it in an extra script.

I've been starting to reuse some of this work in a script to do active 
character assignment for XeTeX depending on what glyphs are present in 
an OpenType font, so that those characters for which the font doesn't 
have a glyph are generated by ConTeXt.  Basically I want to produce 
something like this:

\ifnum\XeTeXcharglyph"010D=0
     \catcode`č=\active \def č{\ccaron}
\else
     \catcode`č=\letter
\fi % ConTeXt knows this letter -> better hyphenation

\ifnum\XeTeXcharglyph"1E0D=0
     \catcode`ḍ=\active \def ḍ{\b{d}}
\else
     \catcode`ḍ=\letter
\fi % ConTeXt doesn't know this letter

(with \other, respectively, for non-letters).  Being somewhat of a 
novice to TeX programming, I'm not sure if this will work, though, and 
I'm also not sure if it's better to generate static scripts that do this 
for every font (so the resulting TeX file is a font-specific big list of 
\catcode`$CHARACTERs) or to do this dynamically on every font change, 
maybe limited to selectable Unicode ranges (which is more general but 
also a lot slower).

> I'd prefer to see a context encoding added to GNU recode for the
> benefit of future archeologists trying to decipher ancient documents.

That would be better I guess, but isn't ConTeXt encoding a moving target 
in that characters can still get added?  Or is the list fixed to AGL 
glyph names and nothing else?

Philipp

_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context

Re: Unicode stuff (was: Re: Specifying BibTeX engine)

[Mojca Miklavec]

On 11/4/06, Philipp Reichmuth wrote:
> I've been starting to reuse some of this work in a script to do active
> character assignment for XeTeX depending on what glyphs are present in
> an OpenType font, so that those characters for which the font doesn't
> have a glyph are generated by ConTeXt.  Basically I want to produce
> something like this:
>
> \ifnum\XeTeXcharglyph"010D=0
>      \catcode`č=\active \def č{\ccaron}
> \else
>      \catcode`č=\letter
> \fi % ConTeXt knows this letter -> better hyphenation
>
> \ifnum\XeTeXcharglyph"1E0D=0
>      \catcode`ḍ=\active \def ḍ{\b{d}}
> \else
>      \catcode`ḍ=\letter
> \fi % ConTeXt doesn't know this letter

No reason for not adding it.

> (with \other, respectively, for non-letters).  Being somewhat of a
> novice to TeX programming, I'm not sure if this will work, though, and
> I'm also not sure if it's better to generate static scripts that do this
> for every font (so the resulting TeX file is a font-specific big list of
> \catcode`$CHARACTERs) or to do this dynamically on every font change,
> maybe limited to selectable Unicode ranges (which is more general but
> also a lot slower).

Generating this for every single font would be stupid. This should be
part of low-level XeTeX (Jonathan has promised to look into it some
time). In my opinion the best way to deal with it would be the ability
to define a fall-back definition for "every" missing letter in a font.
Consequently, if you have "ddotbelow" missing in your font, XeTeX
would ask ConTeXt if some fallback definition has been provided for
that glyph, If yes, it would fall back to it, "\b{d}", but if the
glyph would be present in that font, XeTeX would use it.

> > I'd prefer to see a context encoding added to GNU recode for the
> > benefit of future archeologists trying to decipher ancient documents.
>
> That would be better I guess, but isn't ConTeXt encoding a moving target
> in that characters can still get added?  Or is the list fixed to AGL
> glyph names and nothing else?

No, it's certainly not fixed to AGL. But I wouldn't object adding it
to GNU recode (on top of "(La)TeX" which also recognizes \v, \b, ...)
if someone would decide to make a good revision of it and if more
people think that it would be useful (and if developers are open to
that idea). I try to use Unicode when writing sources whenever
possible.

Mojca


PS for Philipp: I didn't try out your definitions, but you have a cut
out of an older conversation as an example of what certainly doesn't
work under XeTeX ;)
(answer was written by Jonathan Kew) I was trying write a few macros
to support the old tfm-based fonts, but figured out that that was the
wrong starting point (and also other reason than yours).

> \catcode`ð=\active \defð{^^f0}
> \starttext
> Testing ... ð
> \stoptext
>
> and it seems to enter some infinite loop when ð is encountered (I can
> define any other letter as well, but only ^^f0 is causing problems).

No, this seems to me like it's the wrong way to define the character!
And I think you would have the same problem with other letters if
trying to define them as their own codes; the ones that work for you
must be getting defined as *different* codes from the original input.

The ^^xx notation is converted to a literal character by TeX's input
scanning routine, so it behaves exactly as if it were that character
itself. And ^^f0 in Latin-1 (or Unicode) is the ð character. So this
definition works exactly the same as if you were to say

  \catcode`ð=\active \defð{ð}

which is clearly recursive.

Given that you don't need to remap ð in the input to some other
Unicode character for printing, there should be no need for this at
all. The only reason to use a definition like this would be if the
input text used a *different* character where you want to print eth;
or you want to print something *other* than character F0 for the
input ð.

In general, a "safe" form of the definition would be to use \chardef:

  \catcode`ð=\active \chardefð="F0

This makes ð into a macro that expands to the character "F0; there is
an important difference between this and ^^f0, which actually
"becomes" the character ð itself as the input is read (and therefore
inherits its catcode, definition, etc).
_______________________________________________
ntg-context mailing list
ntg-context@ntg.nl
http://www.ntg.nl/mailman/listinfo/ntg-context