[Bug 458430] Review Request: lcdf-typetools - Tools for manipulating OpenType and PostScript fonts
bugzilla at redhat.com
bugzilla at redhat.com
Thu Sep 4 18:42:37 UTC 2008
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
--- Comment #6 from Vasile Gaburici <gaburici at cs.umd.edu> 2008-09-04 14:42:37 EDT ---
I'll only reply to a questions, I'll change the spec to reflect the other
(In reply to comment #5)
> Why disabling the self auto tests?
1) Fedora's TeXLive doesn't use $SELFAUTO* variables in its texmf.cnf. So, to
use otftotfm with it, there's no need for otftotfm to check for those.
The $SELFAUTO* stuff is useful only if you move the _entire_ TL tree from a
location to another, e.g. the mount point of the TL DVD is not known for some
arbitrary Unix/Windows system. That model doesn't fit so well with rpm because
you'd have to store somewhere where you've relocated the texlive packages
already installed so you can put the rest (later) in the same place. AFAIK, rpm
doesn't have this feature.
$ rpm -qi texlive | grep Relocations
Name : texlive Relocations: (not relocatable)
2) If you install upstream's TL 2008 (not from rpms), which does use $SELFAUTO
variables in its texmf.cnf, into /opt/tl/2008 for instance, then
kpathsea-linked binaries installed outside this tree, which include anything
installed from rpms, don't really work with TL 2008, even if you change the
TEXMFCNF environment variable to point to TL 2008's texmf.cnf. The reason is
that any kpathsea-linked binary from (say) /usr/bin, will read TL 2008's
texmf.cnf and set TEXMFMAIN and similar variables relative to the path of the
binary, i.e. /usr/bin, completely ignoring where the TL 2008 tree is actually
located; that's what $SELFAUTOPARENT does. So, $SELFAUTO* configuration isn't
useful for rpm-installed binaries in this case either.
To actually get kpathsea-linked binaries from /usr/bin to work with a separate
TL tree, you need to change TL's texmf.cnf, either directly, or via a shell
variables so that it doesn't use $SELFAUTO* stuff. See for instance:
> I think it could be possible to include as a Source file
Doesn't GPLv2 trump the BSD license that some of the (library) files come
> What is under the 'Redistributable, no modification permitted' license?
> This doesn't look acceptable in fedora?
The -tex subpackage (otftotfm) includes Adobe's Glyph List, hence the different
subpackage license. The license for AGL is given at the top of the file:
This file also included as-is in Fedora's dvipdfmx even though not mentioned in
the license. See:
The data from that file is used in other programs dealing with Adobe fonts,
e.g. freetype and poppler. So, the license is probably okay for Fedora.
> About the t42 patch:
> I think I understood the t42 map stuff. It looks correct to me, but
> certainly suboptimal -- though no more than doing a link with
> dvipsPreferOutline instead of having dvips use that to prefer outline
> fonts to bitmap fonts.
> You should certainly patch the man page of otftotfm to explain what
> this does.
Yes the patch is functional but has rough edges w.r.t. documentation and
configurablility. I applied it following our discussion on the devel mailing
list, so you'd be able to see what I was talking about.
> What do texlive people think about this whole issue, and upstream?
I did send the t42 patch upstream to Eddie. He had very quick turnaround
applying upstream some other patches I've sent him (see the spec Changelog),
but for this one I haven't heard back. I'll ping again.
> Also I don't really understand what otftotfm does with updmap. How
> do the new map file become known by updamp? Does it add the .map it
> generates in updmap.cfg (not the t42 map, the regular map)?
Yes, it adds a line to the per-user updmap.cfg, which is normally in
~/.texlive2007/texmf-config/web2c. The line it adds makes updmap include
~/.texlive2007/texmf-var/fonts/map/dvips/lcdftools/lcdftools.map, which is
entirely maintained by otftotfm.
> I am reluctant to let this be added to fedora only, in case it has to be
> withdrawn later, the users would be left with a setup that doesn't
> work anymore.
I can certainly disable the patch for now; I would also be more comfortable if
upstream applied it because it's a fairly significant new feature. The files
(fonts, encodings, maps) that otftotfm installs work however even if you
completely remove lcdf-typetools from the system. Lcdf-typetools are only
needed during the font installation/conversion; the files produced, even with
the t42 add-on patch, do not require anything but "bog standard" web2c TeX,
something that TeXLive more than qualifies for.
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the fonts-bugs