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-ope... http://existentialtype.net/2008/07/19/fonts-in-latex-part-three-pdftex-and-t...
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@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_other...
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-packaging
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.
On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot nicolas.mailhot@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.
2008/7/25 Vasile Gaburici vgaburici@gmail.com:
On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot nicolas.mailhot@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 :-(
On Fri, Jul 25, 2008 at 10:50 PM, Dave Crossland dave@lab6.com wrote:
2008/7/25 Vasile Gaburici vgaburici@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.
On Fri, 2008-07-25 at 23:18 +0300, Vasile Gaburici wrote:
On Fri, Jul 25, 2008 at 10:50 PM, Dave Crossland dave@lab6.com wrote:
2008/7/25 Vasile Gaburici vgaburici@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.
On Fri, 2008-07-25 at 20:50 +0100, Dave Crossland wrote:
2008/7/25 Vasile Gaburici vgaburici@gmail.com:
On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot nicolas.mailhot@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.
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?
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@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
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-hebrew...
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.
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@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-hebrew...
So proper packaging of Type1, TTF and OTF fonts would probably be something like this
- 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
2008/7/27 Vasile Gaburici vgaburici@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.
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@gmail.com wrote:
2008/7/27 Vasile Gaburici vgaburici@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:
- Form a TeX SIG.
- Get some TeX packaging guidelines in place
- 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.
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:
- Form a TeX SIG.
- Get some TeX packaging guidelines in place
- 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,
On Sun, Jul 27, 2008 at 7:08 PM, Nicolas Mailhot nicolas.mailhot@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...
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@gmail.com wrote:
On Sun, Jul 27, 2008 at 7:08 PM, Nicolas Mailhot nicolas.mailhot@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...