* fonts / proposal @ 2001-08-03 15:32 Hans Hagen 2001-08-03 20:06 ` Giuseppe Bilotta 2001-08-04 12:30 ` siepo 0 siblings, 2 replies; 15+ messages in thread From: Hans Hagen @ 2001-08-03 15:32 UTC (permalink / raw) Hi, I'm currently working on fonts, not so much in context itself, as well as installation. Since i want a clean way to install fonts [commercial ones for instance] and since licence policy is always tricky, i now put them in a dedicated tree texmf-fonts. In the texmf tree [as distribited by tex live] there are a couple of free fonts [we're talking outlines] but not that much. I don't want to let the rather latex oriented font naming and organization scheme 'spoil' things and i want users to be able to easilly use other encodings that ec too. How do users handle this currenlty, say that they want polish encoding? Installing fonts comes down to (1) generating the tfm's (2) if needed create vf files (3) if neede copy files to the right location (4) create a decent map file for pdftex in addition, if needed: (5) create slanted fonts (6) create small caps Now, since one font can be on the system in say texnansi, ec, pl0, csr or whatever encoding, and since users may have different opinions on how slanted or small capped a font may be, we end up in so many files that the current tex naming sheme drives at least me crazy. Also, i really want to avoid latex like fd files scattering the system. Therefore, this is what i have implemented and can support: (1) users choose a default encoding but can derive from it if needed, let's assume ec here (2) texfont creates a series of files from the afm files (we assume urw palatino): ec-urw-palatino.map ec-raw-*.tfm ec-*.tfm ec-*.vf (3) if needed also create slanted/caps alternatives (4) also, a tex test file generated that show that things are done ok (5) typescript files will mape symbolic names in an efficient way (6) map files will be loaded at run time [when enabled] an example of a generated file is: ec-blabla-slanted-167.tfm which is a bitthe x windows way of naming fonts. If needed one can have say 10 slanted and 5 extended and 2 capped files of one font. [there is currenty a make file that makes all files needed] What does this mean in practice? A couple of more files, but named in such a way that simple font users like me can see what happens. It also means that we can use one set of typescripts for all kind of encodings. A dedicated font tree so that we can consider zipping it and posting it. Now, if context comes with the typescripts that define fonts this verbose way. we can have a problem with users who want to stick to the 8 byte names and/or want to sort out the funny names themselves. Since filename mapping is implemented recursively, they can have a way out with a special file like: \definefontsynonym [ec-uplr8a-slanted-167] [uplro8t] where they may hope that the latter is indeed available, slanted 167, and in ec encoding. Are there any strong [and valid] objectiona against this scheme? The idea is, in the end to have a way to set up a minimal consistent system. Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-03 15:32 fonts / proposal Hans Hagen @ 2001-08-03 20:06 ` Giuseppe Bilotta 2001-08-04 11:45 ` Taco Hoekwater 2001-08-06 8:29 ` Hans Hagen 2001-08-04 12:30 ` siepo 1 sibling, 2 replies; 15+ messages in thread From: Giuseppe Bilotta @ 2001-08-03 20:06 UTC (permalink / raw) Cc: ntg-context Friday, August 03, 2001 Hans Hagen wrote: HH> Hi, HH> I'm currently working on fonts, not so much in context itself, as well as HH> installation. Since i want a clean way to install fonts [commercial ones HH> for instance] and since licence policy is always tricky, i now put them in HH> a dedicated tree texmf-fonts. I think the TeX Directory Standard puts fonts under \texmf\fonts\<type>\<class>\<vendor>\<name> e.g. \texmf\fonts\type1\public\ams\cmr or something of the sort. [snip] HH> an example of a generated file is: ec-blabla-slanted-167.tfm HH> which is a bit the x windows way of naming fonts. If needed HH> one can have say 10 slanted and 5 extended and 2 capped files HH> of one font. I think the (only) problem with this is that it fails on pure DOS system (8.3 naming constrictions). Since the font naming is X Windows-like, why don't you just use the X Windows scheme? [snip] HH> Now, if context comes with the typescripts that define fonts this verbose HH> way. we can have a problem with users who want to stick to the 8 byte names HH> and/or want to sort out the funny names themselves. Since filename mapping HH> is implemented recursively, they can have a way out with a special file like: HH> \definefontsynonym [ec-uplr8a-slanted-167] [uplro8t] HH> where they may hope that the latter is indeed available, slanted 167, and HH> in ec encoding. HH> Are there any strong [and valid] objectiona against this scheme? The idea HH> is, in the end to have a way to set up a minimal consistent system. I don't find any objections. The recursive fontsynonym technique also allows for automagic font substitutions: if ec-uplr8a-slanted-167 is not available, it can be mapped to the closer available font (e.g. removing the 167, which would seek for a "default" slanted font, then removing the "slanted" etc; something like using a * in a fontname part under X Windows). Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-03 20:06 ` Giuseppe Bilotta @ 2001-08-04 11:45 ` Taco Hoekwater 2001-08-06 8:29 ` Hans Hagen 1 sibling, 0 replies; 15+ messages in thread From: Taco Hoekwater @ 2001-08-04 11:45 UTC (permalink / raw) Cc: Hans Hagen, ntg-context Giuseppe Bilotta wrote: > > I think the TeX Directory Standard puts fonts under > > \texmf\fonts\<type>\<class>\<vendor>\<name> I strongly believe that was a mistake. Because that way, the different parts that make up a font are split over two or three separate directories. But that is not important now... > I think the (only) problem with this is that it fails on pure DOS > system (8.3 naming constrictions). Since the font naming is X > Windows-like, why don't you just use the X Windows scheme? The X system has rather a lot of keys that dont make sense in TeX. Here is the list and an example: Foundry Adobe Family Helvetica Weight bold Slant oblique Set Width expanded Additional Style Pixel Size 12 Point Size 120 Resolution X 75 Resolution Y 75 Spacing proportional Average Width 69 Charset iso8859-1 Slant and Spacing are actually one letter in the X font name, so this font's name is: -adobe-helvetica-bold-o-normal--12-120-75-75-p-69-iso8859-1 Slant is normally one of (o,r,i) for oblique,roman,italic Spacing is normally one of (c,p,m) for cell,proportional,monospaced (cell is roughly the same as monospaced) AddStyle is normally not used. Point Size is in 1/720th of an inch (value 0 for scalable font). PxlSize, resX and resY are never really applicable to a type 1 font. (values 0) AvgW is a bit of a weird thing that is sometimes handy when trying to replace the font for a block of text, but it is usually generated on-the-fly and not saved in the name (value==0). Therefore, the example font is actually specified in the font directory as: -adobe-helvetica-bold-o-normal--0-0-0-0-p-0-iso8859-1 Whatever Hans comes up with, at should be documented straight away. And by that I mean a precise specification of what the font installer can generate in the fields. Just some background info. Greetings, Taco ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-03 20:06 ` Giuseppe Bilotta 2001-08-04 11:45 ` Taco Hoekwater @ 2001-08-06 8:29 ` Hans Hagen 2001-08-07 17:59 ` Re[2]: " Giuseppe Bilotta 1 sibling, 1 reply; 15+ messages in thread From: Hans Hagen @ 2001-08-06 8:29 UTC (permalink / raw) Cc: ntg-context At 10:06 PM 8/3/2001 +0200, Giuseppe Bilotta wrote: >Friday, August 03, 2001 Hans Hagen wrote: > >HH> Hi, > >HH> I'm currently working on fonts, not so much in context itself, as well as >HH> installation. Since i want a clean way to install fonts [commercial ones >HH> for instance] and since licence policy is always tricky, i now put >them in >HH> a dedicated tree texmf-fonts. > >I think the TeX Directory Standard puts fonts under > >\texmf\fonts\<type>\<class>\<vendor>\<name> > >e.g. > >\texmf\fonts\type1\public\ams\cmr > >or something of the sort. right, and since i like to delete and reinstall the base path's i don't want my own fonts or patches there -) I think the (only) problem with this is that it fails on pure DOS >system (8.3 naming constrictions). Since the font naming is X >Windows-like, why don't you just use the X Windows scheme? right, in which case one can use filemapping to map back on 8 char names for which i provide \usetypescript [map][berry] >I don't find any objections. The recursive fontsynonym technique >also allows for automagic font substitutions: if >ec-uplr8a-slanted-167 is not available, it can be mapped to the >closer available font (e.g. removing the 167, which would seek >for a "default" slanted font, then removing the "slanted" etc; >something like using a * in a fontname part under X Windows). right, can even be automated, Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re[2]: fonts / proposal 2001-08-06 8:29 ` Hans Hagen @ 2001-08-07 17:59 ` Giuseppe Bilotta 2001-08-08 8:32 ` Hans Hagen 0 siblings, 1 reply; 15+ messages in thread From: Giuseppe Bilotta @ 2001-08-07 17:59 UTC (permalink / raw) Cc: ntg-context Monday, August 06, 2001 Hans Hagen wrote: HH> At 10:06 PM 8/3/2001 +0200, Giuseppe Bilotta wrote: >>Friday, August 03, 2001 Hans Hagen wrote: >> >>HH> Hi, >> >>HH> I'm currently working on fonts, not so much in context itself, as well as >>HH> installation. Since i want a clean way to install fonts [commercial ones >>HH> for instance] and since licence policy is always tricky, i now put >>them in >>HH> a dedicated tree texmf-fonts. >> >>I think the TeX Directory Standard puts fonts under >> >>\texmf\fonts\<type>\<class>\<vendor>\<name> >> >>e.g. >> >>\texmf\fonts\type1\public\ams\cmr >> >>or something of the sort. HH> right, and since i like to delete and reinstall the base path's i don't HH> want my own fonts or patches there -) use \localtexmf instead of \texmf as the root. the local tree is supposed to be used exactly for this purpose. -- Giuseppe "Oblomov" Bilotta ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re[2]: fonts / proposal 2001-08-07 17:59 ` Re[2]: " Giuseppe Bilotta @ 2001-08-08 8:32 ` Hans Hagen 0 siblings, 0 replies; 15+ messages in thread From: Hans Hagen @ 2001-08-08 8:32 UTC (permalink / raw) Cc: ntg-context At 07:59 PM 8/7/2001 +0200, Giuseppe Bilotta wrote: >use \localtexmf instead of \texmf as the root. the local tree is >supposed to be used exactly for this purpose. that one is already taken for updates and so, fonts may be put on some server somewhere; now texfont searches for both, so if you don;t have a dedicated font path, local is used Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-03 15:32 fonts / proposal Hans Hagen 2001-08-03 20:06 ` Giuseppe Bilotta @ 2001-08-04 12:30 ` siepo 2001-08-06 8:38 ` Hans Hagen 1 sibling, 1 reply; 15+ messages in thread From: siepo @ 2001-08-04 12:30 UTC (permalink / raw) Cc: ntg-context On 3 Aug, Hans Hagen wrote: > Hi, > > I'm currently working on fonts, not so much in context itself, as well > as installation. Since i want a clean way to install fonts > [commercial ones for instance] and since licence policy is always > tricky, i now put them in a dedicated tree texmf-fonts. > > In the texmf tree [as distribited by tex live] there are a couple of > free fonts [we're talking outlines] but not that much. I don't want > to let the rather latex oriented font naming and organization scheme > 'spoil' things and i want users to be able to easilly use other > encodings that ec too. How do users handle this currenlty, say that > they want polish encoding? > > Installing fonts comes down to > > (1) generating the tfm's > (2) if needed create vf files > (3) if neede copy files to the right location > (4) create a decent map file for pdftex > > in addition, if needed: > > (5) create slanted fonts > (6) create small caps > > Now, since one font can be on the system in say texnansi, ec, pl0, csr > or whatever encoding, and since users may have different opinions on > how slanted or small capped a font may be, we end up in so many files > that the current tex naming sheme drives at least me crazy. Also, i > really want to avoid latex like fd files scattering the system. > Therefore, this is what i have implemented and can support: > > (1) users choose a default encoding but can derive from it if needed, > let's assume ec here > > (2) texfont creates a series of files from the afm files (we assume > urw palatino): > > ec-urw-palatino.map > ec-raw-*.tfm > ec-*.tfm > ec-*.vf > > (3) if needed also create slanted/caps alternatives > > (4) also, a tex test file generated that show that things are done ok > > (5) typescript files will mape symbolic names in an efficient way What do you mean by efficient? > (6) map files will be loaded at run time [when enabled] What do you mean by this? > an example of a generated file is: ec-blabla-slanted-167.tfm which is > a bitthe x windows way of naming fonts. If needed one can have say 10 > slanted and 5 extended and 2 capped files of one font. Ok. But I wouldn't want proper X Window font names, as Guiseppe suggested, because those contain 13 parameters, which is a bit over the top. > [there is currenty a make file that makes all files needed] > > What does this mean in practice? A couple of more files, but named in > such a way that simple font users like me can see what happens. It > also means that we can use one set of typescripts for all kind of > encodings. A dedicated font tree so that we can consider zipping it > and posting it. > > Now, if context comes with the typescripts that define fonts this > verbose way. we can have a problem with users who want to stick to > the 8 byte names and/or want to sort out the funny names themselves. > Since filename mapping is implemented recursively, they can have a > way out with a special file like: > > \definefontsynonym [ec-uplr8a-slanted-167] [uplro8t] > > where they may hope that the latter is indeed available, slanted 167, > and in ec encoding. > > Are there any strong [and valid] objectiona against this scheme? The > idea is, in the end to have a way to set up a minimal consistent > system. > > Hans Is there going to be LaTeX support? How would your scripts handle `real' oldstyle figure and small caps fonts and expert sets? The character sets of these don't seem to be entirely standardized. I think that was the reason why I needed low-level fontinst macros to use my Times OSF&SC fonts even though I had expected the high-level latinfamily fontinst macro to generate the vfs and tfms that I wanted. Siep ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-04 12:30 ` siepo @ 2001-08-06 8:38 ` Hans Hagen 2001-08-06 9:22 ` siep 0 siblings, 1 reply; 15+ messages in thread From: Hans Hagen @ 2001-08-06 8:38 UTC (permalink / raw) Cc: ntg-context At 12:30 PM 8/4/2001 +0000, siepo@cybercomm.nl wrote: > > (5) typescript files will mape symbolic names in an efficient way > >What do you mean by efficient? say \usetypescript [palatino] [ec] and \usetypescript [times] [ec[ and then use \palatino and \times to swhich between font collections. Also, to be able to combine predefined typescripts. > > (6) map files will be loaded at run time [when enabled] > >What do you mean by this? that, instead of editing the pdftex.map file, context will instruct pdftex to load the map files needed. >Is there going to be LaTeX support? The current tools and texmf tree is rather tuned for latex. I think latex users are already served by fontinst and all those fd files. Bu >How would your scripts handle `real' oldstyle figure and small caps >fonts and expert sets? The character sets of these don't seem to be >entirely standardized. I think that was the reason why I needed >low-level fontinst macros to use my Times OSF&SC fonts even though I had >expected the high-level latinfamily fontinst macro to generate the vfs >and tfms that I wanted. right, and i think in this respect fontinst is more powerful; the thing that i have in mind are for users (like me) who have not the faintest idea about what font tricks can be done. in a later stage i will certainly look into expert fonts and alike [maybe taco wants to extend afm2tfm a bit for this], and there i definitely need your expertise in the font field -) Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-06 8:38 ` Hans Hagen @ 2001-08-06 9:22 ` siep 2001-08-06 12:13 ` Hans Hagen 0 siblings, 1 reply; 15+ messages in thread From: siep @ 2001-08-06 9:22 UTC (permalink / raw) Cc: ntg-context On 6 Aug, Hans Hagen wrote: > At 12:30 PM 8/4/2001 +0000, siepo@cybercomm.nl wrote: > >> > (5) typescript files will mape symbolic names in an efficient way >> >>What do you mean by efficient? > > say > > \usetypescript [palatino] [ec] > > and > > \usetypescript [times] [ec[ > > and then use \palatino and \times to swhich between font collections. > > Also, to be able to combine predefined typescripts. > >> > (6) map files will be loaded at run time [when enabled] >> >>What do you mean by this? > > that, instead of editing the pdftex.map file, context will instruct pdftex > to load the map files needed. For me, it is a frequent source of confusion when Context does things its own way. Filesearching deviating from kpsewhich filesearch was one example; mapfile loading different from what dvips and pdftex do on their own would be another. >>Is there going to be LaTeX support? > > The current tools and texmf tree is rather tuned for latex. I think latex > users are already served by fontinst and all those fd files. Bu Well, I am primarily a LaTeX user, but would welcome an alternative to fontinst and would certainly like to have a single font setup for all TeX macro packages. For regular text fonts, creating fd files should be no big deal, and maybe I could contribute there. Siep ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-06 9:22 ` siep @ 2001-08-06 12:13 ` Hans Hagen 2001-08-06 13:14 ` siep 0 siblings, 1 reply; 15+ messages in thread From: Hans Hagen @ 2001-08-06 12:13 UTC (permalink / raw) Cc: ntg-context At 11:22 AM 8/6/2001 +0200, siep@elvenkind.com wrote: >For me, it is a frequent source of confusion when Context does things >its own way. Filesearching deviating from kpsewhich filesearch was one >example; mapfile loading different from what dvips and pdftex do on >their own would be another. actually, file searching is not that different, since the only filetype supported by kpsewhich in tex itself are "tex" and "tfm"; i only block system wide searches for certain cases by forcing local searches, an dmost can be configured; global searches screw up any project with similar file names; context is meant for usage is highly structered projects' if you refer to figure inclusion, well this is messy anyway between tex's and apps -) concerning map files: dvips and pdftex already live in a world on their own, also, mapfiles can be highly conflicting [try to include a pdf graphic while using the default pdfonts.map and there is a reasonable change that you run into troubles due to naming conflicts]; also, many fonts in the map files are either not on any system, or in different names, etc etc. Actually, pdftex should be capable of using a format specific cfg file. I try to adapt as much as possible to anything standard, but esp with regards to fonts, less is standardized that one wishes, and i want once and for all to get rid of missing glyphs depending on what cd i mounted. Actually, it would already help a lot if mapfiles would be structured, properly named, etc Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-06 12:13 ` Hans Hagen @ 2001-08-06 13:14 ` siep 2001-08-07 8:40 ` Taco Hoekwater 0 siblings, 1 reply; 15+ messages in thread From: siep @ 2001-08-06 13:14 UTC (permalink / raw) Cc: pragma On 6 Aug, Hans Hagen wrote: > At 11:22 AM 8/6/2001 +0200, siep@elvenkind.com wrote: > >>For me, it is a frequent source of confusion when Context does things >>its own way. Filesearching deviating from kpsewhich filesearch was one >>example; mapfile loading different from what dvips and pdftex do on >>their own would be another. > > actually, file searching is not that different, since the only filetype > supported by kpsewhich in tex itself are "tex" and "tfm"; i only block > system wide searches for certain cases by forcing local searches, an dmost > can be configured; global searches screw up any project with similar file > names; context is meant for usage is highly structered projects' if you > refer to figure inclusion, well this is messy anyway between tex's and apps -) > > concerning map files: dvips and pdftex already live in a world on their > own, also, mapfiles can be highly conflicting [try to include a pdf graphic > while using the default pdfonts.map and there is a reasonable change that > you run into troubles due to naming conflicts]; also, many fonts in the map > files are either not on any system, or in different names, etc etc. > Actually, pdftex should be capable of using a format specific cfg file. > > I try to adapt as much as possible to anything standard, but esp with > regards to fonts, less is standardized that one wishes, and i want once and > for all to get rid of missing glyphs depending on what cd i mounted. > > Actually, it would already help a lot if mapfiles would be structured, > properly named, etc > > Hans I am certainly not claiming that things are perfect the way they are, but I have my own workarounds, and I get along ok with kpsewhich and mapfiles as they are. What about letting out-of-the-box pdftex and dvips read the same mapfiles that they would read outside Context, and letting Context use kpsewhich for all its file searching, and that any non-standard behaviour would have to be explicitly turned on in a configuration file? Siep ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-06 13:14 ` siep @ 2001-08-07 8:40 ` Taco Hoekwater 2001-08-08 9:13 ` Hans Hagen 2001-08-08 9:34 ` siep 0 siblings, 2 replies; 15+ messages in thread From: Taco Hoekwater @ 2001-08-07 8:40 UTC (permalink / raw) Cc: ntg-context, pragma siep@elvenkind.com wrote: > > What about letting out-of-the-box pdftex and dvips read the same > mapfiles that they would read outside Context, and letting Context use > kpsewhich for all its file searching, and that any non-standard > behaviour would have to be explicitly turned on in a configuration file? One way out of this should be create font-name mapping entries for the new system. the 'fontname' directory in your TeX tree. Then users can decide for themselves whether or not they want the new-style names. I don't really know how this works though, and I am not too eager to find out how it *should* work (and it doesn't solve the IMO nastiest problem: 2 times [a-z0-9] is just not enough for the family name to be anywhere near meaningful: most big vendors have more than 36*36 font families available). -- groeten, Taco ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-07 8:40 ` Taco Hoekwater @ 2001-08-08 9:13 ` Hans Hagen 2001-08-08 9:34 ` siep 1 sibling, 0 replies; 15+ messages in thread From: Hans Hagen @ 2001-08-08 9:13 UTC (permalink / raw) Cc: ntg-context At 10:40 AM 8/7/2001 +0200, Taco Hoekwater wrote: >siep@elvenkind.com wrote: > > > > What about letting out-of-the-box pdftex and dvips read the same > > mapfiles that they would read outside Context, and letting Context use > > kpsewhich for all its file searching, and that any non-standard > > behaviour would have to be explicitly turned on in a configuration file? > >One way out of this should be create font-name mapping entries for the >new system. the 'fontname' directory in your TeX tree. Then users can >decide for themselves whether or not they want the new-style names. there is indeed a mapping from the long names to the texmf-berry names, but that happens in tex; indeed an alternative is dedicated map files; should be doable for the couple of standard encodings; on the other hand, if we can work out a decent collection of nicely organized map files in the next year, i'm sure that we can convince the tex live people to add them Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-07 8:40 ` Taco Hoekwater 2001-08-08 9:13 ` Hans Hagen @ 2001-08-08 9:34 ` siep 2001-08-08 12:13 ` Hans Hagen 1 sibling, 1 reply; 15+ messages in thread From: siep @ 2001-08-08 9:34 UTC (permalink / raw) Let's try to summarize a few things. dvips reads psfonts.map to find the PostScript font for a given tfm, plus any transformations that have to be applied to that file. You can have as many tfms as you like for one PostScript font. For this, you can simply add a bunch of (Context) tfm-s to an existing psfonts.map and since the new tfm names are different from existing tfm names, it won't upset existing usage. The tricky part is reverse lookup. I understand from Taco that this occurs when a to-be-included epsfile needs fonts. Here, additional mapfile entries can cause problems. I am not familiar with the details. However, offhand I would say that for reverse lookup only the PostScript fontname and the filename would be used, and that there should be no problems as long as all entries referring to the same PostScript fontname also refer to the same pfb. It shouldn't be that hard to write a script which validates and corrects mapfiles for this. The point of all this is that it should be possible to stuff everything you need in your default psfonts.map. Also a word about fontinst. If you read the documentation then it is very LaTeX-centric. I believe however that this is mainly true for the top-level commands. I created three testfonts with fontinst, all based on Helvetica Light, with the following input file: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \input fontinst.sty \transformfont{phvl8r}{\reencodefont{8r}{\fromafm{phvl8a}}} \transformfont{transhv}{\reencodefont{8y}{\fromafm{phvl8a}}} \installfonts \installrawfont{installhv}{phvl8a,latin}{8y} {}{}{}{}{} \installfont{virthv}{phvl8r,latin,8r}{T1} {}{}{}{}{} \endinstallfonts \bye %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% As you see, you can name fonts whatever you like, and you can set the LaTeX-specific parameters to null values; these would only be needed for creating font families and fd files I think. These are the mapfile entries: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% transhv Helvetica-Light "TeXnANSIEncoding ReEncodeFont " <texnansi.enc <phvl8a.pfb installhv Helvetica-Light "TeXnANSIEncoding ReEncodeFont " <texnansi.enc <phvl8a.pfb %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% A LaTeX testfile: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \documentclass{minimal} \usepackage[LY1,T1,OT1]{fontenc} \DeclareFontFamily{LY1}{transhv}{} \DeclareFontShape{LY1}{transhv}{m}{n}{<->transhv}{} \DeclareFontFamily{LY1}{installhv}{} \DeclareFontShape{LY1}{installhv}{m}{n}{<->installhv}{} \DeclareFontFamily{T1}{virthv}{} \DeclareFontShape{T1}{virthv}{m}{n}{<->virthv}{} \begin{document} \fontencoding{LY1}\fontfamily{transhv}\selectfont Font generated with transformfont (non-virtual, no kerning, texnansi) German sz in wrong slot AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \ss \char223\par~\par \fontencoding{LY1}\fontfamily{installhv}\selectfont Font generated with installrawfont (non-virtual, generic kerning, texnansi) German sz in wrong slot AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \ss \char223\par~\par \fontencoding{T1}\fontfamily{virthv}\selectfont Font generated with installfont (virtual, generic kerning, T1) AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \ss\par~\par \end{document} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% A Context testfile (contributed by Taco): %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \definefontsynonym[Atranshv][transhv][encoding=texnansi] \definefontsynonym[Ainstallhv][installhv][encoding=texnansi] \definefontsynonym[Avirthv][virthv][encoding=ec] \definebodyfont [14.4pt,12pt,11pt,10pt,9pt,8pt,7pt,6pt,5pt] [rm] [bi=Atranshv sa 1, bf=Ainstallhv sa 1, it=Avirthv sa 1] \switchtobodyfont[10pt] \starttext Font generated with transformfont (non-virtual, no kerning, texnansi) {\bi AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \sz \par~\par} Font generated with installrawfont (non-virtual, generic kerning, texnansi) {\bf AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \sz \par~\par} Font generated with installfont (virtual, generic kerning, T1) {\it AT fi fl `A\relax T' A\kern0pt T \'el\`eve co\"\i tus \sz\par~\par} \stoptext %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% You can find pdfs of the testfiles at www.cybercomm.nl/~siepo/. Siep ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: fonts / proposal 2001-08-08 9:34 ` siep @ 2001-08-08 12:13 ` Hans Hagen 0 siblings, 0 replies; 15+ messages in thread From: Hans Hagen @ 2001-08-08 12:13 UTC (permalink / raw) Cc: ntg-context At 11:34 AM 8/8/2001 +0200, siep@elvenkind.com wrote: >dvips reads psfonts.map to find the PostScript font for a given tfm, >plus any transformations that have to be applied to that file. You >can have as many tfms as you like for one PostScript font. For this, >you can simply add a bunch of (Context) tfm-s to an existing >psfonts.map and since the new tfm names are different from existing >tfm names, it won't upset existing usage. right, i'm now using a psfonts.map file with all names stripped out [second entry] in which case it does not conflict. for the sake of simplicity, i furthermore leave that file untouched >The tricky part is reverse lookup. I understand from Taco that this >occurs when a to-be-included epsfile needs fonts. Here, additional >mapfile entries can cause problems. I am not familiar with the >details. However, offhand I would say that for reverse lookup only >the PostScript fontname and the filename would be used, and that >there should be no problems as long as all entries referring to the >same PostScript fontname also refer to the same pfb. It shouldn't be >that hard to write a script which validates and corrects mapfiles for >this. right, with reverse lookup, the FontName is used, unless removed. Since this name has no info on shape changes or alike, i removed them, otherwise pdftex will start loading the associated tfm file [funny confusing messages about fonts you don't use then show up] -) >The point of all this is that it should be possible to stuff everything >you need in your default psfonts.map. it would be a nice option [i will discuss this with thanh] if entries could be overloaded >Also a word about fontinst. If you read the documentation then it is >very LaTeX-centric. I believe however that this is mainly true for the >top-level commands. I created three testfonts with fontinst, all based >on Helvetica Light, with the following input file: ok, thanks for testing, i will look into that when i'm back from tug2001 Hans ------------------------------------------------------------------------- Hans Hagen | PRAGMA ADE | pragma@wxs.nl Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: +31 (0)38 477 53 69 | fax: +31 (0)38 477 53 74 | www.pragma-ade.com ------------------------------------------------------------------------- ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2001-08-08 12:13 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2001-08-03 15:32 fonts / proposal Hans Hagen 2001-08-03 20:06 ` Giuseppe Bilotta 2001-08-04 11:45 ` Taco Hoekwater 2001-08-06 8:29 ` Hans Hagen 2001-08-07 17:59 ` Re[2]: " Giuseppe Bilotta 2001-08-08 8:32 ` Hans Hagen 2001-08-04 12:30 ` siepo 2001-08-06 8:38 ` Hans Hagen 2001-08-06 9:22 ` siep 2001-08-06 12:13 ` Hans Hagen 2001-08-06 13:14 ` siep 2001-08-07 8:40 ` Taco Hoekwater 2001-08-08 9:13 ` Hans Hagen 2001-08-08 9:34 ` siep 2001-08-08 12:13 ` Hans Hagen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).