On Wed, Aug 13, 2008 at 5:17 PM, Patrice Dumas <pertusus@xxxxxxx> 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-packaging > > -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
