Re: Best way to add a line to a config file from another package?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Well, changing the default configuration file is not necessarily
something that dvips developers need to hear about. The original
config.ps file has section saying:
% This shows how to add your own map file.
% Remove the comment and adjust the name:
% p +myfonts.map

On the other hand, this extra psfonts_t42.map configuration file I'm
adding is in a way a workaround for the current behavior of updmap,
which puts ".ttf" entries in both psfonts_t1.map and psfonts_pk.map,
even though that practically means dvips will use bitmaps for ttfs
regardless whether you enabled dvipsPreferOutline, which defaults to
on. I'm not the first person to be annoyed by this. There's been a
long thread on tex.fonts about this a couple of year back
[http://osdir.com/ml/tex.fonts/2006-08/msg00017.html], but nobody
changed anything...

However, if one were to change updmap to add ".t42" entries instead of
".ttf" to psfonts_t1.map instead of my solution of using an additional
map, then one needs to make sure that the TeX distro ships t42
counterparts for all ttf fonts it ships because there is no fallback
for dvips anymore if dvipsPreferOutline is enabled. And there are some
ttf fonts shipped with TeXLive, but obviously no t42 versions.

A more elegant solution would be for dvips itself to encapsulate TTF
fonts in Type 42 as needed, but I don't know how easy is that to hack,
especially since dvips has no notion of dvipsPreferOutline; the
desired behavior is obtained by updmap symlinking psfonts.map to
either psfonts_t1.map or psfonts_pk.map. The teTeX fokes, which
intially wrote updmap, seem to have preferred this hack instead of
changing dvips...

It's not clear if dvips is even supported/maitained anymore by Radical
Eye. Their web page [http://www.radicaleye.com/dvips.html] says "To
get the latest version of dvips, simply get the latest version of
teTeX or some other TeX distribution that includes dvips. [...] I no
longer support installation of dvips independent of full installation
of a TeX distribution." So, presumably we'd have to send the patch to
TeXLive. Adding an additional map seemed a lot simpler than dealing
with this mess...

On Tue, Aug 12, 2008 at 11:12 PM, Axel Thimm <Axel.Thimm@xxxxxxxxxx> wrote:
> On Tue, Aug 12, 2008 at 08:20:18PM +0300, Vasile Gaburici wrote:
>> Also, removing the entry is not necessary. Nothing breaks if the extra
>> map does not exist. It would actually be a bad idea to remove the
>> entry because Type 42 fonts generated by the user using otftotfm would
>> become unusable after the tool is uninstalled, even thought the tool
>> is not required to use the fonts it generated. Given this, I'll submit
>> a config patch for texlive-texmf-dvips.
>
> Ideally this sounds like something that should (also) be submitted
> upstream. If it's a change that people can only benefit from and
> doesn't stand in the way of upstream's future plans, upstream will
> accept it. Otherwise maybe upstream will even point out a flaw (not
> compatible with future upstream planned changes, different solution in
> works etc.).
>
> And if upstream signals green light for such a change the maintainer
> of the texlive packages will be easier to convince to allow for a
> patch.
>
>> > I've written a patch for otftotfm (and sent it upstream) that allows
>> > installation of Type 42 fonts from TrueType fonts.
>
> Patching config.ps and this patch should go hand in hand in both
> upstream and Fedora packaging. E.g. if the patch to otftotfm were to
> be rejected upstream with sane reasoning, then we shouldn't deviate.
>
> Sounds very interesting, I hope this goes through!
> --
> Axel.Thimm at ATrpms.net
>

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux