TeX fonts, part one [Was: Re: [Fedora-packaging] Proposed amendment to general packaging guidelines: no bundling of fonts in other packages]
7:04 a.m.
I did not have time finish writing all the details below, I'll write
some more tonight, but before this Type 1 bashing gets out of hand,
read the stuff below. If you don't want the gory details, the bottom
line is that the mainstream TeX still works best with type-1 fonts.
And it isn't likely to go away soon. So I would not rush to deprecate
type 1 fonts, unless you want TeX users to stop using Fedora. This
isn't likely to change anytime soon. XeTeX is not as robust as the old
TeX, and still lacks some features next to pdftex. XeTeX's acceptance
with academic publishers is virtually nil today. And they, the
publishers dictate what most academics use to write papers, books etc.
The mainstream TeX (and by that I mean dvips, dvipdfm and pdftex)
cannot currently use OpenType/CFF, but only Type 1 (and some TeX font
specialties that are irrelevant in this discussion). CFF fonts need to
be converted to Type 1 using otftotfm. Several tools exist to automate
the CFF to Type 1 conversion for large font families because this can
be a LOT of work using otfotfm directly for fonts that have optical
sizes (like the Adobe Pro series). The most notable automation tools
are, in order of how complete they are: autoinst from fontools,
otfinst, and otftofd. Each has some features the other lacks, however.
Most notably fontools lacks optical size support. Some LaTeX packages,
like MinionPro, have their own otfotfm wrapper scripts, which are a
lot easier to use because some files (enc, fd) come pre-generated.
Furthermore, dvips and dvipdfm cannot use TrueType fonts directly
(regardless whether they have OpenType features), but can convert them
to bitmap PK fonts, which print ok, but may look bad on screen. In
contrast pdftex can embed TrueType as outlines in the pdf using
\DeclareTruetypeFont. Unfortunately, generating the TeX infrastructure
(tfm font metrics, encodings) for TrueType fonts requires MORE work
than generating the Type 1 from a CFF. This happens because a
different, less featured tool must be used: ttf2tfm. There are some
wrappers like ttf2tex (no longer maintained), and fontinst, which is
rather outdated. Autoinst (from fontools) is the only tool that
handles both OpenType CFF and TrueType.
Most tutorials for using TrueType with pdftex recommend using ttf2tfm directly.
FYI: XeTeX uses dvipdfmx as backend, which supports all flavors of
OpenType, but this requires xdv input that is not the same as the
traditional dvi produced by TeX. pdftex does not produce any
intermediate format.
For some simple usage examples see (note - first one is XeTeX):
http://existentialtype.net/2008/07/12/fonts-in-latex-part-one-xelatex/
http://existentialtype.net/2008/07/12/fonts-in-latex-part-two-pdftex-and-...
http://existentialtype.net/2008/07/19/fonts-in-latex-part-three-pdftex-an...
A complex example using Gentium via ttf2tfm:
http://tclab.kaist.ac.kr/ipe/pdftex_3.html
To be continued...
On Fri, Jul 25, 2008 at 2:33 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
On Fri, 2008-07-25 at 13:03 +0200, Patrice Dumas wrote:
> On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote:
> >
> > Frankly, the other font formats are so much less useful than modern font
> > formats, the probability someone did creative legal restructuring is
> > much lower.
Anyway, I've amended the proposal in a less format-oriented version
https://fedoraproject.org/wiki/PackagingDrafts/No_bundling_of_fonts_in_ot...
> > The big exception are Type1 fonts but I just hope they can
> > die die die (and if the Tex-Gyre situation is fixed and we can use OTF
> I don't think this may happen in a while because some very interesting
> apps (though not mainstream desktop apps, fortunately) uses type1
> fonts, mostly using t1lib, like xfig, xdvi, grace.
Our TEX can use TTF (OpenType TT) and OTF (OpenType CFF) now. Given that
OTF (OpenType CFF) embeds something very close to what PDF uses, I'd be
surprised if Ghostscript could not use the OTF TEX-Gyre fonts directly.
Do we really have so much interecting stuff that depends on Type1 once
TEX and GS are out of the way?
> > In the meanwhile, it may make sense to add Type1 to the list.
>
> For tex I believe that it will be too complicated to use the system
> fonts.
TEX now uses the same formats as everyone else (TTF and OTF). I frankly
do not think we can afford (or have the resources) to duplicate megs of
fonts in TEX-specific packages. If TEX can not use the fonts in
fontconfig directories, it just has to symlink them somewhere it can.
Regards,
--
Nicolas Mailhot
--
Fedora-packaging mailing list
Fedora-packaging(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
8:18 a.m.
On Fri, 2008-07-25 at 15:04 +0300, Vasile Gaburici wrote:
I did not have time finish writing all the details below, I'll
write
some more tonight, but before this Type 1 bashing gets out of hand,
read the stuff below. If you don't want the gory details, the bottom
line is that the mainstream TeX still works best with type-1 fonts.
And it isn't likely to go away soon.
Drat, and I was so happy to get rid of them :(
All my other points still stand, though.
— We should not ship X versions of the same URW fonts. We should
consolidate on the most recent one in OTF format.
— We should not hide general-purpose fonts in app-specific directories.
TEX should use system fonts directly.
— We should no ship font collections in a single package when the legal
context is so dangerous, but audit each font separately. Every time
someone has tried the font collection way it has finished badly.
--
Nicolas Mailhot
2:42 p.m.
On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
— We should not hide general-purpose fonts in app-specific
directories.
TEX should use system fonts directly.
XeTeX can do that. TeX probably NEVER will because that violates TDS.
If you don't what that means, then don't take on the subject of TeX
fonts.
2:50 p.m.
2008/7/25 Vasile Gaburici <vgaburici(a)gmail.com>:
On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
> — We should not hide general-purpose fonts in app-specific directories.
> TEX should use system fonts directly.
XeTeX can do that. TeX probably NEVER will because that violates TDS.
If you don't what that means, then don't take on the subject of TeX
fonts.
I second the idea that TeX ought to be an exception to the guideline
"not hide general-purpose fonts in app-specific directories"; TeX
predates all other programs in a GNU/Linux system, and TeX users have
hardended expectations about how it works; if Fedora's TeX package
fiddles with things, that will be a loss for users.
(I'm still not getting Nicolas' emails :-(
3:18 p.m.
On Fri, Jul 25, 2008 at 10:50 PM, Dave Crossland <dave(a)lab6.com> wrote:
2008/7/25 Vasile Gaburici <vgaburici(a)gmail.com>:
I second the idea that TeX ought to be an exception to the guideline
"not hide general-purpose fonts in app-specific directories"; TeX
predates all other programs in a GNU/Linux system, and TeX users have
hardended expectations about how it works; if Fedora's TeX package
fiddles with things, that will be a loss for users.
If Fedora ships a screwed-up TeX, it would incur a loss of users,
mostly of PAYING academic ones that buy RHEL through their
departments, like UMD's CS dept., which just finished a big upgrade of
all the CS RHEL machines... FYI: Macs are already the preferred choice
for laptops amongst my colleagues, because the can run both Unix apps
and Powerpoint hassle-free (OOo is still pathetic for presentations,
and not everyone has the patience that Beamer requires, especially for
graphics).
Back to the technical side, a font for TeX requires a tfm file (TeX
font metrics). To use it with LaTeX you also need a fd file, an
sometimes a sty with macros is provided, especially if the font has
features. These files don't really belong the the system fonts
directory because nothing but TeX can use them... So, for fubu-fonts,
you'd need an extra fubu-fonts-tex, or possible even a
fubu-fonts-latex package to hold the extra files (you need the latter
if you consider that latex is not required to use plain tex).
What I would like to see system fonts installing themselves for TeX
use, say via an autoinst postinst script. Like I said my "draft"
email, that's a lot of hassle for the users to do manually. That's why
I'm trying to get fontools resurected...
Also, the current texlive package has inconsistent rules for font
formats. The Gyre fonts are included as OTF, while the LM (Latin
Modern) are not, even though XeTeX needs them that way if you wan to
select them as non-default fonts. I suspect this didn't originate from
upstream.
4:33 p.m.
On Fri, 2008-07-25 at 23:18 +0300, Vasile Gaburici wrote:
On Fri, Jul 25, 2008 at 10:50 PM, Dave Crossland
<dave(a)lab6.com> wrote:
> 2008/7/25 Vasile Gaburici <vgaburici(a)gmail.com>:
> I second the idea that TeX ought to be an exception to the guideline
> "not hide general-purpose fonts in app-specific directories"; TeX
> predates all other programs in a GNU/Linux system, and TeX users have
> hardended expectations about how it works; if Fedora's TeX package
> fiddles with things, that will be a loss for users.
If Fedora ships a screwed-up TeX, it would incur a loss of users,
mostly of PAYING academic ones that buy RHEL through their
departments, like UMD's CS dept., which just finished a big upgrade of
all the CS RHEL machines...
Oh, please, I heard the same bogus arguments from Java people when we
started integrating Java under Linux at JPackage. I was not the "Java
way" (the "Java way" being whatever screwed up setup SUN historically
used). There would be a loss of users. Etc, etc
A few year forward SUN was quoting JPackage in all its Linux press
releases and trying to catch up with us.
There is no reason to fear changes when those changes are sound
engineering.
Back to the technical side, a font for TeX requires a tfm file (TeX
font metrics). To use it with LaTeX you also need a fd file, an
sometimes a sty with macros is provided, especially if the font has
features. These files don't really belong the the system fonts
directory because nothing but TeX can use them...
And thus TEX can keep them. But the common resources (OpenType fonts),
it gets to share them with the rest of the system, which means
installation in system dirs.
What I would like to see system fonts installing themselves for TeX
use, say via an autoinst postinst script.
You're welcome to propose amendments to our current font packaging
policy. We have no TEX rules right now because no TEX user was
interested in writing them and other people obviously couldn't.
The main requirements are:
1. The font specs must be kept simple (ie no complex in-spec scripting)
2. A font package can not require any specific font system on install.
It's only allowed to use one if already present, and it's the font
system responsability to discover resources that were installed before
it was on system.
(same proposal to bitmap users that complain of anti-bitmap ostracism)
Like I said my "draft"
email, that's a lot of hassle for the users to do manually. That's why
I'm trying to get fontools resurected...
Also, the current texlive package has inconsistent rules for font
formats. The Gyre fonts are included as OTF, while the LM (Latin
Modern) are not, even though XeTeX needs them that way if you wan to
select them as non-default fonts. I suspect this didn't originate from
upstream.
I can't comment on this part. For me they're all wrong.
--
Nicolas Mailhot
4:20 p.m.
On Fri, 2008-07-25 at 20:50 +0100, Dave Crossland wrote:
2008/7/25 Vasile Gaburici <vgaburici(a)gmail.com>:
> On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot
> <nicolas.mailhot(a)laposte.net> wrote:
>> — We should not hide general-purpose fonts in app-specific directories.
>> TEX should use system fonts directly.
>
> XeTeX can do that. TeX probably NEVER will because that violates TDS.
> If you don't what that means, then don't take on the subject of TeX
> fonts.
I second the idea that TeX ought to be an exception to the guideline
"not hide general-purpose fonts in app-specific directories"; TeX
predates all other programs in a GNU/Linux system, and TeX users have
hardended expectations about how it works; if Fedora's TeX package
fiddles with things, that will be a loss for users.
We're under a *nix. The TEX packagers can symlink the files to TEX
internal directories if that makes TEX users feel better. Though we've
been resorbing various private font repositories in the past years
(starting with the xorg ones) and mid term I don't see how TEX can
escape the trend.
That's the bad thing of switching to a common font format. (The good
thing being of course that you get access to the fonts other groups
provide)
(I'm still not getting Nicolas' emails :-(
I'm routing lab6.com through another smtp now. Of course that won't
change mails sent directly to the list. Someone is blackholing me
between Red Hat servers and yours.
--
Nicolas Mailhot
11:49 a.m.
On Fri, 2008-07-25 at 22:42 +0300, Vasile Gaburici wrote:
XeTeX can do that. TeX probably NEVER will because that violates TDS.
If you don't what that means, then don't take on the subject of TeX
fonts.
Symlinks?
--
behdad
http://behdad.org/
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
5:40 a.m.
I had a look the TDS (http://www.ctan.org/get/tds/tds.pdf). Nothing
written there prevents the use of symlinks. In fact their not even
mentioned because TDS is supposed work even on MSDOS. The question is
if it will actually work if we do that. I guess Jindrich Novy, the
texlive packaged owner knows better than any of us, so I'm cc-ing him.
So, Jindrich, the question is whether ripping out the TeX fonts
formats that are usable by the system at large (via freetype etc.),
and replacing them with symlinks in the TDS is going to work? A
potential problem that I see is that if texlive gets installed after
some fonts it needs to figure out and link to them...
On Sat, Jul 26, 2008 at 7:49 PM, Behdad Esfahbod <behdad(a)behdad.org> wrote:
On Fri, 2008-07-25 at 22:42 +0300, Vasile Gaburici wrote:
>
> XeTeX can do that. TeX probably NEVER will because that violates TDS.
> If you don't what that means, then don't take on the subject of TeX
> fonts.
Symlinks?
--
behdad
http://behdad.org/
"Those who would give up Essential Liberty to purchase a little
Temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin, 1759
6:08 a.m.
On Sun, 2008-07-27 at 13:40 +0300, Vasile Gaburici wrote:
I had a look the TDS (http://www.ctan.org/get/tds/tds.pdf). Nothing
written there prevents the use of symlinks. In fact their not even
mentioned because TDS is supposed work even on MSDOS. The question is
if it will actually work if we do that. I guess Jindrich Novy, the
texlive packaged owner knows better than any of us, so I'm cc-ing him.
It seems the tex-fonts-hebrew at least provides TEX context for some
system fonts
http://cvs.fedoraproject.org/viewcvs/devel/tex-fonts-hebrew/tex-fonts-heb...
So proper packaging of Type1, TTF and OTF fonts would probably be
something like this
1. normal foo-fonts system package that can be used by any font system,
including TEX
2. tex-foo-fonts or foo-texfonts package that depends on foo-fonts and
adds additionnal TEX files (without duplicating the font files
themselves), with symlinks or references or whatever works in TEX
3. master TEX comps group or package that assembles all the foo-texfonts
packages.
Of course I know next to nothing about TEX so I'd be a lot happier if
people like Jonathan Underwood wrote the whole TEX font packaging rules
in my stead.
--
Nicolas Mailhot
6:45 a.m.
The TeXNaming draft guidelines
[https://fedoraproject.org/wiki/PackagingDrafts/TeXNaming] seem to
indicate that "tex" should go before the package name. E.g.
tex-foo-fonts, and perhaps latex-foo-fonts as well. I don't know if
ConTeXt needs any special bits for fonts, but in Fedora it gets
packaged separately as texlive-context. The only bit that surely
doesn't need anything special is texlive-xetex, which can use the
system fonts.
A minor issue: dvipdfm and dvipdfmx don't have a tex prefix in their
package names, even though both put files in the system texmf tree. I
don't know if they're usable without TeX installed, but I kinda doubt
it...
There draft guidelines say that there are several ways to specify the
"Requires:" for TeX. But on a recent review, I got this:
? MUST: The package must meet the Packaging Guidelines .
The Requires for texlive-latex should be replaced with Requires: tex(latex)
The sooner this gets sorted out the better...
On Sun, Jul 27, 2008 at 2:08 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
On Sun, 2008-07-27 at 13:40 +0300, Vasile Gaburici wrote:
> I had a look the TDS (http://www.ctan.org/get/tds/tds.pdf). Nothing
> written there prevents the use of symlinks. In fact their not even
> mentioned because TDS is supposed work even on MSDOS. The question is
> if it will actually work if we do that. I guess Jindrich Novy, the
> texlive packaged owner knows better than any of us, so I'm cc-ing him.
It seems the tex-fonts-hebrew at least provides TEX context for some
system fonts
http://cvs.fedoraproject.org/viewcvs/devel/tex-fonts-hebrew/tex-fonts-heb...
So proper packaging of Type1, TTF and OTF fonts would probably be
something like this
1. normal foo-fonts system package that can be used by any font system,
including TEX
2. tex-foo-fonts or foo-texfonts package that depends on foo-fonts and
adds additionnal TEX files (without duplicating the font files
themselves), with symlinks or references or whatever works in TEX
3. master TEX comps group or package that assembles all the foo-texfonts
packages.
Of course I know next to nothing about TEX so I'd be a lot happier if
people like Jonathan Underwood wrote the whole TEX font packaging rules
in my stead.
--
Nicolas Mailhot
8:20 a.m.
2008/7/27 Vasile Gaburici <vgaburici(a)gmail.com>:
The TeXNaming draft guidelines
[https://fedoraproject.org/wiki/PackagingDrafts/TeXNaming] seem to
indicate that "tex" should go before the package name. E.g.
tex-foo-fonts, and perhaps latex-foo-fonts as well. I don't know if
ConTeXt needs any special bits for fonts, but in Fedora it gets
packaged separately as texlive-context. The only bit that surely
doesn't need anything special is texlive-xetex, which can use the
system fonts.
A minor issue: dvipdfm and dvipdfmx don't have a tex prefix in their
package names, even though both put files in the system texmf tree. I
don't know if they're usable without TeX installed, but I kinda doubt
it...
Yes, that should maybe be fixed up, and one could also make the same
argument for xdvik, I suppose. The notion of prefixing with tex- was
really meant for addon class file packages for tex, rather than binary
programs. But I see your point entirely.
There draft guidelines say that there are several ways to specify
the
"Requires:" for TeX. But on a recent review, I got this:
? MUST: The package must meet the Packaging Guidelines .
The Requires for texlive-latex should be replaced with Requires: tex(latex)
The sooner this gets sorted out the better...
Yes, it's a mess, and now it's starting to impact progress with
resolving the font issues. I had started to make some headway with
packaging guidelines a while back, and Patrice had also tackled it,
but between us we've dropped the ball.
In actual fact, the reason that I had made little headway is that when
you start to look at the problem carefully you start to realize that
it's a bit of a mistake for Fedora to be repackaging the texlive
distribution rather than packaging the individual upstream projects.
However, texlive does provide some really handy package integration
that we rely on, so we need to make use of that work. We've slowly
been making some progress splitting things out, but there's not many
packagers who seem to care much about TeX, alas.
Anyway, here's some things I see as a bit of a priority:
1) Form a TeX SIG.
2) Get some TeX packaging guidelines in place
3) Work with the fonts SIG to resolve the fonts mess.
Regarding 3, it seems to me that there's in principle nothing
technically stopping us moving in the direction that Nicholas paints
as desireable regarding proper system integration of the fonts (and
Nicholas is right to push for this). The approach I could imagine
working is roughly this:
For each font, create a standalone package which installs the font in
the system fonts directory, foo-fonts. During package building that
package would create and install the necessary symlinks and auxillary
files needed by tex (font metric files etc) and package them in a
subpackage, tex-foo-fonts (or maybe foo-fonts-tex). The
texlive-texmf-fonts package would then just require all of these
tex-foo-fonts packages. The tex-fontools will be really usefully for
taking care of this at package build time, so I am really glad that
Vasile Gaburici is moving that forward (and the lcdf-typetools
packaging). I think this is a better approach than using scriplets to
do the same thing at font install time if tex is installed.
Of course, until we actually try implementing such an approach, it'll
not become clear what the complications are. I have to admit, I'm not
massively familiar with the font packaging process in Fedora, but have
been reading through the wiki pages and looking at packages this
weekend - in fact I hadn't really wanted to raise a proposal until I
had a better and more complete understanding of the problem space, but
Nicholas' email has spurred me on a bit.
What do folks think? And I guess, more importantly, who's up for some work? :)
Jonathan.
9:54 a.m.
I need to digest this a bit more, but a quick note regarding the
(in)abilities of the automated TeX font tools is in order. Some
important TeX fonts like Latin Modern (also from GUST), cannot be be
currently correctly installed by autoinst. There are two obstacles:
- lack of optical size info in the Latin Modern OTFs (no OpenType 'size' tag)
- lack of support for optical sizes in autoinst. There's another tool
called otfinst (also a wrapper for lcdf-typetools) that can handle
optical size info if it is present in the OTF. But otfinst lacks a
bunch of other features that autoinst has (no .fd generation, no TTF
flavor of OpenType support). At some point I hope to port the opical
size support to autoinst, but these tools are written in different
languages, so it will take a while.
So, Fedora would still have to ship TeX font files separately (for
some fonts) until the tool set and upstream OTF packaging matures. But
for mundane OTF fonts, which don't have optical sizes, I don't see
serious show stoppers for the proposal to (i) generate their .tfm TeX
metrics automatically, and (ii) convert them to type 1 on the user's
machine. These to jobs could be handled by a simple invocation of
autoinst (with some parameters, like telling it if the font is serif
or not). So, for most fonts the foo-font-tex package could be just
some emtpy dirs and a %post invocation of autoinst. This method needs
some testing with various fonts before we commit to it.
TrueType fonts can be used used without conversion by pdftex, but TeX
metrics still have to be generated. Other TeX drivers, like dvips and
dvipdfm, can use TrueType fonts only if they are converted to bitmaps;
I don't think this is worth the hassle since the output would suck on
screen.
Btw, if you've never heard of Latin Modern -- it is the Computer
Modern extension to non-English western alphabets. XeTeX, since it
supports only UTF-8 input, uses Latin Modern as default font. There's
another package, called cm-super, that attempts the same feat, but it
uses autotraced fonts, so it's generally considered of inferior
quality. The guys from GUST wrote a tool called METATYPE1 which allows
them to compile METAPOST into type 1 fonts without autotracing. Latin
Modern is written in METATYPE1. Don't ask me if they had permission
from Knuth to do this...
On Sun, Jul 27, 2008 at 4:20 PM, Jonathan Underwood
<jonathan.underwood(a)gmail.com> wrote:
2008/7/27 Vasile Gaburici <vgaburici(a)gmail.com>:
> The TeXNaming draft guidelines
> [https://fedoraproject.org/wiki/PackagingDrafts/TeXNaming] seem to
> indicate that "tex" should go before the package name. E.g.
> tex-foo-fonts, and perhaps latex-foo-fonts as well. I don't know if
> ConTeXt needs any special bits for fonts, but in Fedora it gets
> packaged separately as texlive-context. The only bit that surely
> doesn't need anything special is texlive-xetex, which can use the
> system fonts.
>
> A minor issue: dvipdfm and dvipdfmx don't have a tex prefix in their
> package names, even though both put files in the system texmf tree. I
> don't know if they're usable without TeX installed, but I kinda doubt
> it...
>
Yes, that should maybe be fixed up, and one could also make the same
argument for xdvik, I suppose. The notion of prefixing with tex- was
really meant for addon class file packages for tex, rather than binary
programs. But I see your point entirely.
> There draft guidelines say that there are several ways to specify the
> "Requires:" for TeX. But on a recent review, I got this:
> ? MUST: The package must meet the Packaging Guidelines .
> The Requires for texlive-latex should be replaced with Requires: tex(latex)
>
> The sooner this gets sorted out the better...
>
Yes, it's a mess, and now it's starting to impact progress with
resolving the font issues. I had started to make some headway with
packaging guidelines a while back, and Patrice had also tackled it,
but between us we've dropped the ball.
In actual fact, the reason that I had made little headway is that when
you start to look at the problem carefully you start to realize that
it's a bit of a mistake for Fedora to be repackaging the texlive
distribution rather than packaging the individual upstream projects.
However, texlive does provide some really handy package integration
that we rely on, so we need to make use of that work. We've slowly
been making some progress splitting things out, but there's not many
packagers who seem to care much about TeX, alas.
Anyway, here's some things I see as a bit of a priority:
1) Form a TeX SIG.
2) Get some TeX packaging guidelines in place
3) Work with the fonts SIG to resolve the fonts mess.
Regarding 3, it seems to me that there's in principle nothing
technically stopping us moving in the direction that Nicholas paints
as desireable regarding proper system integration of the fonts (and
Nicholas is right to push for this). The approach I could imagine
working is roughly this:
For each font, create a standalone package which installs the font in
the system fonts directory, foo-fonts. During package building that
package would create and install the necessary symlinks and auxillary
files needed by tex (font metric files etc) and package them in a
subpackage, tex-foo-fonts (or maybe foo-fonts-tex). The
texlive-texmf-fonts package would then just require all of these
tex-foo-fonts packages. The tex-fontools will be really usefully for
taking care of this at package build time, so I am really glad that
Vasile Gaburici is moving that forward (and the lcdf-typetools
packaging). I think this is a better approach than using scriplets to
do the same thing at font install time if tex is installed.
Of course, until we actually try implementing such an approach, it'll
not become clear what the complications are. I have to admit, I'm not
massively familiar with the font packaging process in Fedora, but have
been reading through the wiki pages and looking at packages this
weekend - in fact I hadn't really wanted to raise a proposal until I
had a better and more complete understanding of the problem space, but
Nicholas' email has spurred me on a bit.
What do folks think? And I guess, more importantly, who's up for some work? :)
Jonathan.
11:08 a.m.
On Sun, 2008-07-27 at 14:20 +0100, Jonathan Underwood wrote:
In actual fact, the reason that I had made little headway is that
when
you start to look at the problem carefully you start to realize that
it's a bit of a mistake for Fedora to be repackaging the texlive
distribution rather than packaging the individual upstream projects.
I totally agree with this assessment
Anyway, here's some things I see as a bit of a priority:
1) Form a TeX SIG.
2) Get some TeX packaging guidelines in place
3) Work with the fonts SIG to resolve the fonts mess.
As long as what you do is text and font-related, you're welcome to work
within the Fonts SIG IMHO. Because in case you have noticed, setting up
a SIG and making it visible enough to influence upstreams is a lot of
work.
[OT We're listened to because we have a internet wiki presence so please
everyone do take care to fill and update the wiki pages associated to
your font packages. I know it's no fun stuff but it helps a lot.]
Of course that shouldn't stop you for setting a separate SIG if you feel
like it and have the necessary manpower. SIGs are fun.
Of course, until we actually try implementing such an approach,
it'll
not become clear what the complications are.
That's usually the case. It's an incrementatal
ooops-brownpaper-bag-decision process. :p
I have to admit, I'm not
massively familiar with the font packaging process in Fedora, but have
been reading through the wiki pages and looking at packages this
weekend - in fact I hadn't really wanted to raise a proposal until I
had a better and more complete understanding of the problem space, but
Nicholas' email has spurred me on a bit.
What do folks think? And I guess, more importantly, who's up for some work? :)
I obviously am already taken by other stuff, and I'll be away for a
month starting tomorrow, but I can offer the Fonts SIG infrastructure. I
do think TUG has the potential to be a big font provider, and there's a
lot of crossover between the Fonts SIG and what you want to do, so that
would be good for everyone.
Of course I don't speak for everyone in the SIG, so, people, if you
don't want TEX messages to crowd the list, please speak up now.
Best regards,
--
Nicolas Mailhot
11:57 a.m.
On Sun, Jul 27, 2008 at 7:08 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
On Sun, 2008-07-27 at 14:20 +0100, Jonathan Underwood wrote:
> In actual fact, the reason that I had made little headway is that when
> you start to look at the problem carefully you start to realize that
> it's a bit of a mistake for Fedora to be repackaging the texlive
> distribution rather than packaging the individual upstream projects.
I totally agree with this assessment
Well, the trouble is that there's no Linux/Unix TeX distro like
MiKTeX, which has a nice *modular* packaging system. I'd rather have a
Fedora-style TeX distro with frequent updates that TeXLive's once a
year monolithic disk image. There's a beta version of MiKTeX's
packaging tool (mpm) for Linux
[http://blog.miktex.org/post/2005/08/mpmunix.aspx], but so far nobody
made a Linux TeX distro using it. And that's a lot of work, so I'm not
signing up for it on my current schedule...
10:24 a.m.
Just in time, TeXLive now has a modular installer. Can even install off the net:
http://www.river-valley.tv/conferences/bachotex2008/#0104-Reinhard_Kotucha
On Sun, Jul 27, 2008 at 7:57 PM, Vasile Gaburici <vgaburici(a)gmail.com> wrote:
On Sun, Jul 27, 2008 at 7:08 PM, Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> wrote:
> On Sun, 2008-07-27 at 14:20 +0100, Jonathan Underwood wrote:
>
>> In actual fact, the reason that I had made little headway is that when
>> you start to look at the problem carefully you start to realize that
>> it's a bit of a mistake for Fedora to be repackaging the texlive
>> distribution rather than packaging the individual upstream projects.
>
> I totally agree with this assessment
Well, the trouble is that there's no Linux/Unix TeX distro like
MiKTeX, which has a nice *modular* packaging system. I'd rather have a
Fedora-style TeX distro with frequent updates that TeXLive's once a
year monolithic disk image. There's a beta version of MiKTeX's
packaging tool (mpm) for Linux
[http://blog.miktex.org/post/2005/08/mpmunix.aspx], but so far nobody
made a Linux TeX distro using it. And that's a lot of work, so I'm not
signing up for it on my current schedule...
5749
days inactive
5754
days old
15 comments
5 participants
participants (5)
-
Behdad Esfahbod -
Dave Crossland -
Jonathan Underwood -
Nicolas Mailhot -
Vasile Gaburici