[Bug 458430] Review Request: lcdf-typetools - Tools for manipulating OpenType and PostScript fonts
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=458430
--- Comment #6 from Vasile Gaburici <gaburici(a)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
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...
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.
15 years, 8 months
[Bug 458430] Review Request: lcdf-typetools - Tools for manipulating OpenType and PostScript fonts
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=458430
--- Comment #5 from Patrice Dumas <pertusus(a)free.fr> 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.
--
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.
15 years, 8 months
[Issue 79878] OO.o can not select modern font faces conveniently
by hdu@openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=79878
------- Additional comments from hdu(a)openoffice.org Thu Sep 4 14:09:14 +0000 2008 -------
@tora: thank you for the detailed insight into the CJK aspect of this problem!
@dtardon: while you are reworking this please consider tora's input too. Especially the common case
that some CJK font families are only distinguished by their weight (e.g. "Mincho W6" vs. "Mincho W8") is
bound to cause similar problems like the ones nmailhot and benlaenen mentioned (older font families
that had e.g. "condensed" or "outline" in the family name instead of the style name). My personal
preference would be if these family variants were merged into one family and the style attributes could
do the rest.
As far as I'm concerned I'd be happy with every change
- which doesn't introduce unsolvable regressions
- which allows simple backwards compatibility with existing documents
- which allows simple interoperability with other common document formats
- plays nicely with existing libraries (e.g. fontconfig)
- which goes into the direction Nicolas mentioned in e.g. desc27
- which keeps the style name exactly as defined by the font itself (except localized strings of course)
That's a big order though. Is it too big? Or should we continue to "just" fix the obvious issues with the
pitch attribute first and ignore the related issues for now? Solving the problems with pitch would go a
long way already...
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
15 years, 8 months
[Bug 16792] [GTK] Fails to render Japanese/Chinese text with simple path
by bugzilla-daemon@webkit.org
https://bugs.webkit.org/show_bug.cgi?id=16792
------- Comment #11 from alp(a)nuanti.com 2008-09-03 20:01 PDT -------
(In reply to comment #10)
> Created an attachment (id=23155)
--> (https://bugs.webkit.org/attachment.cgi?id=23155&action=view) [edit]
> Font selection and rendering fixes
>
> GTK+ font fixes and enhancements.
>
> Implement font fallback for the simple FontConfig-based text path and
> improve the Pango-based complex text path to make use of requested
> font properties and available font selection.
>
> Add text shadow support to the complex path.
>
Some notes on this patch:
1) These changes push Pango's high level (layout) API as far as it can go. If
we want to go further we'll probably want to use the low-level Pango API
directly as Mozilla does, but at least the complex path is now
feature-complete.
2) FontPlatformDataGtk's comparison operator and copy constructor need to be
fixed some time to avoid leaking FontPlatformDatas. The leaks are pretty minor
(per-font) and the fix was too involved to be ready for this patch.
3) Our FontConfig-based fallback font selection doesn't always match what Pango
would select since we don't have that kind of advanced coverage analysis, but
with these changes the simple path does successfully select fonts with the
necessary glyphs available for the first time.
I hope this improves the experience for users of non-Latin scripts and would be
interested to get some feedback. You need to build with the "freetype" backend
to see most of the improvements since they haven't been implemented in the
"pango" backend yet.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
15 years, 8 months
[Issue 79878] OO.o can not select modern font faces conveniently
by masayan@openoffice.org
To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=79878
User masayan changed the following:
What |Old value |New value
================================================================================
CC|'belegdol,beppec56,cmc,dta|'belegdol,beppec56,cmc,dta
|rdon,fedorafonts,hdu,khira|rdon,fedorafonts,hdu,khira
|no,mba,meywer,norbusan,ral|no,masayan,mba,meywer,norb
|phie,rene,thb,tora' |usan,ralphie,rene,thb,tora
| |'
--------------------------------------------------------------------------------
---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification
15 years, 8 months