Thomas A.Schmitz said this at Mon, 21 Feb 2005 10:01:50 +0100:

Just a quick reply:

having the afm is already very good. The file without an extension looks suspiciously like a Mac font resource. Can you try running the utility "fondu" on it (from the command line)? That will usually produce the pfbs (very likely, there's more than one: roman, italics, bold ...). Texfont, btw, can equally well work with truetype fonts, so if you have a proper tryetype font with extension .ttf. you might as well use this. texfont will produce a map entry that you will have to modify a bit (so it points to a .ttf instead of the default .pfb), but that's not too difficult. As to names: don't bother, ConTeXt is happy with whatever name you throw at it.

Only a couple things to add: When fondu generates the .pfb file, copy the .afm to share the new (probably longer) filename. Texfont on MacOSX trips on capital letter extensions: make sure they're uniformly lower case. If fondu fails you (it hasn't failed me yet), there's also t1unmac (lcdf.org). And if texfont installation fails or inexplicably stalls, you might need to go in and truncate long (255+ character) lines by manually editing the text file. I've always found these to be comment/copyright lines, so you're not hurting anything by doing so. You lucky so-and-so for getting Andulka! adam

On Feb 21, 2005, at 1:58 AM, David Wooten wrote:

...

Greetings all,

I've been having a lot of fun struggling with the installation of a newly purchased font, and wanted to double check a preliminary question before I give in and ask a more thorough question ;)

I'm working with Mac OS X, so I bought a font-set with both Mac TTF and Postscript files. The Postscript folders have 2 types of file for each fontname: .afm and another without a suffix. The names also have uppercase letters, such as AndulBooBol (a.k.a. Andulka Book Bold).

For the texfont script, it apparently needs the .afm files and .pfb files. Thus:

1) Are these non-suffixed files the .pfb files in question? If so, should I rename (add .pfb to) them before trying to install them? (I could convert the TTF files to .pfb?)

2) Should I take away the UpperCaseLettering as well? Rename them to something more Berry-like?

In fact, I've tried these things with no success, but before I spell out the details of my failure I thought I would get this straight.

Kind regards, David Wooten

_______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context

_______________________________________________ ntg-context mailing list ntg-context@ntg.nl http://www.ntg.nl/mailman/listinfo/ntg-context

-- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl@comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Greetings ConTeXters I'm back to ask another question: After an initial successful installation of the purchased fonts, I've come to find that there is a serious quirk. That is, when I try to use any special glyph, be it an accented character of any kind, or e.g. an eth. The result of something like \"a (or \"{a}) is _a_ without the diacritic. Curiously (to me, at least:), if I enter the actual glyph: ä, it gives me the character I need…but only for a few runs! After adding a couple more of such "alternative" glyphs, it starts to show gibberish. Some trials evince an ff-ligature as the diacritic. Errors in the mapping/virtual font/…? Again I hope to save myself some time by asking to be pointed in the right direction, as my initial searches haven't really helped. Kind Regards, David Wooten On Feb 21, 2005, at 1:17 AM, Adam Lindsay wrote:

Thomas A.Schmitz said this at Mon, 21 Feb 2005 10:01:50 +0100:

...

Just a quick reply:

