On Tue, Aug 12, 2008 at 07:48:30AM +0300, Vasile Gaburici wrote:
> I need to add line to /usr/share/texmf/dvips/config/config.ps to get
> some extra functionality enabled for lcdf-typetools, namely Type 42
> support. The config.ps file is properly marked as a config file in
> texlive-texmf-dvips. Is there some infrastructure that's normally used
> to hack config files or should I just echo "..." >> config.ps?

I think that it is improperly marked as %config. It should not be
touched upon by the user, and should be solely under the upstream or
packagers control. It should be, in my opinion, marked as
%ghost %verify(not size mtime md5)

That being said you are entitled to change that file as a packager
in a post-install script, however
* you should make sure that the change is reverted if your package is
removed.
* you should be very very careful, since this kind of change can
easily mess the system. It should be safe to be applied whatever
the order of package install (as constrained by the Requires),
and it should not output anything except in very rare cases.

Also if the change can be left in the file, it would even be better
to patch it in telive-texmf.

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Tue, Aug 12, 2008 at 08:09:04PM +0300, Vasile Gaburici wrote:
> No, it's actually a proper system-wide config file. I've edited my
> local config.ps successfully to enable Type 42 fonts by adding an
> additional map. Now I want to be able to do that system-wide when
> lcdf-typetools is installed.

It is, of course, a proper system-wide config file. But in my opinion
it should be overwritten by what upstream/packagers give, and user
changes should not be kept. If a user wants to have his changes kept,
he should copy the file to /etc/texmf/web2c/, his file will be used in
priority.

--
Pat

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Wed, Aug 13, 2008 at 5:17 PM, Patrice Dumas <pertusus@free.fr> wrote:
> On Wed, Aug 13, 2008 at 04:26:00AM +0300, Vasile Gaburici wrote:
>> 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
>
> I may be missing something, but it seems to me that we shouldn't
> hardcode map files in here, but instead use updmap.

Yes, you are missing something. By default dvips uses a single map
called psfonts.map[*]. What updmap esentially does is is to keep that
in sync with 2 other maps (for pdftex and dvipdfm), starting from a
single source: updmap.cfg. But if we add type 42 fonts, we *don't*
want pdftex and dvipdfm map files to have the same entries as dvips.
So using an additional map for dvips, which overrides some entries in
the one generated by updmap, is reasonable.
[*] I've glossed over the fact that there are two files psfonts_t1.map
and psfonts_pk.map, but only one is read via a symlink. The symlink is
changed by updmap depending on whether you set dvipsPreferOutline to
true or false.

Before my patch, otftotfm alrady installs it's own map, called
lcdftools.map, which serves as the master source map for the fonts it
has installed. It adds this map to updmap.cfg, so when updmap runs, it
basically copies any entries in lcdftools.map to the 3 maps (dvips,
pdftex, dvipdfm).

With my patch, otftoftm also creates a map called psfonts_t42.map, in
which it puts any t42 entries for the fonts it has installed. Except
that you don't need to run updmap to blast these entries to dvips
because it reads it directly (thanks to config.ps). It's okay not to
spread any of these t42 entries to other maps because no other program
can read those fonts. Actually, if you put a t42 font entry in
pdftex's map, it won't load the font at all.

I know this a bit hard to follow. I'll update the src rpm so you can
test this. I'm not adding any scriptlet for now, but I'll put
instructions for changing your user's config.ps in README.fedora.

>> 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.
>
> What about generating t42 versions, or have them in a package that dvips
> depends on (on fedora...)? And then patch updamap to use t42 fonts in
> priority over ttf fonts?

That was actually my first idea before I discovered that dvips can
read multiple maps by itself. It seems simpler, but it is far harder
to make work properly. If updmap automatically wrote t42 entries
instead of ttf entries into a single dvips map, then you'd have to
guarantee somehow that every ttf font has a t42 counterpart. Which is
not easy, because updmap is designed as "dumb" file synchronization
tool, not a font installer. Basically, it would have to check if the
t42 file exists, if not it would have to call otftotfm, which
essentially the reverse of how things are layered now, i.e. otftotfm
invokes updmap after all the required font files have been generated.
Updmap wansn't meant to do any of that. I doubt upstream would ever
accept the mission creep and significant changes in updmap that would
enatail.

>> 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...
>
> It indeed seems that dvips is maintained by texlive folks, at least
> that's the conclusion I came to when looking at what should come from
> texlive or not.
>
> --
> Pat
>
> --
> Fedora-packaging mailing list
> Fedora-packaging@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging
>
>

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

On Wed, Aug 13, 2008 at 5:17 PM, Patrice Dumas <pertusus@free.fr> wrote:
> On Wed, Aug 13, 2008 at 04:26:00AM +0300, Vasile Gaburici wrote:
>> 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
>
> I may be missing something, but it seems to me that we shouldn't
> hardcode map files in here, but instead use updmap.

Yes, you are missing something. By default dvips uses a single map
called psfonts.map[*]. What updmap esentially does is is to keep that
in sync with 2 other maps (for pdftex and dvipdfm), starting from a
single source: updmap.cfg. But if we add type 42 fonts, we *don't*
want pdftex and dvipdfm map files to have the same entries as dvips.
So using an additional map for dvips, which overrides some entries in
the one generated by updmap, is reasonable.
[*] I've glossed over the fact that there are two files psfonts_t1.map
and psfonts_pk.map, but only one is read via a symlink. The symlink is
changed by updmap depending on whether you set dvipsPreferOutline to
true or false.

Before my patch, otftotfm alrady installs it's own map, called
lcdftools.map, which serves as the master source map for the fonts it
has installed. It adds this map to updmap.cfg, so when updmap runs, it
basically copies any entries in lcdftools.map to the 3 maps (dvips,
pdftex, dvipdfm).

With my patch, otftoftm also creates a map called psfonts_t42.map, in
which it puts any t42 entries for the fonts it has installed. Except
that you don't need to run updmap to blast these entries to dvips
because it reads it directly (thanks to config.ps). It's okay not to
spread any of these t42 entries to other maps because no other program
can read those fonts. Actually, if you put a t42 font entry in
pdftex's map, it won't load the font at all.

I know this a bit hard to follow. I'll update the src rpm so you can
test this. I'm not adding any scriptlet for now, but I'll put
instructions for changing your user's config.ps in README.fedora.

>> 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.
>
> What about generating t42 versions, or have them in a package that dvips
> depends on (on fedora...)? And then patch updamap to use t42 fonts in
> priority over ttf fonts?

That was actually my first idea before I discovered that dvips can
read multiple maps by itself. It seems simpler, but it is far harder
to make work properly. If updmap automatically wrote t42 entries
instead of ttf entries into a single dvips map, then you'd have to
guarantee somehow that every ttf font has a t42 counterpart. Which is
not easy, because updmap is designed as "dumb" file synchronization
tool, not a font installer. Basically, it would have to check if the
t42 file exists, if not it would have to call otftotfm, which
essentially the reverse of how things are layered now, i.e. otftotfm
invokes updmap after all the required font files have been generated.
Updmap wansn't meant to do any of that. I doubt upstream would ever
accept the mission creep and significant changes in updmap that would
enatail.

>> 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...
>
> It indeed seems that dvips is maintained by texlive folks, at least
> that's the conclusion I came to when looking at what should come from
> texlive or not.
>
> --
> Pat
>
> --
> Fedora-packaging mailing list
> Fedora-packaging@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-packaging
>
>

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