lilypond-devel
[Top][All Lists]
Advanced

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

Re: FYI pango/font status


From: Han-Wen Nienhuys
Subject: Re: FYI pango/font status
Date: Sun, 2 Jan 2005 12:58:07 +0100

address@hidden writes:
> > * Remove all support code for encoding within LilyPond.  [...]
> >   Encoding is either handled by (La)TeX, or by Pango.  This means
> >   that
> >
> >     \encoding
> >
> >   will disappear, as will the inputencoding field in \layout{}
> 
> We need a new command to select the backend -- I propose \TeXformat
> and \PSformat so that the `-f ps' and `-f tex' switches become
> obsolete.

And SVG/Gnome/whatever-we-come-up-with-next? I disagree with this
idea.

> > * We still could have LilyPond call iconv to convert other encodings
> >   to UTF-8, but my feeling is that this does not really add to the
> >   functionality. How is UTF8 support for other (non-emacs) editors,
> >   and what encodings besides latin1 are currently used for .ly
> >   files?
> 
> I suggest to let convert-ly do this job, namely to convert all files
> from latin-1 to UTF-8 which have been written for lilypond versions
> before 2.8.0.  We've never supported something different, right?

In theory we did, but  I haven't ever heard of anyone using a different
encoding.

> > * How do we deal with kerning in Pango?  AFAIK, Pango does not read
> >   AFM/TFM files, so how can it compute kernings?
> 
> IIRC Owen has mentioned that he plans to support reading of AFM files
> for Type 1 fonts to get kerning.  Kerning from OpenType should be
> supported already (but I'm not sure).

Do you know the status of these plans? Am I correct that we could have
kerning and a complete fontset already by re-packaging lmodern as OTF
and merging in the TFM hs? 

We should then rename ec-mftraced to lilypond-text-fonts, otherwise
packagers will be angry with us for introducing yet another
outline-font package.

> > * all font files should either be loaded through FC or by Lily
> >   directly.  Lily does not link to kpathsea anymore.
> 
> This is fine for the PS backend.  For the TeX backend, we should still
> support reading of TFM files.

Hmm. Not actually true; we only need guesses for the TeX backend, so
we could get away with outline bboxes.

> > * the CMR fonts do not have characteristics defined; the type1 fonts
> >   just list fontname = "cmbx12".  We should have a separate package,
> >   which collects all TeX type1 fonts (using kpathsea), defines
> >   style/weight/etc. characteristics and generates appropriate FC
> >   cache files.
> 
> Do you mean an additional configuration file which FC shall read?

Yes, it would be a configuration file that makes all (traced) TeX
fonts (including eg. Math and calligraphic fonts) available to
FontConfig, and hence to apps like Abiword, inkscape, etc. 

> > * How do we deal with design sizes?  We can kludge them onto
> >   font-weight and/or font-stretch.  It would be best if a feature
> >   was added to FC, where we can specify design sizes.
> 
> Write to Keith Packard -- a similar problem exists for Multiple
> Masters fonts, so maybe there is something available already.

I did some more research. It's possible to add a "designsize" property
to FcFontPattern. In fact, any property may be added, since properties
are generic. The distressing thing is that Pango does not expose it's
fontconfig interface to the world, so it's unclear whether we can
instruct Pango to use the designsize.

-- 

 Han-Wen Nienhuys   |   address@hidden   |   http://www.xs4all.nl/~hanwen 





reply via email to

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