[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UTF8 and (La)TeX backend?

From: Han-Wen Nienhuys
Subject: Re: UTF8 and (La)TeX backend?
Date: Mon, 3 Jan 2005 23:21:16 +0100

address@hidden writes:
> > * LilyPond needs to determine a font both in TeX and PS.
> > * LilyPond needs to load those metrics to get a rough estimate of
> >   sizes.
> Why do you need a rough estimate of sizes for the TeX backend?  I
> thought this is done by `-f texstr'.

Because -f texstr runs a full formatting run. To make that one run
sanely, we have to have dimensions which are somewhat realistic.

> To avoid misunderstandings, let me recapitulate:
>   . All backends except TeX directly produce output using font
>     information provided by fontconfig, and string dimensions provided
>     by Pango.  Even if they use TeX fonts, the information is based on
>     the PS outlines.

Yes. - and if possible, I would also like to do font selection for TeX
with pango.

> I fully support your idea to replace
>     ec-fonts-mftraced with cmsuper or something similar, converted to


>     OpenType so that the TFM files are no longer needed.  Ideally,
>     those OpenType TeX fonts should behave similar to any other
>     OpenType font; this means the loss of italic correction (which
>     isn't available in OpenType fonts), for example, but it assures
>     that the font interface doesn't have to cope with special cases.


>   . The TeX backend consists of two parts, `-f texstr', and `-f tex'.
>     Input files which are written for this backend won't produce good
>     results with other backends due to the different handling of text
>     strings.


> In general, we should make a distinction between direct output
> backends and backends producing output which is postprocessed.  For
> example, imagine a lilypond backend which creates groff input.  Why
> not indicate the fact that lilypond acts as a `preprocessor' with
> \TeXFormat or \groffFormat?  The default would then be \LilyFormat.
> For me, the very question is how to handle the data which must be
> independent of the backend, this is, how to output everything which
> isn't a text string.  As perverse as it probably sounds in the very
> first moment, what do you think of always create an EPS file, even for
> the TeX backend, but without the text strings?

Hmmm; that's an interesting idea. I agree it sounds perverse at the
beginning, but on 2nd thought it actually makes sense, because there
most of the TeX backend escapes to PS anyway, via the \embeddedps{}
macro. Nevertheless, I don't see what practical advatage it would


 Han-Wen Nienhuys   |   address@hidden   | 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]