having the afm is already very good. The file without an extension looks suspiciously like a Mac font resource. Can you try running the utility "fondu" on it (from the command line)? That will usually produce the pfbs (very likely, there's more than one: roman, italics, bold ...). Texfont, btw, can equally well work with truetype fonts, so if you have a proper tryetype font with extension .ttf. you might as well use this. texfont will produce a map entry that you will have to modify a bit (so it points to a .ttf instead of the default .pfb), but that's not too difficult. As to names: don't bother, ConTeXt is happy with whatever name you throw at it.

Only a couple things to add: When fondu generates the .pfb file, copy the .afm to share the new (probably longer) filename.

Texfont on MacOSX trips on capital letter extensions: make sure they're uniformly lower case.

If fondu fails you (it hasn't failed me yet), there's also t1unmac (lcdf.org).

And if texfont installation fails or inexplicably stalls, you might need to go in and truncate long (255+ character) lines by manually editing the text file. I've always found these to be comment/copyright lines, so you're not hurting anything by doing so.

You lucky so-and-so for getting Andulka! adam

David Wooten said this at Fri, 11 Mar 2005 15:40:14 -0800:

That is, when I try to use any special glyph, be it an accented character of any kind, or e.g. an eth.

Hi David, I took a look at your file (off-list), and it looks like you're using the 8r encoding. Interesting that you bring the "eth" up, because that character doesn't exist in the 8r encoding.

The result of something like \"a (or \"{a}) is _a_ without the diacritic.

Hmm. What do your typescript definitions look like, then? Does ConTeXt know you're using 8r as the encoding for the font?

Curiously (to me, at least:), if I enter the actual glyph: ä, it gives me the character I need…but only for a few runs!

Okay, that now becomes an interaction between regime (input file encoding) and the rest. It could be coincidence that ä is in the same slot (228) with both regime and encoding. Which regime are you using? Are you sure it lines up with the encoding in (say) TeXshop?

Some trials evince an ff-ligature as the diacritic.

That's another data point pointing to the encoding not being in synch. So. More input required, but right now I'm eyeing the encoding with suspicion. adam P.S. As a side point, Andulka does indeed look like a nice, sturdy, legible text font. A bit like the free (but masterfully drawn) Charter, but with a lot more personality. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl@comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

David Wooten said this at Sat, 12 Mar 2005 15:07:25 -0800:

...

Hmm. What do your typescript definitions look like, then? Does ConTeXt know you're using 8r as the encoding for the font?

I believe so. An example from the typescript file:

\usetypescriptfile [type-buy] \loadmapfile [8r-stf-andulka-book.map]

\starttypescript [serif] [andulka-book] [name] \definefontsynonym [Serif] [Andulka-Book] \stoptypescript

\starttypescript [serif] [andulka-book] [8r] \definefontsynonym [Andulka-Book] [8r-andulkabook]

Ah-ha. ConTeXt isn't *that* clever about names. At the end of the font synonym chain, you need to associate the font name with an encoding explicitly. The typescript names are just symbols (for the most part) that signal to ConTeXt which groups of definitions to use. Therefore, the above line should be: \definefontsynonym [Andulka-Book] [8r-andulkabook] [encoding=8r]

\stoptypescript

...

...

Curiously (to me, at least:), if I enter the actual glyph: ä, it gives me the character I need…but only for a few runs!

Okay, that now becomes an interaction between regime (input file encoding) and the rest. It could be coincidence that ä is in the same slot (228) with both regime and encoding. Which regime are you using? Are you sure it lines up with the encoding in (say) TeXshop?

I use TextMate for the text editing, and it's currently saving in UTF-8. …this area of "regime and encoding" isn't very clear to me. That sounds like a clue.

It does. I started to explain some of this on the list, saved on the wiki: http://contextgarden.net/Encodings_and_Regimes Regime is the encoding of the input document processed by ConTeXt. If you're using TextMate in UTF-8, then you should add this to every document or perhaps your local cont-sys.tex: \enableregime[utf] This converts things like ä to the internal named glyph \adiaeresis. Encodings map these names to numbers from 0 to 255, which are indices into the font file. The file enco-tbo says for fonts in the 8r encoding, given a character \thorn, choose character #254 from that font. Look at the penultimate cell in your \showfont[8r-andulkatext] file, and there's that thorn. Perhaps that's too much detail. :) Choose the encoding that's right for you, and consistently apply it in your typescripts, and you'll be fine. You got into trouble because not naming an encoding, ConTeXt assumed you meant the default encoding, which consists of a bunch of fallbacks that get you close to what you want, but often not close enough.

...

P.S. As a side point, Andulka does indeed look like a nice, sturdy, legible text font. A bit like the free (but masterfully drawn) Charter, but with a lot more personality.

Yes, I've grown fond of it, especially at a smaller size. Funny you should mention Charter in this regard, as it always had a certain appeal.

And then there's a bit of the legibility innovations of Gentium thrown in... the low shoulders (look at that 'h'), the wedge serifs, and the stress on asymmetrical features... nice font. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Adam T. Lindsay, Computing Dept. atl@comp.lancs.ac.uk Lancaster University, InfoLab21 +44(0)1524/510.514 Lancaster, LA1 4WA, UK Fax:+44(0)1524/510.492 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

David Wooten wrote:

I'm back to ask another question: After an initial successful installation of the purchased fonts, I've come to find that there is a serious quirk. That is, when I try to use any special glyph, be it an accented character of any kind, or e.g. an eth. The result of something like \"a (or \"{a}) is _a_ without the diacritic. Curiously (to me, at least:), if I enter the actual glyph: ä, it gives me the character I need…but only for a few runs! After adding a couple more of such "alternative" glyphs, it starts to show gibberish. Some trials evince an ff-ligature as the diacritic. Errors in the mapping/virtual font/…?

i can imagine interference between input encoding and remapping (map/enc file) later in the pipeline, but what puzzles me is that different runs produce something different; sounds more like an os/caching problem Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------