Lars,<br><br>Thanks again for all of your patience and help. I have found a workable solution for my needs: getting the ogoneks and commaaccents to output correctly using pdflatex.<br><br>To summarize for those just tuning in, I overcame the limitations of both AdobeStandardEncoding (8r) and T1 (8a) by writing my own encoding vector, as well as a few choice customized hacks to access the new glyphs.<br>
<br>I began with a copy of 8r.enc, and simply swapped out glyphs that are not in Palatino/Palladio (dotlessj, some f-ligatures, infinity, etc) for the ones I needed (Aogonek, tcommaccent, etc.)<br><br>I then made a copy of t1.etx, and swapped out the slots that are not in Palladio (tcedilla, etc.) with slots for my new glyphs, and used this when I called installfont in my fontinst script.<br>
<br>Lars suggested that I write another encoding in order to declare text composite commands to access any new commaaccent glyphs. That looked a bit intimidating to me, and so I resorted to a quick hack.<br><br>I'm somewhat embarassed to say that I simply dropped this command into my style file:<br>
<br>\def\cb#1{%comma below<br>\ifx#1S\char30\else\ifx#1T\char149\else%<br>\ifx#1s\char26\else\ifx#1t\char181\else#1%<br>\fi\fi\fi\fi}<br><br>I did notice that Palladio has a spare "commaccent" glyph that could surely be brought in to draw all the other commaaccents on the fly. I'll leave that as an exercise for another day.<br>
<br>The upshot seems to be that, yes, each font really should have its own encoding vector. Although the above methodology is exceedingly clumsy, I've certainly profited from the effort.<br><br>Two more things I should mention. In all this I'm not actually setting extended text in Turkish, Romanian or Polish; merely the occassional word in each language.<br>
<br>As for the slots, it's trivial to cross-reference the AFM, 8r.enc and t1.etx and see where room can be made.<br><br>One caveat: when I ran my test file through, I noticed that I had to have my new encoding vector (.enc) in the same directory to get it to work.<br>
<br>The relevant line in the map file looks like this:<br><br>up9r8r URWPalladioL-Roma <up9.enc <up9r8a.pfb " fontinst-autoenc-up9 ReEncodeFont "<br><br>Should I somewhere give this a more proper name or indicate where it can exist in my TeX directory?<br>
<br>—Christopher<br><br><div class="gmail_quote">2010/1/18 Lars Hellström <span dir="ltr"><<a href="mailto:Lars.Hellstrom@residenset.net">Lars.Hellstrom@residenset.net</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Christopher Adams skrev:<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I've finally pieced together that the solution is to write my own encoding<br>
vector.<br>
<br>
Is there a good tutorial about how to do this?<br>
<br>
As a test I simply made a copy of 8r.enc and 8r.etx. In the .enc file I<br>
replaced one of the /.notdef's with /eogonek, and then added a \setslot for<br>
this glyph in the .etx file. Then I changed \reencodefont{8r} to refer to my<br>
renamed, modified copy, ran the files through TeX and updated all the map<br>
files.<br>
<br>
Sure enough, the correct *eogonek* comes out in the PDF (it's even<br>
serchable). Perfect!<br>
<br>
I finally understand the reason that *eogonek* wasn't working is that it<br>
isn't defined by 8r.<br>
<br>
I still have some questions.<br>
<br>
1) What's the best way to do what I need?<br>
</blockquote>
<br></div>
Depends on your priorities. If they are to get what you need done with as little effort as possible, then the "substitute a few glyphs" approach you later seemed to decide on is probably optimal. If they instead are best quality -- to produce the full font support for Eastern/Central European languages using the latin script -- then it might rather be to embark on the project of producing a T1A (or whatever) encoding, that can be used for those languages where T1 isn't quite sufficient.<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) If I need a glyph that is not in T1, like *iogonek*, in addition to the<br>
above, do I then simply have to modify t1.etx and add a slot for that glyph?<br>
</blockquote>
<br></div>
As far as fontinst is concerned, yes, and if using the new multislot.sty package (which I'm not sure I've ever announced properly), you can write an ETX which *only* sets the slots that are different from T1, and then goes \inputetx{t1}, thus significantly reducing the amount of editing you need to do.<br>
<br>
When we get to LaTeX however, things are quite different.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) If I need a glyph that doesn't even have a TeX command, such as<br>
scommaccent, what do I have to do to get access to it in my latex document?<br>
I know someone has written a \cb{} command that fakes comma below. Can I<br>
write my own \cb{} command? What would it look like? I really only need to<br>
access to scommaaccent and tcommaaccent.<br>
</blockquote>
<br></div>
This is a matter of the encoding-specific "text commands", which are described in the "Encodings" section of fntguide.tex (part of LaTeX distro) and Section 7.11 of The LaTeX Companion (2nd edition). You would probably want to do something like<br>
<br>
\DeclareTextComposite{\k}{L01}{s}{...}<br>
<br>
if following Hilmar's suggestion of using \k also for the comma accent; the above would (if ... is replaced by the right slot number) make \k{s} typeset an scommaaccent glyph.<br>
<br>
What you can't get around is however the need to declare a new LaTeX encoding for your fonts, since you'll need some text commands to end up doing something different than they would under T1. In the example above I used L01 (local encoding 1) for this new encoding, as you'll (at least initially) probably only be using it privately, but in the long run I think a lot of people would benefit if someone stepped up to designing an encoding which fully covers the Eastern European languages T1 only provides a partial solution for. Hilmar?<div class="im">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Fortunately, because I'm doing book work, I can make room in the encoding<br>
vector by discarding some math symbols and analphabetics.<br>
</blockquote>
<br></div>
Are you talking about 8r here? There isn't very much nonalphabetic material in T1 to get rid of. Getting something new in pretty much necessitates losing some of the precomposed letters...<br>
<br>
<br>
<br>
Christopher Adams skrev:<div class="im"><br>
> Hi Hilmer,<br>
><br>
> Thank you again for your thoughtful replies.<br>
><br>
> 2010/1/17 Hilmar Schlegel<br></div>
[who likes to keep his e-mail secret, wrote]<div class="im"><br>
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Well, another question would be: What do you want to do?<br>
Seriously, all depends on what you really need (and not<br>
necessarily what you believe now you might need).<br>
</blockquote></blockquote>
><br>
> At this point I can define my goal quite narrowly: I need an<br>
> *a/eogonek*rendered as single outlines, as well as t/scommaccent<br>
> (without loosing<br>
> scedilla). I see now this should be quite easy to achieve.<br>
><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2) If I need a glyph that is not in T1, like /iogonek/, in<div class="im"><br>
addition to the above, do I then simply have to modify t1.etx and<br>
add a slot for that glyph?<br>
</div></blockquote></blockquote></blockquote>
>><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
That is a practicable solution for some special glyphs. Since T1<div class="im"><br>
is full, those are replacements of other glyphs you don't need.<br>
</div></blockquote></blockquote><div class="im">
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Since my target glyphs are few i number, this would appear this is<br>
</blockquote>
> the best solution.<br>
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
If I write a \setslot{scommaaccent} in my modified t1.etx file, I'm<br>
still not confident I could typeset it. My low-level TeX is not so<br>
good, and so I'm trying to puzzle out the code you sent. At some<br>
point in the code do you<br>
have to refer to the glyph by its char number? Or is there another<br>
way to refer to whichever glyph occupies the "scommaaccent" slot by<br>
name?<br>
</blockquote>
><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3) If I need a glyph that doesn't even have a TeX command, such<div class="im"><br>
as scommaccent, what do I have to do to get access to it in my<br>
latex document?<br>
I know someone has written a \cb{} command that fakes comma<br>
below. Can I<br>
write my own \cb{} command? What would it look like? I really<br>
only need to<br>
access to scommaaccent and tcommaaccent.<br>
</div></blockquote></blockquote></blockquote>
>><br>
>><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Well, you can simply use the ogonek accent command: \k{a} and<div class="im"><br>
\k{e} are defined as standard Latex commands. Ogoneks are applied<br>
to vowels (like iogonek) and for consonants you simply provide<br>
commaaaccents (g, k, n, r, s,<br>
t). See the sample for using \k as ogonek/commaaccent for vowels/consonants.<br>
</div></blockquote></blockquote><div class="im">
>><br>
>> Here the commaaccent is defined as a specific char code.<br>
>> You can place it as it suits your needs.<br>
><br>
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Am I correct that this code is drawing the glyphs by composing a base letter with a diacritic? But it first checks to see if there is<br>
a real eogonek? I apologize that I'm having trouble following the code. Would it be feasible to have a command that gets \cb{s} and \cb{t} to print the right glyphs, assuming that the .etx has slots for s/tcommaccent?<br>
</blockquote>
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
s/tcommaccent are a trivial correction for T1: replace scedilla (which will mean there is no longer Turkish language support) and<br>
use a T1' with a commaccent and redefine (extend) the \k{} command<br>
as in the sample code.<br>
</blockquote></blockquote>
>><br>
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
It seems I can't quite go this route, as I can't lose Turkish as a<br>
</blockquote>
> result.<br>
><br>
><br>
>><br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Fortunately, because I'm doing book work, I can make room in the<div class="im"><br>
encoding vector by discarding some math symbols and analphabetics.<br>
</div></blockquote>
<br><div class="im">
Actually you are not free to assign the glyphs in Latex to<br>
arbitrary character codes! All depends on the used hyphenation<br>
patterns for the needed<br>
languages (Eastern European, Baltic, old Prussian &c). Therefore<br>
T1 can be a reasonable template to start with since there is a high probability of language support for T1 encoded fonts.<br>
</div></blockquote></blockquote>
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ok, this is good to know. I'm very curious to know where this "you<br>
are not free to assign..." mandate is written.<br>
</blockquote>
<br>
I've tried to document it in fontinst/doc/encspecs/encspecs.tex. The main problem is that TeX's \lccode table establishes a correspondence between upper and lower case letters, and if you don't respect these correspondences then the hyphenation can get screwed up.<div>
<div></div><div class="h5"><br>
<br>
>> From the pure typographic view I'd strongly suggest to consider<br>
>> i) the font Aldus [...]<br>
>> ii) Palatino and Aldus Nova OT from Linotype. [...]<br>
>><br>
><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
These are both considerate choices. I very aware of both Aldus and<br>
Palatino Nova, and under different circumstances your suggestions<br>
would be entirely correct. But in this case I have already<br>
determined that the regular and bold weights of Palatino are<br>
precisely what I need (as a display face I'm using Sistina). Plus,<br>
the fact that I require embedding permissions means that I need<br>
Adobe. The fact that I have to tweak some glyphs means I need<br>
Palladio.<br>
</blockquote>
><br>
> If circumstances were different I probably wouldn't be using any of<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
these. It just so happens that the work I am setting deals with<br>
literary and cultural history centered in Frankfurt from the 1950s onward. It is as if the choice has been made for me!<br>
</blockquote>
><br>
> In point of fact this has all given me a much finer appreciation of<br>
> Zapf's accomplishment.<br>
><br>
><br>
>> iii) for the less strict user of existing implementations it is also<br>
>> worth to have a look into a Palatino Linotype, which is a TT<br>
>> (TrueType) font with a larger glyph set. In case you can take the<br>
>> trouble and make use of large TT fonts for Latex (extract the<br>
>> metrics, map with fontinst and embed them via Distiller) this can<br>
>> enrich the glyph set usable by Latex considerably.<br>
><br>
> This is something I'm certainly interested in learning how to do.<br>
> Considering my modest skill-set I'm determined to stick with Type 1<br>
> fonts for now. Are there any good resources to learn more about this?<br>
><br>
> My reasons for using fonstinst stem from my reliance on the microtype<br>
> package in pdflatex. But now I'm really hooked on the flexibility it<br>
> offers for mashing up fonts. I'm really interested in learning how<br>
> OpenType is going to change the fontinst landscape. Any pointers?<br>
<br></div></div>
Well, since you ask about the future... But bear in mind that this is probably double-danger material, and very much work in progress:<br>
<br>
<a href="http://abel.math.umu.se/%7Elars/fontinst/bigbase.dvi" target="_blank">http://abel.math.umu.se/~lars/fontinst/bigbase.dvi</a><br>
<br>
Again, be warned: I had the spur of fontinst development resulting in this back in September--October, but from November and on I've been doing other stuff. There's no reason to believe these mechanisms will be in anything resembling working condition within the foreseeable future.<br>
<font color="#888888">
<br>
Lars Hellström<br>
<br>
</font></blockquote></div><br>