Bug 458430 - (lcdf-typetools) Review Request: lcdf-typetools - Tools for manipulating OpenType and PostScript fonts
Review Request: lcdf-typetools - Tools for manipulating OpenType and PostScri...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
: 458429 (view as bug list)
Depends On:
Blocks: tex-fontools 458462
  Show dependency treegraph
 
Reported: 2008-08-08 03:48 EDT by Vasile Gaburici
Modified: 2009-07-05 16:02 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-09 02:46:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vasile Gaburici 2008-08-08 03:48:24 EDT
Spec URL: http://www.cs.umd.edu/~gaburici/lcdf-typetools.spec
SRPM URL: http://www.cs.umd.edu/~gaburici/lcdf-typetools-2.69-5.fc9.src.rpm
Description: 
LCDF Typetools consists of several command-line programs for inspecting
and manipulating OpenType fonts of both CFF (PostScript Type 2) and
TrueType flavors, as well as PostScript Type 1, and Type 1 multiple
master fonts. The otftotfm utility that creates TeX font metrics and
encodings is packaged separately in lcdf-typetools-tex.

$ rpmlint lcdf-typetools.spec
0 packages and 1 specfiles checked; 0 errors, 0 warnings.
Comment 1 Vasile Gaburici 2008-08-08 03:50:55 EDT
I (still) need a sponsor...
Comment 2 Parag AN(पराग) 2008-08-08 04:42:26 EDT
*** Bug 458429 has been marked as a duplicate of this bug. ***
Comment 3 Vasile Gaburici 2008-08-08 22:43:57 EDT
After some patching and complaining about usability upstream, a new version has been released. Please review this instead!

http://www.cs.umd.edu/~gaburici/lcdf-typetools-2.70-2.fc9.src.rpm
http://www.cs.umd.edu/~gaburici/lcdf-typetools.spec
Comment 4 Vasile Gaburici 2008-08-13 15:12:00 EDT
Updated with the preliminary Type 42 auto-generation patch:

http://www.cs.umd.edu/~gaburici/lcdf-typetools.spec
http://www.cs.umd.edu/~gaburici/lcdf-typetools-2.71-3.fc9.src.rpm
Comment 5 Patrice Dumas 2008-09-04 10:25:33 EDT
Issues:

The %_prefix definition and the %configure switches settings are not useful,
see
rpm --eval %configure

Why disabling the self auto tests?

You should remove
[ "$RPM_BUILD_ROOT" != "/" ] &&

I think that it is better not to have a dependency on
/usr/share/texmf/web2c/mktexupd
this file is supposed to be installed when kpathsea is installed, and
kpathsea is an automatic soname dependency.

Most of the files are under the GPLv2+ according to the license headers.
Others are under the CLICK license.
In the README they are said to be under the GPLv2 only.

I think that a short comment should explain the licensing,
in the spec file. Like

# header file GPLv2+ and CLICK license (BSD no advertising), 
# in README GPLv2 only.

What is under the 'Redistributable, no modification permitted' license?
This doesn't look acceptable in fedora?

It is better not to use fedora in the spec file, dist should be
preferred.

The
otftotfm.cc.TTinOTFrename
patch needs an explanation in the spec file

The auto-t42.patch is more or less explained in the README file, could be
worth saying it in a comment in spec file, that the README explains the
patch.


Suggestions:

I suggest naming the patch after the package name, and with the version
string showing in which version they were added, like:
Patch0:         lcdf-typetools-2.71-TTinOTFrename.patch

I think it could be possible to include as a Source file
http://www.read.cs.ucla.edu/click/license

I personally prefer having globs for man pages to catch different
compression schemes, or no compression, for example like

%{_mandir}/man1/cfftot1.1*




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.

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

What do texlive people think about this whole issue, and upstream?


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.
Comment 6 Vasile Gaburici 2008-09-04 14:42:37 EDT
I'll only reply to a questions, I'll change the spec to reflect the other remarks.

(In reply to comment #5)
> Issues:
> 
> 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: http://tug.org/pipermail/tex-live/2008-August/017338.html

> 
> I think it could be possible to include as a Source file
> http://www.read.cs.ucla.edu/click/license

Doesn't GPLv2 trump the BSD license that some of the (library) files come under?

> 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:
http://www.adobe.com/devnet/opentype/archives/glyphlist.txt

This file also included as-is in Fedora's dvipdfmx even though not mentioned in the license. See: https://www.redhat.com/archives/fedora-devel-list/2008-September/msg00000.html

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.
Comment 7 Patrice Dumas 2008-09-05 14:26:12 EDT
(In reply to comment #6)
> I'll only reply to a questions, I'll change the spec to reflect the other
> remarks.
> 
> (In reply to comment #5)
> > Issues:
> > 
> > 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.

Ah, ok, I had forgotten. A little comment would be nice.

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

This is in Spot hands now.
 

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

Ok.

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

Ok. I think that it is not said clearly enough in the  otftotfm,
but this is more for upstream.

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

Indeed, but there is also the additional change in dvips config file 
that goes side-by-side with the t42 maps. This will certainly be added
if the t42 map support goes in, and if reversed because upstream has
chosen another way we will be in trouble.
Comment 8 Patrice Dumas 2008-12-04 06:35:05 EST
Where do we stand here? I am ready to sponsor you, and the package is near from being acceptable, with (if you coordonate with dvips) or without your patch.

Are we waiting for Spot on the legal issue?
Comment 9 Matěj Cepl 2009-02-02 18:38:15 EST
Patrice, are you gone for good, even for this review?
Comment 10 Patrice Dumas 2009-02-02 19:35:01 EST
(In reply to comment #9)
> Patrice, are you gone for good, even for this review?

No, I am ready to do the review. I am still waiting for an answer to Comment #8, though.
Comment 11 Parag Nemade 2009-05-25 00:53:14 EDT
Ok. So no progress here and meantime I also forgot to look at new package queue and now I have submitted new package request for lcdf-typetools in review bug 501854.
If submitter still interested then I will drop my request otherwise I will be happy to maintain this package.

Hmm. Not much used TEX but I just want to have this package in fedora so if someone interested and knowing well TEX, he can maintain or co-maintain this package in review 501854.
Comment 12 Parag Nemade 2009-05-26 02:56:32 EDT
If no response received in next 15 days, I will close this review.
Comment 13 Parag Nemade 2009-06-09 02:45:53 EDT
Closing now as said earlier.

Note You need to log in before you can comment on or make changes to this bug.