Re: UTF8 and (La)TeX backend?

[Werner LEMBERG]

> > I believe that `-f tex' and `-f ps' are fundamentally different,
> > and that we shouldn't invest time to `unify' both interfaces.
>
> I disagree.  We want both to look equal or as similar as possible.
> For example, we can have people develop a score using GNOME point
> and click, then print samples using PS output, and do final touchup
> on the SVG output.

Sorry to say but I think this is not realistic.  GNOME, PS, and SVG
are all based on Pango, while TeX isn't (and never will be).

> Of course, we can decide that TeX is the odd one out, but then we
> have to figure out a way to make lilypond-book use the -f ps backend
> (because we want the manual to use the preferred backend, of
> course).

lilypond-book should support both `-f ps' and `-f tex'.

> We could do so by dumping systems as separate EPS files, and dumping a
> .tex file saying
>
>   \includegraphics{system1.eps}
>   \includegraphics{system2.eps}
>   \includegraphics{system3.eps}
>   \includegraphics{system4.eps}
>
> the last actually has my preference, since I am not a fan of the tex
> backend.

:-)

> How do we prevent bigcheese20.otf from ending up hundreds of times
> in the output?

It shouldn't be too difficult:

  . LilyPond produces EPS files which contain

      %%DocumentNeededResources: font bigcheese20

    but doesn't contain the font itself.  (I'm not sure whether such
    files can be called `EPS' since they aren't fully self-contained.)

  . The CFF part of bigcheese20.otf is extracted and put into a PS
    resource which is loaded with the -h option of dvips.  If that
    doesn't work, lilypond-book simply emits
    \special{header=bigcheese.cff} at the beginning of the document.

> > It probably makes sense to pronounce the differences between `-f
> > tex' and `-f ps' w.r.t. font handling even more -- what about
> > renaming the TeX font attributes to `tex-font-...'?
>
> I don't think this is an improvement.

After some thinking, I agree.  It would be great if the interfaces
could be unified, but I fear that this is not trivial.

> * 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'.

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.  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?

      +------------------------------------------------------+
      | (EPS image)                                          |
      |                                                      |
      |     Allegro con brio                                 |
      |                                                      |
      |                                                      |
      |                                       espress.       |
      |                   leg.                               |
      +------------------------------------------------------+

The TeX backend then simply creates a box which contains the EPS file
and commands to position the text strings correctly.


    Werner