Created attachment 6123 [details] urw -> industry names A gs fontmap is needed for the URW font set at http://www.artifex.com/urw136/ I suppose it can be stored in the /lib directory like the other font maps. The mapping from URW to industry font names is attached.
Note, font set moved to protect it. Contact Ray Johnston for new locations on the www.artifex.com server. Also placed the files on spectre.ghostscript.com:/home/ray/urw136
Henry I'm not sure what the requirement is here. The existing URW fonts (basic 35 font set) are stored as type 1 fonts in /gs/Resource/Font, using the URW font name instead of the font filename the fonts were (presumably) originally supplied under. That is, we've renamed the files. They still appear to be PFB encoded type 1 fonts though. The URW fonts are then aliased to the normal font names in Fontmap.GS. So GS finds the fonts by name, as they are stored in Resource/Font, and if one of the standard names is used, the font map aliases the request to use the URW font name. Do you want me to do the same with the 136 type 1 files ? That is, rename the .PFB files to have the name of the font, and then create a Fontmap.GS which contains aliases for these fonts to the regular PostScript names ? What about the TrueType fonts, do you need me to do anything with those ?
We definitely need the 'alias' Fontmap entries, /IndustryFontName /URWFontName ; then to allow the fonts to be used, we need the fontname to file name mapping: /URWFontName (urwfile.pfb) ; We (I) renamed the fonts when we put them in the Resource/Font directory to avoid the need for the extra mapping and to avoid having the Resource/Font on the LIBPATH (since that is where font files are searched for). To allow testing of the urw136, all we really need is the two form mapping, we can decide later if we want to rename the files (easily done from the fontname to file name mapping).
I'm still working on this, but here are some observations and issues: Information in spreadsheet ================================ 1. It would be helpful if the spreadsheet contained the actual PostScript '/FontName' of the URW supplied font, and ideally the PostScript /FontName of the '136 font set' font which it replaces. For example, at the moment the spreadsheet contains entries like: Fontnr Family name weight industry name ------------------------------------------------------------------ G043003 URW Garamond regular Stempel Garamond roman What would be more helpful would be: Fontnr Family name weight industry name URW PSName Adobe PSName --------------------------------------------------------------------------------------------------------------- G043003 URW Garamond regular Stempel Garamond roman GaramondURW-Reg StempelGaramond-Roman That way we would know the actual PostScript font name of the font when loaded into the PostScript environment, and the (PostScript) name of the font it is intended to be a substitute for. 2. AtramentURW is named as a replacement for Taffy, but Taffy is not identified in the standard 136 font list. Looks somewhat like Tekton but Tekton is a sans serif face and Taffy is a serif face. In fact the real Taffy is also a sans serif font, so AtramentURW does not appear to be a reasonable substitute for Taffy either. 3. No replacement defined for Wingdings-Regular. Problems with the .PFB font files ============================== 1. The PFB font files 'g043004i.pfb (URW Garamond demi) and g043024i.pfb (URW Garmanond Italic) contain the same /FontName entry in the font dictionary 'GaramondURW-Dem'. The file g043024i should probably have a /FontName entry something like 'GaramondURW-Ita'. 2. The PFB file n019065i.pfb (NimbusSanCon-BolIta) does not define a /.notdef glyph, and is therefore invalid as this glyph is required to be present in all fonts.
Finished testing. There are 4 problems: 1) g043004i.pfb and g043024i.pfb are both named internally (/FontName) as 'GaramondURW-Dem'. Thus we have no GaramondURW-DemIta and so no font to use for 'StempelGaramond-BoldItalic'. 2) No font supplied to replace Wingdings. 3) NimbusSanCon-BolIta (n019065i.pfb) is not a valid Type 1 PostScript font as its CharStrings dictionary does not contain a /.notdef glyph. 4) The replacement nominated for Monaco (NimbusTypewriter-Regular) is not a very good substitute. Several glyphs, including 'a', 'r' and 'k' are noticeably different shapes from the Monaco font. Other than that, I have a compete fontmap available.
URW will not create a Wingdings font for legal reasons. I'll send off an email to urw with the other issues you noted in comment 4 and 5.
> 3) NimbusSanCon-BolIta (n019065i.pfb) is not a valid Type 1 PostScript font > as its CharStrings dictionary does not contain a /.notdef glyph. .notdef is a SFNT quirk, not required by type1 fonts.
From the Adobe type 1 font format, page 23 in my copy: "The preceding example shows a character named “.notdef” defined in the CharStrings dictionary. A Type 1 font program must have a “.notdef” character defined in in its CharStrings dictionary, even if it is not referenced by the encoding vector." So I submit it is not a SFNTS (ie Type 42) quirk, and it *is* a requirement of a type 1 font.
Ken is correct. This has been a requirement all along and was never relaxed as far as any official Adobe Type 1 document I can find. I have Version 1.1 (1990) and it has this same statement at the end of Section 2.4 on page 17.
*Blush* Oh for the tropism of youth, back when memory actually worked! ☹ Yes, I misremembered. And rather stupidly at that. ☹ ☹ .notdef is indeed required in type1. Obviously, else what would an empty encoding array slot have as a filler?... I must have been thinking of the unfortunate use in most GLYF fonts — and now many cff fonts — of a marking glyph. I don’t suppose these three comments can be elided from the bz db? I didn’t think so.
(In reply to comment #7) > .notdef is a SFNT quirk, not required by type1 fonts. I don't have the type 1 spec heady, but /.notdef is definitely required. One of my earliest mis-adventure in ghostscript-land was a mysterious problem involving japanaese printing with the public domain wadalab fonts (which was PS type 3 converted to type 1) just over a decade ago - printing via ghostscript to pcl5-based printer works, but print jobs to Apple Laserwriter just disappeared. Some kind soul on the internet took a look at the postscript file and told me ghostscript doesn't care about /.notdef (since it is not used), but genuine postscript printers do. So I added a couple of lines to the type3 to type 1 program in C just to add a bogus /.notdef entry to make geniune PS printer happy. Just out of curiosity - does gs emit a warning for embedded/subsetted type 1 fonts now, or still silently accept such slightly off-spec files? I think it does emit a warning about actually needing to substitute for /.notdef, but probably does not enforce validity when /.notdef is not used?
I don't think GS will raise an error if a font embedded in the PostScript file has no /.notdef, though I haven't tried it to be certain. Of course if it has no /.notdef and needs it then it will cause an error ('undefined' error I suspect).
Henry, another problem with the type 1 fonts. /NimbusSanNo2-BolIta (n019023i.pfb) This is actually the Italic font /NimbusSanNo2-Ita (n019024i.pfb) This is actually the Bold Italic font. The names are taken from the font dictionary /FontName, the excel spreadsheet claims these fonts are numbered 'a30033' (same number for both of them), but there are no font files with those names.
The same Italic/BoldItalic confusion for NimbusSanNo2 persists with the TrueType fonts. Opening the file (under Windows) 'n019023i.ttf' the font properties say it is 'NimbusSanNo2 Bold Italic'. Opening the file 'n019024i.ttf' the font properties say it is 'NimbusSanNo2 Italic' Comparing the font samples the 'Italic' font is clearly bolder than the 'Bold Italic' font.
Revision 10988 adds interim Fontmap files for the Type 1 and TrueType fonts. These will need to be altered once URW address the font naming problems and fix the illegal type 1 font.
Are there any news/progresses on this one?
Re-assigning to Chris who has been doing recent work on this. We do now have a Wingdings font, I have no idea if the other problems in the font set have been fixed.
If it will help, I can run raster images of the 136 fonts that come with CPSI that can be used for a fuzzy compare. The lib/prfont.ps can be used to dump all the glyphs in the font.
With the latest release (1.10) n019065i.pfa ("Nimbus Sans Condensed Bold Italic" or "/NimbusSanCon-BolIta") still does not define a /.notdef glyph, nor does it contain a /space or /nbspace. With the latest release, the filenames have changed, this the mapping in the spreadsheet attached above is not relevant. Also, in the speadsheet above, several of the fonts appear listed as including Greek and Cyrillic glyphs, but looking at the font contents, there are no Cyrillic glyphs and only a very few "common" Greek glyphs like mu, omega and pi. We need to get back to URW with these observations.
The fontmap for the up to date URW++ 136 font set is now in our git repo with the font files themselves.